From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020310 BuildID: 2002031008 When I click on a link in a mail message, the mail window tries to look up the page instead of delegating it immediately to the browser window. This can cause longer delays during which the entire applciation is not usable. I guess it would be better to leave the mail window operational by delegating the page lookup to the browser window. Reproducible: Always Steps to Reproduce: 1. Send yourself an e-mail containing a link (ideally to a page that is not in the cache, yet better has not been looked up by DNS 2. Open the message 3. Click on the link Actual Results: Enjoying the enforced wait... :-( Expected Results: Mail window stays operations, browser window takes over control of page lookup
I've been experiencing this as long as I remember using mozilla. I never filed a bug because I thought considering how annoying it is, a bug must have been filed already. I performed something in the order of 10 different searches only not to find anything similiar to this. I'm going to confirm this
Status: UNCONFIRMED → NEW
Ever confirmed: true
Has also happened on Windows 98 as long as I can remember. It seems strange to me that Networking /allows/ one window to start loading a page and another window to display it.
Severity: enhancement → normal
OS: Linux → All
Hardware: PC → All
Summary: delay if I click on link in mail message → delay if I click on link in mail message (should open in browser immediately)
*** Bug 144963 has been marked as a duplicate of this bug. ***
Actually, it's worse than I expected first. If you start another action in the mail window during the page lookup, the lookup gets interrupted and the page will never be loaded. Seen with 1.0RC2 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020310 BuildID: 2002031008
Priority: -- → P3
*** Bug 159991 has been marked as a duplicate of this bug. ***
This is extra bad because if you click on a slow link, you cannot do anything in the MailNews window until the link is loaded. If you do something, like go read another message, the loading of the link is terminated. Effectively, clicking a link in MailNews means that all activity in MailNews must be halted while Mozilla loads the page. Keywords --> nscatfood
i've been seeing for a long time and my impression is that it became worse lately. The new feature "open link in a new tab" loads the URL immediately whcih seems to indicate that it uses a different (better !) method to communicate with the browser window. Addinf perf keyword
This also causes error messages to be displayed in the mail window instead of a browser window - see bug 157527
*** Bug 190366 has been marked as a duplicate of this bug. ***
FYI 164710 is the same as this bug. The problem also exists when you open a new Browser window or tab.
*** Bug 164710 has been marked as a duplicate of this bug. ***
This same sort of behavior is evident on selecting a newsgroup on a slow server also. The group name is not highlighted in the folder pane until AFTER the server is contacted. This can be a significant delay. I have watched several users become frustrated when Mozilla does not update the UI immediately. They think that it is ignoring their clicks. Is there a more general bug about updating the UI BEFORE anything else happens? If not, I will make one. <evangelism> It is critical that users are made aware that SOMETHING is happening when they issue a command, and immediately at that. I can't think of anything that should have a higher scheduling priority than updating the UI to reflect user input. </evangelism>
I think this bug (130671) and the bugs it blocks (bug 157527, bug 134421) are dups of bug 199360, which is fixed.
Comment #13 Agree, it seems fixed in 1.4b To test: 1. send to yourself and url that does not resolv (ie. http://www.qweqweqweqwe.com) 2. click that link in MailNews What happend: 1. a navigator window is opened before the dns lookup is done 2. after a few seconds, a dns timeout occurs and you see the error. This is what is expected. For me it is OK to close the bug.
Agreed, this is fixed, so are the two dependents. Any other test cases? One is other protocols eg. news:// and mailto:// and ??
news:// seems to work alright, either opening the mail/news window or bringing it to the front, and offering to subscribe to the group if not already present. mailto:// still works, that always has I guess ftp:// works ok
*** This bug has been marked as a duplicate of 199360 ***
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.