Closed Bug 427257 Opened 16 years ago Closed 16 years ago

"ASSERTION: XPConnect is being called on a scope without a 'Components' property!" when opening mail window and quickly closing browser

Categories

(SeaMonkey :: MailNews: Message Display, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: ajschult784, Assigned: mnyromyr)

Details

(Keywords: assertion)

Attachments

(2 files, 1 obsolete file)

Attached file stack for assertion
With SeaMonkey, if I have a browser window open and
1. Open Mail (Ctrl+2)
2. Close the browser window quickly

I get
ASSERTION: XPConnect is being called on a scope without a 'Components' property!
(sky is falling, etc)

Beyond the assertion, I don't see any adverse effects.
The problem is caused by tasksOverlay.js::toOpenWindowByType's onload event handler, for which the passing browser window was holding a reference.
We could add an unload handler to the current window too; in fact we could reuse the same handler and get it to remove itself from both places at once.
Easier steps to reproduce - I think it's the same problem:
1. Open Mail (Ctrl+2)
2. Close Mail (Ctrl+W)

The main difference for me is that with my steps I get only two of the assertions, while I get four with Andrew's.
This patch fixes the issue Andrew filed this bug on, but not mine from comment#3 - that's probably a similar issue, just not the same.
Attachment #313926 - Flags: superreview?(neil)
Attachment #313926 - Flags: review?(neil)
(In reply to comment #3)
> Easier steps to reproduce - I think it's the same problem:
> 1. Open Mail (Ctrl+2)
> 2. Close Mail (Ctrl+W)
No, that's probably bug 425298.
Comment on attachment 313926 [details] [diff] [review]
destroy load listener on window death

>+      // make sure that this handler is called only once
>+      // and in the correct window context
>+      if (uri in window)
This will always be true at this point. We're always called in the original window's context, which is what causes the bug when that's closed first.

>+      {
>+        window[uri].removeEventListener("load", newWindowLoaded, false);
>+        delete window[uri];
>+      }
I think you probably want to remove the unload handler here too.
> >+      // make sure that this handler is called only once
> >+      // and in the correct window context
> >+      if (uri in window)
> This will always be true at this point. We're always called in the original
> window's context, which is what causes the bug when that's closed first.

I had JavaScript errors about window[uri] not being defined.
I need to investigate the exact circumstances, then.
I got the JavaScript error with v1 when:
- opening browser
- opening mailnews
- closing mailnews
- closing browser
because I didn't free the unload handler...
Patch updated.
Assignee: mail → mnyromyr
Attachment #313926 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #314438 - Flags: superreview?(neil)
Attachment #314438 - Flags: review?(neil)
Attachment #313926 - Flags: superreview?(neil)
Attachment #313926 - Flags: review?(neil)
Comment on attachment 314438 [details] [diff] [review]
destroy all load listeners on window death

>+    // or until the current window passes away
I think "is closed" suffices ;-)
Attachment #314438 - Flags: superreview?(neil)
Attachment #314438 - Flags: superreview+
Attachment #314438 - Flags: review?(neil)
Attachment #314438 - Flags: review+
Landed on trunk.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: