If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

sending mail hangs in message compose when entering several recipients

VERIFIED FIXED

Status

MailNews Core
Composition
--
critical
VERIFIED FIXED
15 years ago
9 years ago

People

(Reporter: Mitch, Assigned: Brian Ryner (not reading))

Tracking

({hang, regression})

Trunk
x86
All
hang, regression

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
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.
(Reporter)

Comment 1

15 years ago
Created attachment 106349 [details]
starc trace from hanging mozilla process - infact it is looping
(Reporter)

Comment 2

15 years ago
Forgot to add that this behavior happens on Solaris and Linux.

Updated

15 years ago
Keywords: hang

Comment 3

15 years ago
Wfm Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021113

Comment 4

15 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

15 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).
Seth, can you take a look at this problem? my Linux build is currently dead :-(

Comment 7

15 years ago
regression seems to be between linux trunk builds 2002110721 and 2002110904
Keywords: regression

Comment 8

15 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

15 years ago
regression between 2002110808 and 2002110821
checkin for bug 124990 might be a suspect
*** Bug 180513 has been marked as a duplicate of this bug. ***
os=all (win2k is also affected)
OS: Linux → All
*** Bug 180513 has been marked as a duplicate of this bug. ***

Comment 13

15 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
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
*** Bug 180469 has been marked as a duplicate of this bug. ***

Updated

15 years ago
Summary: sending mail hangMessage compose when entering several recipients → sending mail hangs in message compose when entering several recipients
cc'ing bryner. Brian, any idea?
(Assignee)

Comment 17

15 years ago
Created attachment 106829 [details] [diff] [review]
patch

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.
(Assignee)

Comment 18

15 years ago
taking
Assignee: ducarroz → bryner
Status: ASSIGNED → NEW

Comment 19

15 years ago
Comment on attachment 106829 [details] [diff] [review]
patch

r=saari
(Assignee)

Updated

15 years ago
Attachment #106829 - Flags: superreview?(jst)
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

15 years ago
checked in.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 22

15 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

15 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

15 years ago
*** Bug 181703 has been marked as a duplicate of this bug. ***
*** Bug 183896 has been marked as a duplicate of this bug. ***
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.