delay if I click on link in mail message (should open in browser immediately)



17 years ago
10 years ago


(Reporter: tquas, Assigned: mscott)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




17 years ago
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

Comment 1

17 years ago
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
Ever confirmed: true

Comment 2

17 years ago
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)

Comment 3

17 years ago
*** Bug 144963 has been marked as a duplicate of this bug. ***

Comment 4

17 years ago
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

Comment 5

17 years ago
*** Bug 159991 has been marked as a duplicate of this bug. ***


17 years ago
Blocks: 134421

Comment 6

16 years ago
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
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
Keywords: perf

Comment 8

16 years ago
This also causes error messages to be displayed in the mail window instead of a
browser window - see bug 157527
Blocks: 157527


16 years ago
QA Contact: huang → gchan

Comment 9

16 years ago
*** Bug 190366 has been marked as a duplicate of this bug. ***

Comment 10

16 years ago
FYI 164710 is the same as this bug.

The problem also exists when you open a new Browser window or tab.

Comment 11

16 years ago
*** Bug 164710 has been marked as a duplicate of this bug. ***

Comment 12

16 years ago
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.

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.

Comment 13

16 years ago
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.
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.

Comment 15

16 years ago
Agreed, this is fixed, so are the two dependents.
Any other test cases? One is other protocols eg. news:// and mailto:// and ??

Comment 16

16 years ago
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

Comment 17

16 years ago

*** This bug has been marked as a duplicate of 199360 ***
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.