180285 - sending mail hangs in message compose when entering several recipients

Status: VERIFIED FIXED

(MailNews Core :: Composition, defect)

Description

[Mitch]

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.

Comment 1

[Mitch]

Attachment: starc trace from hanging mozilla process - infact it is looping

Comment 2

[Mitch]

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

Comment 3

[Frank Wein [:mcsmurf]]

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

Comment 4

[Calum Mackay]

Yup, confirmed, 20021113 Linux/x86. Doesn't need to be a Forward; same happens
for Reply.

Comment 5

[Calum Mackay]

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

[Jean-Francois Ducarroz]

Seth, can you take a look at this problem? my Linux build is currently dead :-(

Comment 7

[Andrew Schultz]

regression seems to be between linux trunk builds 2002110721 and 2002110904

Comment 8

[Andrew Schultz]

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

[Andrew Schultz]

regression between 2002110808 and 2002110821
checkin for bug 124990 might be a suspect

Comment 10

[Matthias Versen [:Matti]]

*** Bug 180513 has been marked as a duplicate of this bug. ***

Comment 11

[Matthias Versen [:Matti]]

os=all (win2k is also affected)

Comment 12

[Matthias Versen [:Matti]]

*** Bug 180513 has been marked as a duplicate of this bug. ***

Comment 13

[Andrew Schultz]

this is a regression from bug 124990

Comment 14

[Jean-Francois Ducarroz]

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]

Comment 15

[Jean-Francois Ducarroz]

*** Bug 180469 has been marked as a duplicate of this bug. ***

Comment 16

[Jean-Francois Ducarroz]

cc'ing bryner. Brian, any idea?

Comment 17

[Brian Ryner (not reading)]

Attachment: 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.

Comment 18

[Brian Ryner (not reading)]

taking

Comment 19

[saari (gone)]

Comment on attachment 106829 [details] [diff] [review]
patch

r=saari

Comment 20

[Johnny Stenback (: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

Comment 21

[Brian Ryner (not reading)]

checked in.

Comment 22

[esther]

Using trunk builds 20021121 on winxp linux and mac osx and scenario in comment
14 this is fixed. Verified

Comment 23

[Todd]

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

[Andrew Schultz]

*** Bug 181703 has been marked as a duplicate of this bug. ***

Comment 25

[Matthias Versen [:Matti]]

*** Bug 183896 has been marked as a duplicate of this bug. ***