I've noticed that often when you drag down to select a block of text and then move back up to de-select some of it, sometimes the newly-deselected text disappears. It only seems to happen on multi-line text and usually only if the start of the text selection is above (or on the boundary of) the affected element.
Created attachment 21371
I should also note that I don't know for certain whether this is only a QtWebKit issue, but that's the only one that I had available to test.
OK, so I compiled GtkWebKit and the issue also shows up there, so it doesn't appear to be specific to the Qt port. Changing component. If 'Text' is not correct, feel free to re-assign to the correct component.
Confirmed with Alexey Proskuryakov, this does not affect the Mac port.
Got the problems with GtkLauncher but NOT with midori on the same webkitgtk-code.
(In reply to comment #5) > Got the problems with GtkLauncher but NOT with midori on the same > webkitgtk-code. > I get the problem with Midori too. Maybe your experience was a fluke?
(In reply to comment #6) > I get the problem with Midori too. Maybe your experience was a fluke? No, I tested it several times on different pages. I don't run in to problems using midori the latest trunk and wbkit with soup,freetype. I made it like in the movie. I got the problems on GtkLauncher but not with midori. Could be because on midori the selection/marking of objects and texts don't work correctly at the moment.
Midori solved the problems with selection, but the described bug does still not apear on Midori. I tried it with epiphany/webkit with out any problems. Seems only a problem with GtkLauncher on WebKitGtk.
The bug does not appear on WebKit shipped with Qt 4.4 but does appear on QtWebKit from webkit.org. I ran a git bisect on code.staikos.net and it pointed to this changeset: http://trac.webkit.org/changeset/32660 Investigation continues.
Created attachment 21528 [details] Patch that fixes the text disappearance on selection changes Here's a patch that fixes the disappearing text issue on both Qt and Gtk. I don't necessarily think that it's the *correct* solution since I think what it is doing is a) drawing all text in the run as unselected b) later any selected text is drawn overtop of it There's at least a couple problems with this simplistic fix: - we're doing unnecessary work by drawing text and then drawing over it - In many cases, text has a different style when selected and unselected. For example, links often have underlines when they're not selected, but are not supposed to be underlined when they're selected. So if you apply this patch you'll see that when you select a link, it will improperly have an underline in the unselected color.
Created attachment 21533 [details] Test case Sample html file with 2 paragraph where the issue can be reproduced.
You can reproduce the bug on Mac, too, if you make it take the "paint selection separately" code path, for example by adding this to the test case: <style> ::selection { background-color: red; color: white; } </style>
Created attachment 21538 [details] Fix Fix discussed with Mitz Pettel.
Created attachment 21539 [details] Fix Fixed bad paste and improved ChangeLog
Comment on attachment 21539 [details] Fix r=me. It would be nice to have a pixel test for this, but that would have to be made on Mac OS X.
Created attachment 21547 [details] Pixel test for Mac OS X
Comment on attachment 21539 [details] Fix Landed in <http://trac.webkit.org/changeset/34414>, so clearing the review flag. Leaving the bug open pending review of the regression test.
Test landed in <http://trac.webkit.org/changeset/34430>.