Closed
Bug 180285
Opened 22 years ago
Closed 22 years ago
sending mail hangs in message compose when entering several recipients
Categories
(MailNews Core :: Composition, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: Mitch, Assigned: bryner)
References
Details
(Keywords: hang, regression)
Attachments
(2 files)
4.10 KB,
text/plain
|
Details | |
1.76 KB,
patch
|
jst
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021115 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021115 Recent mozilla builds (since 20021112 to today) hangs 100% reproduceably when pasting an email address in the second (and above) reciepient address input box in the composer. Stack trace is attached. After about 5 minutes a dialog is popped up saying "A script on this page is causing mozilla to run slowly. If it continues to run, your computer may become unresponsive. Do you want to abort the script ? Ok Cancel." Note, there is NO javascript running in the browser window (it is blank) and there is no LDAP lookup for addresses enabled ! Reproducible: Always Steps to Reproduce: 1. Click forward to forward an existing email 2. Paste (don't type) an address in the first "To:" input box of the forwarded mail 3. Paste (don't type) an address in the second "To:" input box of the forwarded mail 4. Mozilla hangs for about 5 minutes 5. Popup dialog as described above Actual Results: Mozilla hangs for about 5 minutes Expected Results: Not hang, but accept typed/pasted addresses.
Forgot to add that this behavior happens on Solaris and Linux.
Comment 3•22 years ago
|
||
Wfm Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021113
Comment 4•22 years ago
|
||
Yup, confirmed, 20021113 Linux/x86. Doesn't need to be a Forward; same happens for Reply.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 5•22 years ago
|
||
I should have noted in comment 4 above that I am using LDAP address completion (whcih is working fine for normally typed addresses).
Comment 6•22 years ago
|
||
Seth, can you take a look at this problem? my Linux build is currently dead :-(
Comment 7•22 years ago
|
||
regression seems to be between linux trunk builds 2002110721 and 2002110904
Keywords: regression
Comment 8•22 years ago
|
||
with a debug build, I get this: JavaScript error: line 0: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMEventTarget.dispatchEvent]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://global/content/bindings/listbox.xml#listitem.selected (setter) :: onset :: line 8" data: no]
Comment 9•22 years ago
|
||
regression between 2002110808 and 2002110821 checkin for bug 124990 might be a suspect
Comment 10•22 years ago
|
||
*** Bug 180513 has been marked as a duplicate of this bug. ***
Comment 12•22 years ago
|
||
*** Bug 180513 has been marked as a duplicate of this bug. ***
Comment 13•22 years ago
|
||
this is a regression from bug 124990
Blocks: 180455
Summary: sending mail hangs in recent cvs builds 2002111[2345] when pasting in second reciepient address box → sending mail hangs in recent builds when pasting in second reciepient address box
Comment 14•22 years ago
|
||
The easy way to reproduce this problem (on windows) is: 1) Open a message compose window 2) enter an email address (don't press the return or tab key) 3) click on the second address row, that will create a new row 4) click on the third address row ==> Hang while processing a mouse up event Just before the hang, I get the following JS error on the console, i don't know if it's related: JavaScript error: line 0: uncaught exception: [Exception... "Component returned failure code: 0x8 0004005 (NS_ERROR_FAILURE) [nsIDOMEventTarget.dispatchEvent]" nsresult: "0x8000 4005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://global/content/binding s/listbox.xml#listitem.selected (setter) :: onset :: line 8" data: no]
Status: NEW → ASSIGNED
Summary: sending mail hangs in recent builds when pasting in second reciepient address box → sending mail hangMessage compose when entering several recipients
Comment 15•22 years ago
|
||
*** Bug 180469 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Summary: sending mail hangMessage compose when entering several recipients → sending mail hangs in message compose when entering several recipients
Comment 16•22 years ago
|
||
cc'ing bryner. Brian, any idea?
Assignee | ||
Comment 17•22 years ago
|
||
This fixes at least the case that ducarroz gave steps to reproduce, and hopefully fixes the other cases as well. There was an unintentional behavior change introduced that caused dispatchEvent to throw an exception if the element was not in a document. This patch fixes that.
Comment 19•22 years ago
|
||
Comment on attachment 106829 [details] [diff] [review] patch r=saari
Assignee | ||
Updated•22 years ago
|
Attachment #106829 -
Flags: superreview?(jst)
Comment 20•22 years ago
|
||
Comment on attachment 106829 [details] [diff] [review] patch + // Do nothing if the element isn't in the document + if (!document) + return NS_OK; - nsCOMPtr<nsIPresShell> shell; - document->GetShellAt(0, getter_AddRefs(shell)); + // Obtain a presentation context + PRInt32 count = document->GetNumberOfShells(); + if (count == 0) + return NS_OK; This is IMO pointless (I know you didn't write this code), I see no reason why you couldn't just ask for the shell at index 0, and if it's not there you get a null pointer back (the implementations are cool with this, as they should be), and then you know there are no shells in the document. + nsCOMPtr<nsIPresShell> shell; + document->GetShellAt(0, getter_AddRefs(shell)); IOW, remove the call to GetNumberOfShells() above and add a null check here. Less code, faster code, and you get the same end result. sr=jst
Attachment #106829 -
Flags: superreview?(jst) → superreview+
Assignee | ||
Comment 21•22 years ago
|
||
checked in.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 22•22 years ago
|
||
Using trunk builds 20021121 on winxp linux and mac osx and scenario in comment 14 this is fixed. Verified
Status: RESOLVED → VERIFIED
Comment 23•22 years ago
|
||
Hi All, The nightly link on the Mozilla.org is still pointing at 1.3.1.20021120008 (even thought it is the 21st.) I downloaded my 20021121 directly from ftp://ftp.mozilla.org/pub/mozilla/nightly/2002-11-21-08-trunk I actully tested 2108 thinking it was 21xx and was VERY DISSAPOINTED. But, fortunately, it was a false alarm. :-) --Tony
Comment 24•22 years ago
|
||
*** Bug 181703 has been marked as a duplicate of this bug. ***
Comment 25•22 years ago
|
||
*** Bug 183896 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•