Version: 4.3.72 (KDE 4.3.72 (KDE 4.4 >= 20091015)) (using 4.3.75 (KDE 4.3.74 (KDE 4.4 >= 20091102)), compiled sources) Compiler: gcc OS: Linux (i686) release 2.6.32-rc3-git1 Sometimes (on some pages) selecting text doesn't select what it appears to, ie. real selection is shifted some characters from what is highlighted. For example, go to http://ifdb.tads.org/viewgame?id=2fo0u9hcpxsf53t1#memberReviews and try to select some (not all) text from the "A credit reel for AAS" review. Selecting, say, "opportunity" yields "pportunity " in selection for me. This shift varies throughout the text.
Looks like a duplicate of an issue that is known already. *** This bug has been marked as a duplicate of bug 166241 ***
No, it's not. This hasn't to do anything whatsoever with word boundary detection.
Sorry that I did something wrong here - I was not near my trunk build this afternoon and only verified that your test URL shows exactly the same behaviour as described in bug 166241 in KDE <= 4.3. Looking at the HTML source also shows that there are two spaces in front of the sentence containing "opportunity", which is just what triggers that bug. In trunk, the test case of bug 166241 actually shows the behaviour you describe, so it seems that bug 166241 was replaced by this bug... > No, it's not. This hasn't to do anything whatsoever with word boundary > detection. I'm not really an expert, but it seems to me that the problem you've found might be due to word boundary detection being broken in a different way than before.
(In reply to comment #3) > Sorry that I did something wrong here - I was not near my trunk build this > afternoon and only verified that your test URL shows exactly the same behaviour > as described in bug 166241 in KDE <= 4.3. Looking at the HTML source also shows > that there are two spaces in front of the sentence containing "opportunity", > which is just what triggers that bug. > > In trunk, the test case of bug 166241 actually shows the behaviour you > describe, so it seems that bug 166241 was replaced by this bug... > > > No, it's not. This hasn't to do anything whatsoever with word boundary > > detection. > > I'm not really an expert, but it seems to me that the problem you've found > might be due to word boundary detection being broken in a different way than > before. Ah, I see. I'd say it's due to bad fixing of the other problem. I don't know KHTML internals, but it'd seem that bug 166241 was fixed by introducing character shift, but it has only been applied to buffer used in highlighting and not buffer used in selection (if that makes any sense), which made the two buffers out of sync, hence this bug. (Substitute for 'buffers' whatever model KHTML uses to store and manipulate the content.)
Is this a duplicate of bug #213246 ?
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