341635 - crash [@ nsDOMAttribute::GetNamespaceURI] related to opening and closing windows, focus method, xul and javascript alert

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[publicpp+mozilla]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060418 Firefox/1.0.8 (Ubuntu package 1.0.8)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; pl; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

Provided test case causes crash on Windows builds of Firefox 1.5. The bug is present also on 2006061405 nighty build.

What test case do: html page (index.html) opens XUL window (one.xul). This window opens XUL page in new window (two.xul), then uses setTimeout to close itself and then displays javascript alert (after closing the window).
In the meantime two.xul executes focus method of element from one.xul and closes itself.

If popup blocking is disabled crash will not occur because this test case relies on windows opening. But it should also crash if the user trigger windows opening manually.

Reproducible: Always

Steps to Reproduce:
1. Go to http://cryptonix.org/exploits/firefox/
2. Disable popup blocking.
3. Click on the link.
4. Click OK to crash your browser.

Actual Results:  
The browser crashes.

Expected Results:  
It should gracefully close opened windows.

Talkback incident ID: 19867443.

Doesn't occur on Linux, on Firefox 1.0 and on Mozilla Suite 1.7.12.

Comment 1

[publicpp+mozilla]

Attachment: Main file.

Comment 2

[publicpp+mozilla]

Attachment: one.xul

Comment 3

[publicpp+mozilla]

Attachment: two.xul

Comment 4

[Régis Caspar]

Confirmed on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4 ID:2006050817 and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060615 Minefield/3.0a1 ID:2006061504 [cairo] 

TB19903037E (trunk-cairo)

I have an assertion on a debug build: 
###!!! ASSERTION: XPConnect is being called on a scope without a 'Components' property!

This is pretty much always bad. It usually means that native code is
making a callback to an interface implemented in JavaScript, but the
document where the JS object was created has already been cleared and the
global properties of that document's window are *gone*. Generally this
indicates a problem that should be addressed in the design and use of the
callback code.

Will attach stack

Comment 5

[Régis Caspar]

Attachment: stack

-> Core / DOM for triage

Comment 6

[timeless]

the stack isn't very interesting, you have to look at the js and figure out why it registered a timer in such a way that the js outlived its host. as the message tries to explain.

MSVCR80.dll + 0x4d85 (0x78134d85) is somewhere inside MSVCR80!_calloc_impl, which is a kinda strange place to be. i.e. i can't trust much of stack.

I'd rather ignore the stack you have here. do you get any other assertions? talkback seems to indicate mNodeInfo was null, but in a debug build you should have aborted or hit a number of asserts first....

Comment 7

[Régis Caspar]

(In reply to comment #6)
> I'd rather ignore the stack you have here. do you get any other assertions?
> talkback seems to indicate mNodeInfo was null, but in a debug build you should
> have aborted or hit a number of asserts first....
Yes, the stack was strange to me (no nsDOMAttribute::GetNamespaceURI) but I attached it because I'm not an expert. I  also get some warning and JS error:
WARNING: NS_ENSURE_TRUE(prompter) failed: file c:/mozilla/mozilla/dom/src/base/nsGlobalWindow.cpp, line 3193 
JavaScript error: , line 0: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindowInternal.alert]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: http://cryptonix.org/exploits/firefox/one.xul :: <TOP_LEVEL> :: line 7"  data: no]

(NB: my source tree is more up2date than my build, I need to rebuild that's perhaps why my stack is bad).

Comment 8

[timeless]

that one might be because of markh's rocky landing, or not.

anyway, that's not the stack i'm looking for either, you really get no other asserts?

do you actually crash in your debug build? how about attaching that stack and a list of local variables.

Comment 9

[Régis Caspar]

Attachment: stacks+vars+stdout

(In reply to comment #8)
> anyway, that's not the stack i'm looking for either, you really get no other
> asserts?
No.
 
> do you actually crash in your debug build? how about attaching that stack and 
> a list of local variables.
No I don't really crash, the build assert two times with "XPConnect is being called on a scope..." but still run. Attached is a stack+variable+stdout. I even tried making a bp @ nsDOMAttribute::GetNamespaceURI and my debugger didn't break here...
(Note: I made a fresh build last night)

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

I see this assertion
###!!! ASSERTION: JSContext still in threadjscontextstack!: '!mThreadData->GetJSContextStack() || !mThreadData->GetJSContextStack()-> DEBUG_StackHasJSContext(mJSContext)', file /home/smaug/mozilla/mozilla_cvs/event_rework/mozilla/js/src/xpconnect/src/xpccallcontext.cpp, line 343

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Latest 1.5 doesn't seem to crash, trunk does crash

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

Attachment: put back nsCOMPtr<nsIScriptContext> context

Before DOM_AGNOSTIC merge |context| variable used to be nsCOMPtr, now it is just a pointer.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 225995 [details] [diff] [review]
put back nsCOMPtr<nsIScriptContext> context

So this fixes the crash in trunk.

Comment 14

[Johnny Stenback (:jst)]

Comment on attachment 225995 [details] [diff] [review]
put back nsCOMPtr<nsIScriptContext> context

sr=jst