GNOME Bugzilla – Bug 494986
Email viewer jumps to the start when clicking a link while in "caret mode".
Last modified: 2012-03-31 10:09:30 UTC
Please describe the problem: When the email viewer is in "caret mode" (triggered by F7), then clicking on a link in the email opens the web browser with that link but also causes the email viewer to move the view to where the caret is, which is often at the top of the page. Steps to reproduce: 1. Open an email larger then the viewer window that has links at the bottom. 2. Press F7 to switch to caret mode (or do nothing if Evolution is already in caret mode) 3. scroll down and click a link Actual results: The message viewer scrolls the view back to the beginning of the email Expected results: The message viewer should not change the view Does this happen every time? Yes Other information: Apparently this doesn't happen with "mailto" urls.
I can also reproduce in 2.22.1.
I am getting the same on 2.24.3, running on Ubuntu 8.10 VERY annoying if you spend a lot of time working through emails with lists of links in them. This DOES happen for mailto: links as well. It does happen only when in caret mode. Additionally, opening an HTML message either in preview pane or by opening it: while contents are still loading, if you attempt to scroll down through message, it keeps jumping back to the top, until all embedded contents have finished loading.
*** Bug 421746 has been marked as a duplicate of this bug. ***
*** Bug 528830 has been marked as a duplicate of this bug. ***
*** Bug 500624 has been marked as a duplicate of this bug. ***
*** Bug 508072 has been marked as a duplicate of this bug. ***
Created attachment 129157 [details] [review] proposed gtkhtml patch for gtkhtml; This fixes both URL clicking and animated gifs drawing.
*** Bug 307005 has been marked as a duplicate of this bug. ***
*** Bug 329509 has been marked as a duplicate of this bug. ***
Seems fine for trunk, hmm even post trunk.
I confirm it is fixed in trunk. I'm on nightly builds.
(In reply to comment #11) > I confirm it is fixed in trunk. I'm on nightly builds. Strange, the patch isn't in yet.
(In reply to comment #12) > (In reply to comment #11) > > I confirm it is fixed in trunk. I'm on nightly builds. > > Strange, the patch isn't in yet. > I just tested again. Opened one html mail, enabled caret mode by F7 and scrolled down. Clicked the link which opened in firefox. Checked evolution, cursor was at same position.
(In reply to comment #13) > I just tested again. Opened one html mail, enabled caret mode by F7 and > scrolled down. Clicked the link which opened in firefox. Checked evolution, > cursor was at same position. with cursor, do you mean that blinking thin thing? To reproduce this properly, place cursor somewhere in the top, then scroll down by the mouse, keeping cursor out of actual view. When you'll click the link by mouse, and go back to Evolution, you'll see the cursor blinking and centered in the view, scrolled back to top. With this patch it'll move view to show the cursor.
(In reply to comment #14) > with cursor, do you mean that blinking thin thing? To reproduce this properly, > place cursor somewhere in the top, then scroll down by the mouse, keeping > cursor out of actual view. When you'll click the link by mouse, and go back to > Evolution, you'll see the cursor blinking and centered in the view, scrolled > back to top. With this patch it'll move view to show the cursor. > Oh yes focus is moved to where cursor was. I'll test again when patch is committed.
gtkhtml had been branched yesterday. Committed to trunk. Committed revision 9197.
Err, I just realized, when selecting text it doesn't move scroll :( I'm working on a solution.
Created attachment 132453 [details] gtkhtml patch for gtkhtml; The follow up patch to fix the above mentioned issue. Just for a reference.
Committed to trunk. Committed revision 9202.
*** Bug 588480 has been marked as a duplicate of this bug. ***
Downstream bug report claims this still occurs in Evolution 2.28. Reopen for reinvestigation. Not sure it's worth spending too much time on this since the WebKit transition will likely address it. But if a solution can be found easily, all the better.
Downstream bug report: https://bugzilla.redhat.com/show_bug.cgi?id=550510
The most I see is only once, when I turn on caret mode for the first time, otherwise it seems to work fine for me.
Created attachment 151179 [details] [review] gtkhtml patch for gtkhtml; OK, I got finally few more steps what to do to trigger it. This is the result.
Created commit 198e349 in gtkhtml master (3.29.6+) Created commit 0a4b841 in gtkhtml gnome-2-28 (3.28.3+)
*** Bug 529271 has been marked as a duplicate of this bug. ***
*** Bug 582582 has been marked as a duplicate of this bug. ***