Version: (using KDE Devel) Installed from: Compiled sources Compiler: g++ 2.95.3 OS: Linux Hi, Selecting text in Konqueror/KHTML is really not usable. Open the attached document in Konqueror, and try to select the text between General and Compilation & Configuration with the mouse from top to bottom. (Place the mouse just before the list mark before "What is FreeType2?") The text will not be selected, but if you drag the mouse down under the "Compilation & Configuration", this "Compilation & Configuration" and all what is below will be selected. You can select the text under General in two ways: 1. Click first before the "General", but this way also the "General" string will be selected: it's not eaxctly what we want. 2. Select from bottom to top, but people usually do the other way, as it is more logical. The second error is shown in the screenshot. Place the mouse somewhere in the document, and select some text from bottom to top and without releasing the mouse button, drag the pointer down before the first point where you've clicked. The expected behaviour would be that the text from the first point to the last point (where you've released the mouse button) is selected, and it's not important if you have moved the mouse around the screen with the button pressed. Actually the text is corretly selected, but the selection mark gone crazy. Hiding and restoring the window shows the correct selection. If one part of the weird selection if covered by another window, than when you move away the window, that part will be correctly restored (but the whole image will look even worst). For the first bug there was a fix written by D. Faure sometime before the 3.1 was released, but it was never committed. :-( Andras
Created attachment 922 [details] Reproducible with this file
Created attachment 923 [details] Weird selection screenshot.
I can confirm this. I am going to have a look and see what I can do, but as this is my first attempt at hacking on KHTML ... we'll see ;)
I vote for this (cause I *hate* this bug, too)
Can anyone reproduce those problems with the current KHTML from CVS HEAD? I tried quickly and it all looks fine to me.
Works for me in current CVS
Subject: Re: Weird selection in KHTML The reported cases seems to be fixed, but please don't close the bug report, as the selection is still broken is some other cases. Let's use the same file to show the where is broken: 1. At the beginning of the page, there is the text "Document index". Let's try to select it: a) Left to right selection is not working, if you place the mouse cursor somewhere before the "D". You may be able to select from left to right if the starting point is close enough (or is on) "D". b) Quickly moving the mouse from right to left usually will not select the whole text, but only part of it. c) Left-Top->Right-Bottom selection is not working d) Right-Top->Left-Bottom selection is usually not working. You have to be lucky and start from the right pixel in order to be able to select the text. e) Place the mouse right-top relative to the "x" and move it below the text and a little left. If sometimes selects the whole text, sometimes only the "x" or the space after the "x". Same happens if you start from the below and try to select from bottom to top. Sometimes you see that the "x" is selected, but the selection quickly disappears. f) the text selected (if you are able to select) will not go into the Selection clipboard!! Even worst, if I press CTRL-C to put it in the clipboard, it will put some other text there!! This is not the case when I select another text, like the "The FreeType 2 FAQ" or something from the TOC, but happens with the "Document index" IF you select from right to left. And right now selecting from right to left is the only reliable way to select it. 2. Go a little further in the document to the "I.1 What is FreeType 2 ?".. a) if you selected somehow the above "Document index" from right to left, you scroll down and try to select this text, you cannot. I click somewhere and move the mouse across the screen, but nothing is selected. After switching to another window and back, I can select some text. b) place the cursor after this text, move it up, so the last items from the TOC from above, are selected, move back the mouse (without releasing the button) before the text, and ALL the remaining text in the document gets selected. c) this weird selection of the rest of the document can be triggered more easily by clicking above the horizontal line, and "selecting" this line. When you move in the bluish area of "General questions & answers", the rest of the document gets selected. So the conclusion is that, the first reported bugs are fixed, but the selection is still weird and in many cases confusing and unusable. Using CVS from 04/01/2003. Andras - -- Quanta Plus developer - http://quanta.sourceforge.net K Desktop Environment - http://www.kde.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+io3RTQdfac6L/08RAvcfAJ0alrr8Z2SlUxrQAwcqNuFEIa3wdQCfbMkq T81FSNdrUKiiTWnlScDAghQ= =sVLr -----END PGP SIGNATURE-----
yeh the selecting problem buging alot .
> Created an attachment (id=923) > Weird selection screenshot. Please do NEVER use JPEG for screenshots! Can't you see that the image is completely distorted aroud text? JPEG is only for photos. Use PNG for screenshots.
Subject: Re: Weird selection in KHTML Sorry? The JPEG image is 50KB. In PNG would be much bigger => it takes more time to upload/view it. And I don't see any distortion that affects the presentation of the bug. Andras
Subject: Re: Weird selection in KHTML I did not originate the message here. Eric On Monday 21 July 2003 2:11 pm, you wrote: > ------- You are receiving this mail because: ------- > You are a voter for the bug, or are watching someone who is. > > http://bugs.kde.org/show_bug.cgi?id=54395 > > > > > ------- Additional Comments From amantia@freemail.hu 2003-07-21 23:11 > ------- Subject: Re: Weird selection in KHTML > > Sorry? The JPEG image is 50KB. In PNG would be much bigger => it takes more > time to upload/view it. And I don't see any distortion that affects the > presentation of the bug. > > Andras -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/HF00SiV5TqRTAEsRAgizAJ9Nll1j/8getokC/xNayUCozEI6bgCgmb14 0AogfCMwE2LCCf3jKzymoOk= =Y4vG -----END PGP SIGNATURE-----
Created attachment 2038 [details] Equivalent screenshot in PNG-format, much SMALLER and no distortion! ------- Additional Comment #10 From Mantia Andras 2003-07-21 23:11 ------- > Sorry? The JPEG image is 50KB. In PNG would be much bigger => it takes more > time to upload/view it. And I don't see any distortion that affects the > presentation of the bug. That is simply wrong. Here is an equivalent screenshot in PNG-format that is 15kB. I do not consider 15kB much bigger than 53kB. I actually consider it smaller. If you really care about bandwidth/appearance you should obviously use PNG. ---------------- Burn all JPEG screenshots!
well, I believe, ONE problem is too, that the selection is not realtime, e.g. when you select some text, you press down the left button, move the mouse, and than release the button, the text gets selected after having released the button - OR - if youve stopped moving the mouse. Selecting would look so much nicer if it would update the selected parts "live", that means: also while moving the mouse. This is how Mozilla and MSIE handle this, too. Cheers, Christian Parpart.
This bug appears to be fixed in CVS HEAD. The selection is working normally and the selection is real time. I don't know if there are any outstanding issues, but I don't know of any. Thank you to whomever fixed this...
> working normally and the selection is real time.
This looks fixed in CVS. Can anyone confirm?
Yes Leo Savernik's checkins look like fixed it.
it's working good now except when there is bidi text.
Comment on attachment 922 [details] Reproducible with this file Andras, please file your html testcases under text/html, and *not* text/plain. Otherwise I have to save them before I can view them
I checked, and everything seems to be working well. Andras, please check if it works for you, too, and close this bug then. Maor, if bidi doesn't work (which doesn't really surprise me), please file a bug of it's own with a meaningful testcase.
Subject: Re: Weird selection in KHTML > Andras, please file your html testcases under text/html, and *not* text/ plain. > > Otherwise I have to save them before I can view them Yes, I also noticed this. :-( BTW, I will verify if it's fixed for me or not today. Andras
Subject: Re: Weird selection in KHTML I can confirm that the bug is fixed in CVS HEAD, so I close it. Thanks for the developer who fixed it (Leo?). Andras
Subject: Re: Weird selection in KHTML I found a bit of misbehaviour in the Qt documentation. When I try to select the signature for find() in file:$QTDIR/doc/html/qtextedit.html#find I can select all the way up to the "l" in "bool" (return type) but no further.
Subject: Re: Weird selection in KHTML > I found a bit of misbehaviour in the Qt documentation. When I try to select > the signature for find() in file:$QTDIR/doc/html/qtextedit.html#find I can > select all the way up to the "l" in "bool" (return type) but no further. Confirmed. :-( Reproduceable steps: 1. start selecting from before the function signature ("bool") from up to down. The "bool" won't be selected until the next line " Finds the next occurrence..." is partially selected. 2. start the selection from "[virtual]" from right to left. You can't select the "bool" unless the mouse is moved up to "See also setFamily(), setCurrentFont(), and setPointSize()". 3. do as in 2) and don't release the mouse when the whole function definition is selected, but "undo" the selection (move the mouse to right). The "bool" string remains selected. The above errors can be reproduced also in other places in the QT docs. Should I reopen the bug report? Andras
Another weird selection thing going on happening with KDE-3.1.94 (3.2beta2), I /presume/ it's related. Never seen it happen with KDE-3.1.4... See attached html file, and try to select the body of the text, specifically going over paragraph breaks. (Attachment to follow)
Created attachment 3790 [details] http://news.bbc.co.uk/1/hi/technology/3335063.stm test case
This bug will stay fixed. The Qt documentation bug you're seeing is a repaint bug (which doesn't have anything to do with text selection), while the last one (attachment 3790 [details]) is a different known bug of its own. The difference between this bug and the other ones is that they don't break text selection but merely point out cosmetic glitches.