Summary: | [regression][testcase] Double-click word selection in Konqueror often selects multiple words or only a part of a word | ||
---|---|---|---|
Product: | [Applications] konqueror | Reporter: | Saurav Sarkar <saurav.sarkar> |
Component: | khtml | Assignee: | Konqueror Developers <konq-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | amantia, aros, divided.mind, esigra, finex, frank78ac, germain, jem, kollix, mtadeunet, tsjoker |
Priority: | NOR | ||
Version: | SVN | ||
Target Milestone: | --- | ||
Platform: | Ubuntu | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: |
Double-click word selection in Konqueror
Double-click word selection in Konqueror Double-click word selection in Konqueror Simple testcase. Improved test case convert Selection's DOM offsets to Rendered offsets, as this is what we need here. |
Description
Saurav Sarkar
2008-07-10 17:36:16 UTC
Created attachment 26014 [details]
Double-click word selection in Konqueror
Created attachment 26015 [details]
Double-click word selection in Konqueror
Created attachment 26016 [details]
Double-click word selection in Konqueror
Thanks for the bug report. I can confirm this with SVN trunk rev. 830161. Konqueror 4.0.5 on Kubuntu 8.04 seems to work fine. Created attachment 26020 [details]
Simple testcase.
The funny thing is that double-click selection works fine for me in this bug report page, but not in the test case. Needs further analysis... Created attachment 26050 [details]
Improved test case
OK, I think I know what's going on. Extra spaces in front of words make text
selection go wrong, i.e., spaces at the beginning of a line or multiple spaces
between words. These spaces are not shown, but the text selection algorithm
does not take this into account.
Konqueror 4.0.5 still works OK for me.
I browsed through the code and got the impression that this regression was probably caused by commit 809453: http://websvn.kde.org/?view=rev&revision=809453 I'm CC'ing the developer who committed it. I verified that it still works in 809421 and that the bug is there in 809459. I was unable to build the revisions in between. By the way, I had to do my testing with an offline copy of the testcase (after doing "svn up --revision ..." and building khtml and konqueror) because web browsing didn't work: I got a page saying "The requested operation could not be completed - Unexpected Program Termination..." in Konqueror. If anyone knows what I did wrong, please let me know. I've looked a bit further into this. I have to stop now, so I'm posting my intermediate results here, just in case anyone else has good ideas: The selection seems to be done in Selection::validate() [granularity == WORD] in kdelibs/khtml/xml/dom_selection.cpp. This function calls findWordBoundary() from kdelibs/khtml/misc/helper.cpp. The parameter 'position' of this function should probably be the index in the array 'chars' which corresponds to the clicked character. This is not the case if there are extra spaces in front of the corresponding word. This means that the calculation of this position goes wrong. This calculation takes place in KHTMLPart::handleMousePressEventDoubleClick() in kdelibs/khtml/khtml_part.cpp in the line Position pos(innerNode.handle()->positionForCoordinates(event->x(), event->y())); *** Bug 173413 has been marked as a duplicate of this bug. *** I've just reproduced the selection problem using current trunk ( ~ 4.2beta1) This bug has been reported on Launchpad: https://bugs.edge.launchpad.net/kdebase/+bug/301707 Binary package hint: konqueror Hi when I double-click on a word in Konqueror I have a strange behavior. Please check the attachments( png's ) and their comments (screenshot) double-click on 'b' of the 'bug' word (16.2 KiB, image/png) http://launchpadlibrarian.net/19906687/screen1.png (screenshot) double-click on 'o' of 'one' (15.3 KiB, image/png) http://launchpadlibrarian.net/19906698/screen2.png *** Bug 185055 has been marked as a duplicate of this bug. *** I'm not able to reproduce it anymore using trunk and qt-copy. (r928825) (In reply to comment #14) > I'm not able to reproduce it anymore using trunk and qt-copy. (r928825) I can't confirm: trunk rev. 929171 with Qt 4.5.0-rc1 is still buggy for me :-( With Qt 4.5.0 and KDE 4.2.2 the bug is still there. I can also confirm that the bug is still there on KDE 4.2.2 and Qt 4.5.1. *** Bug 196272 has been marked as a duplicate of this bug. *** As described in comment#9 the problem is with collapsed spaces in the rendering tree. But it's actually a general problem that code should be really clear when DOM or rendered offsets are needed. As part of my SoC project (improved editing) I've addressed this issue and separated positions logic into khtml::RenderPosition and DOM::Position classes with rendering and DOM trees in mind. The code will be merged a bit later in trunk (for 4.4). *** Bug 204866 has been marked as a duplicate of this bug. *** *** Bug 216092 has been marked as a duplicate of this bug. *** It looks like text selection is broken in a different way in trunk: If you select a word using a double-click in the test case, the highlighting works OK (at least in the 2nd and 3rd line - in the 1st line, something still goes wrong), but the text that is actually copied to the clipboard is wrong (no matter how you do the selection, see bug 216092). Created attachment 38649 [details]
convert Selection's DOM offsets to Rendered offsets, as this is what we need here.
(hmm, shouldn't Selection offer a direct interface to rendered offsets?
I fail to see in what case Selection is *not* about the Rendered string?)
SVN commit 1056420 by ggarand: . convert the Selection's DOM offsets to Rendered offsets before using them on the rendered string (#166241, #216092) . use slow font width algorithm when drawing selection for more accurate placement (#213246) BUG: 166241 BUG: 216092 BUG: 213246 M +10 -7 khtml_part.cpp M +3 -3 rendering/render_text.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1056420 |