GNOME Bugzilla – Bug 672582
Fix selection behavior inside <iframe>
Last modified: 2013-03-20 13:41:49 UTC
In the last few releases, up to 3.3.92, Evo seems to be displaying some rather odd cursor behaviour. One I've seen a few times is demonstrated in the attached video, where I'm trying to click on some links in an HTML email. Instead, it seems to be selecting a chunk of text up to the point I'm clicking at. I've no idea why.
Video's too big to attach. Please find it at http://www.happyassassin.net/extras/shell-20120321-1.webm .
er, please don't attempt to impersonate me to the alumni office. that would be mean. :)
Might be a regression caused by the fix for bug #668215. Don't know what else it could be at our level. That bug fix was the only significant change to GtkHtml so far this year, and that was just swapping GtkStyle (deprecated) for GtkStyleContext.
seeing this too
*** Bug 672862 has been marked as a duplicate of this bug. ***
*** Bug 673531 has been marked as a duplicate of this bug. ***
I'm not sure if it's really the GtkStyle->GtkStyleContext change, we're seeing this on Ubuntu in Evo 3.2.3 with gtkhtml 4.2.2; so prior to the change.
Maybe try it with GTK+ 3.2, or an early 3.3. I suspect it'll work again.
I'm seeing this too. evolution 3.4.0.1, gtk+ 3.4.0, gtkhtml 4.4.0.
The same here in Mageia (evolution 3.4.0.1, gtk+ 3.4.0, gtkhtml 4.4.0)
*** Bug 674205 has been marked as a duplicate of this bug. ***
The issue doesn't occur with Gtk+ 3.2 and latest GtkHtml and Evolution.
Still observable with Evolution 3.4.1, GTK+ 3.4.1 and GtkHtml 4.4.1
With GTK+ 3.4.1 yes, but not with 3.2.x. I downgraded GTK to 3.2.3 and started evolution. Though themes are completely broken, the regressions does not show up in Evolution anymore. When I install gnome-themes-standard 3.2.x the themes are working again and evolution still works fine as it should. So it's not the theme, but GTK 3.4.x that causes this regression.
Reassigning to GTK+. Maybe a GTK+ developer can help figure out what broke.
Started a git bisect in gtk+ module. The oldest release I could compile with current glib is 3.3.12, which happens to show something that looks like correct behaviour. The oldest prepackaged version that I could find is 3.3.18, which shows the bad selection behaviour. Bisection should be only 7 steps, but I don't think I have time to finish it completely until upcoming sunday.
fcb58f3c83e8c525c6b2fb09eef9732a96714f08 is the first bad commit commit fcb58f3c83e8c525c6b2fb09eef9732a96714f08 Author: Alexander Larsson <alexl@redhat.com> Date: Sun Feb 19 11:55:22 2012 +0100 Don't unnecessarily clear background twice in no EXPOSE_MASK case We already clear in begin_paint, no need to do it again. In fact, this will get the wrong result if the background has alpha. :040000 040000 c7e5b84743c5bb4d5c0685e511bf4014456943b4 751668e7b80938ce0a86939b8dfd5dcc3f4f8fb7 M gdk
Too bad reverting that commit on top of 3.4.1 doesn't actually fix things here.
I bisected as well and got somewhere completely different :) Somewhere between 7f35708ceeef47cef6807a8a5edc86f4229e1a80 and 352fdc214aafdc8fcf163746a483164fd372fa5d, which is where the XI2 / multitouch branch landed. It seems likely that we are either missing an event that we used to receive or getting some extra events that are confusing things. The change in question comes between 3.3.16 and 3.3.17.
Experiencing this with Evolution 3.2.3 and GTK 3.4.1 (I wouldn't "me too", but the latest upgrade here didn't change the Evolution but did upgrade GTK from 3.2.x; just wanted to offer an additional data point). AfC
Reverting the following commit against the gtk-3-4 master makes the problem go away. commit f6393199beb812b81065890d6fec718ee16632f8 Author: Carlos Garcia Campos <cgarcia@igalia.com> Date: Fri Feb 11 13:43:56 2011 +0100 scrolledwindow: Kinetic scrolling support Kinetic scrolling is only done on touch devices, since it is sort of meaningless on pointer devices, besides it implies a different input event handling on child widgets that is unnecessary there. If the scrolling doesn't start after a long press, the scrolling is cancelled and events are handled by child widgets normally. When clicked again close to the previous button press location (assuming it had ~0 movement), the scrolled window will allow the child to handle the events immediately. This is so the user doesn't have to wait to the press-and-hold timeout in order to operate on the scrolledwindow child. The innermost scrolled window always gets to capture the events, all scrolled windows above it just let the event go through. Ideally reaching a limit on the innermost scrolled window would propagate the dragging up the hierarchy in order to keep following the touch coords, although that'd involve rather evil hacks just to cater for broken UIs.
All this bisection work is certainly helpful, thanks. Ultimatively, this is not purely a gtk bug though. Plenty of gtk apps scroll just fine with 3.4 and don't exhibit strange selection behaviour. So we need to identify what is different in the gtkhtml case to trigger this problem.
For the record, reassigning the bug to GTK+ wasn't meant to simply place blame but to seek assistance from GTK+ developers. I don't really have time to dig into this right now, nor am I familiar with what all changed in GTK+ with the kinetic scrolling support.
*** Bug 675058 has been marked as a duplicate of this bug. ***
I found a workaround under Arch Linux (bug 675058, which is marked as duplicate of this bug): downgrade the package "gtk3" from 3.4.1 to 3.2.3. This bug and also the "black on black" colour bug (bug 671437) are gone. It seems that the newer gtk3 versions are buggy.
*** Bug 675143 has been marked as a duplicate of this bug. ***
Created attachment 213130 [details] Testcase for GtkHtml The bug seems to only affect HTML mail .. and I notice that HTML mail is rendered using an iframe. The bug seems to be triggered when the selection is inside the iframe. I've attached a simple testcase which can be loaded using 'testgtkhtml' from the GtkHtml source tree, and this triggers the selection bug too.
Created attachment 213310 [details] [review] Patch for GtkHTML which fixes the issue Found a simple fix for the Evo bug. In GtkHTML, selection inside a <frame> is still broken, but it remains broken when the kinetic scrolling patch is reverted too so must be a separate issue..
Patch does not break anything when run against the gtk-3-2 branch
(In reply to comment #28) > Created an attachment (id=213310) [details] [review] > Patch for GtkHTML which fixes the issue Should probably go to a separate report as this one is assigned to gtk+ which also means gtk+ maintainers to review (and not Evolution maintainers).
Lets just move it back...
*** Bug 675356 has been marked as a duplicate of this bug. ***
(In reply to comment #28) > Found a simple fix for the Evo bug. > > In GtkHTML, selection inside a <frame> is still broken, but it remains broken > when the kinetic scrolling patch is reverted too so must be a separate issue.. Fix confirmed, thanks a ton for the patch! Committed for GtkHtml 4.5.2 and 4.4.2: http://git.gnome.org/browse/gtkhtml/commit/?id=7b7b37745d2f46914be314e4d7aef7a575529345 http://git.gnome.org/browse/gtkhtml/commit/?h=gnome-3-4&id=9ec36544203d4c1b98aa843c2c3ff0a4f725da68
Confirming the fix. Still, double/triple click selection doesn't work with HTML messages in the viewer. Should we file a new bug for that?
(In reply to comment #34) > Confirming the fix. Still, double/triple click selection doesn't work with HTML > messages in the viewer. Should we file a new bug for that? Probably not worth it at this point. No one is really maintaining GtkHtml and Evolution 3.5.1 has already switched to WebKit.
*** Bug 673456 has been marked as a duplicate of this bug. ***
*** Bug 675642 has been marked as a duplicate of this bug. ***
*** Bug 675709 has been marked as a duplicate of this bug. ***
*** Bug 676127 has been marked as a duplicate of this bug. ***
*** Bug 676552 has been marked as a duplicate of this bug. ***
*** Bug 677761 has been marked as a duplicate of this bug. ***
*** Bug 677773 has been marked as a duplicate of this bug. ***
*** Bug 677939 has been marked as a duplicate of this bug. ***
*** Bug 696194 has been marked as a duplicate of this bug. ***