GNOME Bugzilla – Bug 304937
Clicking a link in an email message causes view to drop to bottom of the message
Last modified: 2005-05-25 02:42:33 UTC
Please describe the problem: When clicking an html link in a message, the view automatically scrolls down to the bottom of the message. As a result I need to scroll back up to see the rest of the message Steps to reproduce: 1. Receive an email that includes an html link 2. Click the link in the preview 3. The message view scrolls to the bottom of the message Actual results: The view of the message scrolls to the bottom of the message Expected results: No change in message display Does this happen every time? Yes Other information:
is this an internal link (a so-called anchor) or an external link to a http- address? does this happen with every mail you receive that has links in it? please add more information, if possible also post the source of such a html link; thanks.
I'm not sure if I've ever seen an internal link in an email, so I can't comment on if they are affected as well. But I am seeing this occur for all external links. The Bugzilla email would have done it, if it was longer than a few lines (it has nowhere to scroll to). As for mail message source, I'm not sure how to obtain this from Evo. I've pasted a sample message below after changing my view to show email source - is that sufficient? If not, plese let me know how to grab the details you're looking for. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Hi Luis ~ Good questions, I had done something similar to this a while back. It's not really the perfect design, but it was more to show how you could get away from dialogs that offer somewhat blind choices instead of just laying out the options. This was just a quick idea for getting rid of the popup dialog for a url not found http://www.gnome.org/~clarkbw/designs/url-not-found/url-not-found.html Similar to this "not found", if you queried NetworkManager for network status and available network options when the system is offline you could give options for getting online and continuing to a link that someone was trying to open. So like your scenario, the last bit is * $APP shows your connection status via the menu - This status menu also allows you to connect * $APP then goes ahead and does what you were trying to do There are two types of systems to consider here, active and background connections. Active case: This is the epiphany scenario, or when you're trying to IM someone in Gossip. You need active feedback and a way to fix network connections that are not working. This case is primarily around when you're actively using a system that relies on the network, whether it be IMing, Browsing, or Emailing (i.e. what's expected to happen isn't happening). Background case: This is the evolution scenario, checking for email while you're doing other things. You don't want active feedback, you want the application to just keep trying and notice when the network goes up or down. This case is primarily around just being aware of network status and doing whatever possible to do the right thing in light of the volatility. Applications need to understand if their network activity are active or background connections and react appropriately. For the active connection I would suggest giving the networking options somehow in the dialog instead of simply the "Try Again"/"Configure Network". This isn't to say that those might not be valuable options, but they are really manual switches when we have enough context information to be more automatic. Being more automatic would mean when the Epiphany network problems page appears and you choose a network that works, ephy just goes to the site automatically once the connection is established without you asking you to "Try Again". Anyway, that's how I see it right now. Cheers, ~ Bryan On Thu, 2005-05-19 at 13:56 -0400, Luis Villa wrote: > Let me put it another way by describing the scenario I'm envisioning. > * I go offline for some reason. > * I don't realize it. (You're right that this part is probably > NetworkManager's and/or a good notification framework's problem.) > * I go to Gossip and try to use it. What happens then? _______________________________________________ Usability mailing list Usability@gnome.org http://mail.gnome.org/mailman/listinfo/usability
I am unable to reproduce this problem in the following versions of evolution: evolution-data-server-1.2.2.0.200505210301-0.snap.novell.0.1 evolution-webcal-2.2.1.0.200505210301-0.snap.novell.0.1 evolution-2.2.2.0.200505210301-0.snap.novell.0.1 When I click on any link that is present in a mail message the link gets opened in the browser immediately and the mail message stays in the same position before and after the link is clicked. Any more information on the steps followed would be useful.
*** This bug has been marked as a duplicate of 272708 ***
Bug 272708 is a duplicate. I confirmed by turning off caret mode and this problem does not occur. However, I have also found some email messages that do not exhibit this problem at all, even when in caret mode. For example, the AMG New Release Newsletter email. Once I choose to load images, I can click on any link in there and no problems are seen even if caret mode is active. I don't have any other emails that I choose to load images with that have links for testing, but perhaps it is safe to say that this occurs when in caret mode, but not after you have chosen to load images? Perhaps it has something to do with displaying in plain text versus an html-rich mode? I'm not sure how Evo handles this, or even decides which mode to display in. And now for the strangest thing of all. After disabling caret mode then re-enabling for an opened message, I cannot reproduce this problem at all with any message, caret mode or not. Toggling that feature seems to have resolved this bug. I have closed and relaunch Evo and I still cannot reproduce even with the message I included as a demonstration. Something funny going on, and I can't provide much more info than this.