Bug 511109

Summary: Message display scrolls to top when link clicked
Product: [Fedora] Fedora Reporter: Matthew Saltzman <mjs>
Component: gtkhtml3Assignee: Matthew Barnes <mbarnes>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 11CC: mbarnes, mcrha
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-07-13 19:49:23 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Matthew Saltzman 2009-07-13 17:25:52 UTC
Description of problem:
When I click an embedded link in the middle of a long message or digest, the link opens in a browser, but the message scrolls back to the top and I have to manually scroll back down to where I was reading.

Version-Release number of selected component (if applicable):
evolution-2.26.3-1.fc11.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Read a long message, scroll the top of the message out of the display window
2. Click a link
3.
  
Actual results:
Message scrolls back to top

Expected results:
Message display window does not change

Additional info:
I use the wide view, with the message window at the right of the display.

This has happened for several versions, back to at least F9.

Comment 1 Matthew Barnes 2009-07-13 17:41:52 UTC
Check whether you have Caret Mode enabled:

   View -> Caret Mode (F7)

Disable it if you do.  It causes all sorts of weird glitches like this.

Comment 2 Matthew Saltzman 2009-07-13 18:59:43 UTC
OK, yes I did have it on.  Turning it off stops the behavior.

What's it supposed to do?

Comment 3 Matthew Barnes 2009-07-13 19:49:23 UTC
It's an accessibility feature in GtkHTML, but it's never really worked right.
And to be honest, it probably won't be fixed before we switch to WebKit, which hopefully handles it better.

Regardless, I sent it upstream so it's at least filed:
http://bugzilla.gnome.org/show_bug.cgi?id=588480