GNOME Bugzilla – Bug 375912
Message Window opens scrolled to end of the message
Last modified: 2007-04-03 09:53:33 UTC
Please describe the problem: When a message is opened in its own window, the end of the message appears rather than the beginning. In other words, it is as if you have immediately scrolled down to the end of the message. This only seems to occur for message content-type text/plain. Multi-part messages display okay (i.e. you see the top of the message). Of course if the message is so short that it naturally fits in the window anyway, there is no problem. Steps to reproduce: Open a message window, when the message is of type text/plain. Actual results: You see the message, but scrolled to the end Expected results: Should see the top of the message Does this happen every time? Yes, in 2.8.x onwards Other information:
Created attachment 77542 [details] [review] Add a notify filter to evolution-data-server This is a proof of concept patch - adding a 'notify' filter-action to evolution-data-server. This patch must be used in conjunction with a patch to evolution itself to allow this filter-action to be used. This patch just creates the code for the filter-action - it is then up to the user to manually add a filter that uses this action to their setup (this is a temporary measure - eventually the filter would become 'builtin/hardcoded' so it is always activated.
Created attachment 77543 [details] [review] Make Evolution mailtool do new new mail notification on notify filter-action This patch is a proof of concept, and must be used in conjunction with the patch to evolution-data-server. It adds the code for the new notify filter-action, and adds this new filter-action to the list of known actions in Evolution (so it appears in the edit filters UI). It removes the new mail notification code from mail-folder-cache.c, and puts (more or less the same code) in mail-session.c. accessed via the callback for the new notify filter-action. The code keeps the throttling mechanism from the original code, i.e. it only triggers the code if an elapsed time has past, and the tool has become idle. I increased the elapsed time to 30 seconds (it was previously 5, which seemed too small). Note: I currently make no attempt to pass the proper uri for the mail folder to the new-mail-notification event. Since the uri can't be NULL (I don't think), I have just used a 'dummy' uri for now. This doesn't matter, since the folder-name in the dbus message isn't used to my knowledge. With these two patches in place, the user can then manually add a filter on INCOMING mail: I suggest filter on 'status != read' and set the action to notify. You should then get notification (play beep or sound) and dbus message only when new mail arrives - but not when junk arrives (the filter is not run if the mail is already seen as junk). I have tested this with imap so far - I intend to test with mbox and pop, but can't test MS-exchange or hula.
Please ignore previous two patches - added to wrong bug-id. Sorry.
Karl, a lot of times this just means that you've accidentally enabled Caret Mode (View -> Caret Mode, or F7). The scrolling behavior is a long-standing bug in GtkHtml, and unfortunately Evolution's main window gives no visual indication that you've enabled this mode. I wonder if we ought to just disable and hide the Caret Mode feature until we get it working right. This bug bites many, many users.
Marking the patches as obsolete since they were attached to the wrong bug.
Indeed - turning off Caret mode removes the bad behaviour! Rather than removing Caret mode completely (at least until GtkHtml is fixed), why not simply turn it from being a global setting to a per message setting. In other words have messages always display initially in non-caret mode, and then the user can turn it on for that message (just as once viewing a message a user can then choose to see full headers - but that choice is not 'sticky').
*** This bug has been marked as a duplicate of 374869 ***