User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 I've tested this with various browser versions. All of the versions of 1.5 (including the 1.5.0.4 which has not been released yet) do not work. However, all versions of 1.0.x do (even Deer Park). Additionally, Bon Echo works as well (I only tested Alpha 2). I have tried with safe-mode as well with no changes. What is happening is I have a popup window that has a form on it. The cancel button is tied to a simple javascript window.close, but the save has a postback. Both close the window. The cancel button does not cause any problems (nor closing the window with the close button on the window's frame). However, the save button does cause a crash. Now, here is a curious fact as well, it seems that it only crashes when certain fields have values within them. But what is strange is that the feilds are mostly all text boxes. But some will cause a crash and some will not. For instance we have a 'short description' (one line) field which does not cause a crash, but filling out a value of the 'long description' (multi line) does. The generated html is nearly identical. Our date and currency fields also cause the crash, but not our drop downs or check box fields. I do not know if this particular bit of information is even relevant, but I thought I would mention it just the same. I cannot find anything peculiar about the html or javascript. However, the page is part of an ASP.Net control, so it is difficult to extract a minimum test case (especially since the post-back seems to be necessary to help trigger the crash). I thought I would post this bug first and continue to try to make a minimum test case. Reproducible: Always Steps to Reproduce: 1. Open edit popup window 2. Ensure one of the "naughty" feilds has a value. 3. Press the "save" button. Actual Results: The browser crashes (with talkback coming up). Expected Results: The popup window closes. I will add a talkback crash ID after I have submitted this bug.

A talkback incident ID: TB18998914Y

Incident ID: 18998914 Stack Signature nsLayoutUtils::HasPseudoStyle d8cd48d9 Product ID Firefox15 Build ID 2005111116 Trigger Time 2006-05-22 15:42:00.0 Platform Win32 Operating System Windows NT 5.1 build 2600 Module firefox.exe + (001804db) URL visited User Comments "save" button on popup window. Since Last Crash 2544 sec Total Uptime 2544 sec Trigger Reason Access violation Source File, Line No. c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsLayoutUtils.h, line 228 Stack Trace nsLayoutUtils::HasPseudoStyle [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsLayoutUtils.h, line 228] nsCSSFrameConstructor::AppendFrames [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 8014] nsCSSFrameConstructor::ContentAppended [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 8779] PresShell::ContentAppended [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 5460] nsHTMLDocument::ContentAppended [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/document/src/nsHTMLDocument.cpp, line 1100] doInsertChildAt [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 2771] nsGenericElement::InsertChildAt [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 2719] nsGenericElement::InsertBefore [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsGenericElement.cpp, line 3019] nsTransactionItem::DoTransaction [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/editor/txmgr/src/nsTransactionItem.cpp, line 182] nsTransactionManager::DoTransaction [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/editor/txmgr/src/nsTransactionManager.cpp, line 132] nsEditor::DoTransaction [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/editor/libeditor/base/nsEditor.cpp, line 684] nsEditor::InsertNode [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/editor/libeditor/base/nsEditor.cpp, line 1375] nsEditor::InsertTextImpl [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/editor/libeditor/base/nsEditor.cpp, line 2657] nsTextEditRules::WillInsertText [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/editor/libeditor/text/nsTextEditRules.cpp, line 730] nsTextEditRules::WillDoAction [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/editor/libeditor/text/nsTextEditRules.cpp, line 302] nsPlaintextEditor::InsertText [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/editor/libeditor/text/nsPlaintextEditor.cpp, line 790] nsTextControlFrame::SetValue [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/forms/nsTextControlFrame.cpp, line 3174] nsTextControlFrame::InitEditor [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/forms/nsTextControlFrame.cpp, line 1742] nsCSSFrameConstructor::CreateAnonymousFrames [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 5810] nsCSSFrameConstructor::CreateAnonymousFrames [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 5683] nsCSSFrameConstructor::ConstructHTMLFrame [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 5617] nsCSSFrameConstructor::ConstructFrameInternal [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 7735] nsCSSFrameConstructor::ConstructFrame [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 7624] nsCSSFrameConstructor::ProcessChildren [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 11977] nsCSSFrameConstructor::ConstructBlock [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 13038] nsCSSFrameConstructor::ConstructFrameByDisplayType [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 6799] nsCSSFrameConstructor::ConstructFrameInternal [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 7799] nsCSSFrameConstructor::ConstructFrame [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 7624] nsCSSFrameConstructor::ProcessChildren [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 11977] nsCSSFrameConstructor::ConstructBlock [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 13038] nsCSSFrameConstructor::ConstructFrameByDisplayType [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 6655] nsCSSFrameConstructor::ConstructFrameInternal [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 7799] nsCSSFrameConstructor::ConstructFrame [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 7624] nsCSSFrameConstructor::ProcessChildren [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 11977] nsCSSFrameConstructor::ConstructTableCellFrame [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 3889] nsCSSFrameConstructor::TableProcessChild [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 4149] nsCSSFrameConstructor::TableProcessChildren [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 4037] nsCSSFrameConstructor::ConstructTableRowFrame [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 3737] nsCSSFrameConstructor::TableProcessChild [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 4134] nsCSSFrameConstructor::TableProcessChildren [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 4037] nsCSSFrameConstructor::ConstructTableRowGroupFrame [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 3626] nsCSSFrameConstructor::TableProcessChild [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 4127] nsCSSFrameConstructor::TableProcessChildren [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 4037] nsCSSFrameConstructor::ConstructTableFrame [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 3498] nsCSSFrameConstructor::ConstructFrameByDisplayType [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 6716] nsCSSFrameConstructor::ConstructFrameInternal [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 7799] nsCSSFrameConstructor::ConstructFrame [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 7624] nsCSSFrameConstructor::ProcessChildren [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 11977] nsCSSFrameConstructor::ConstructBlock [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 13038] nsCSSFrameConstructor::ConstructFrameByDisplayType [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 6799] nsCSSFrameConstructor::ConstructFrameInternal [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 7799] nsCSSFrameConstructor::ConstructFrame [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 7624] nsCSSFrameConstructor::ContentAppended [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsCSSFrameConstructor.cpp, line 8718] PresShell::ContentAppended [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/layout/base/nsPresShell.cpp, line 5460] nsHTMLDocument::ContentAppended [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/document/src/nsHTMLDocument.cpp, line 1100] HTMLContentSink::NotifyAppend [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/document/src/nsHTMLContentSink.cpp, line 3927] HTMLContentSink::FlushPendingNotifications [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/document/src/nsHTMLContentSink.cpp, line 4273] nsHTMLDocument::ResolveName [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/document/src/nsHTMLDocument.cpp, line 3237] nsHTMLDocumentSH::ResolveImpl [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/dom/src/base/nsDOMClassInfo.cpp, line 7186] nsHTMLDocumentSH::NewResolve [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/dom/src/base/nsDOMClassInfo.cpp, line 7755] XPC_WN_Helper_NewResolve [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1063] js_LookupPropertyWithFlags [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2675] js_LookupProperty [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2580] js_GetProperty [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2865]

I'm still working on the test case, but I just saw what the stack trace contains (it's not something that seems easy to find out from the client, the stack trace shown there is in binary). So based on random guesses as to what those functions do, I tried removing the stylesheets. Which, of course, had no effect. Can anyone give me an idea what I'm looking for? I can attach the raw html, but I do not think it will crash by itself. Also, I forgot to mention about the fields, the currency and date fields are just text boxes as well, just sprinkled with some ajax. And the traceback you see is with 1.5.0, I can install the nightly or whatever you like, if that will help? I have just had a few crashes using 1.5.0.3 (when trying to remove the style sheets), so here is one of their ID's : TB19025510Z . I'm sorry that I am not familiar with the gecko rendering engine so I'm kinda stumbling in the dark here.

If you could go ahead and attach what you have (or just give a link to it), then maybe Martijn could figure out what's going on and create a minimized testcase. And yes, it would be nice if you could test this in a nightly or branch build and see if it's still crashing.

Adam, thank you for the reply. I downloaded minefield by accident (nightly/latest-trunk), it crashed too, but maybe it's just wholly unstable and is not related here is the talkback number for it: TB19034017M . I then tried: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8.0/firefox-1.5.0.4.en-US.win32.installer.exe (Dated the 23rd (today)). It also crashed with this ID: TB19034355Y . Which looks like the same thing as the first ID I submitted. I've constructed a copy of the website I was going to send to you (with the javascript files inlined) but running it doesn't seem to trigger the crash (so apparantly it is happening during the postback or somesuch, which would fail). If Martijn or yourself would like to contact me, I can open up a selective hole in our firewall. The email listed under "Reporter" is accurate. Let me know what else I can do to help!

The testcase crashes on load for me (if you don't have the popup blocked, else push the button). The popup consists of this html code: <html><head></head> <body> <textarea>Some text some text some text some text some text</textarea> <div id="Documents_Editors"></div> <script> window.close(); document.getElementById('Documents_Editors'); </script> </body> </html>

In Mozilla1.7, the popup isn't closed, so it doesn't crash in there, but it really should have closed the popup. CC-ing Smaug, since he has some experience with this type of crash ;)

Hmm, so PresShell::Destroy gets called while PresShell::ContentAppended is called :(

Not to be a worry wart, but the testcase doesn't crash my copy of firefox. I've tried the nightly build and 1.5.0.3 as well.

So the presshell is being destroyed during frame construction? Why?

Similar thing is done also in http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsGlobalWindow.cpp#4374

Comment on attachment 223279 [details] [diff] [review] proposed patch r+sr=jst

Er... There are other ways to wipe out a presshell than window.close... I'll look into creating a testcase to demonstrate.

So I checked... All that's happening is that the XBL constructor firing after ContentAppended triggers the window.close call.. So this is the right fix, I guess, but the constructor could also nuke the presshell and prescontext directly. We have bugs on that, though.

Is this patch worthy of 1.8.1 branch and 1.8.0.5 branch?

(In reply to comment #15) > Is this patch worthy of 1.8.1 branch and 1.8.0.5 branch? I'm asking again, is this patch something that should get on branches?

Comment on attachment 223279 [details] [diff] [review] proposed patch The patch here doesn't apply to the branch(es) because it uses the new event system (runnables). Somebody would need to backport the patch to the branches.

I'll port it. Today.

Except that the testcase doesn't crash in the latest 1.8.0 (Linux). Martijn, does it work for you?

(In reply to comment #19) > Except that the testcase doesn't crash in the latest 1.8.0 (Linux). > Martijn, does it work for you? Yes, it works for me too. However, I minimised the original website by using a trunk build. So it may be that I overoptimised for trunk. Unfortunately, I can't access the original website anymore, so I can't test 1.5.0.4 with it. But Adam said he crashed in 1.5.0.4. Adam, could you perhaps make the website available again (and could Smaug also get the login data, please)? Thanks.

Adam already said in comment 9 that he didn't crash with the testcase, so that may be further evidence, that I overoptimised or something.

I am not at a physical location to bring the server back up, but I have left email to have it brought back up. I'll leave a note when I get confirmation that it is back online. I think it is ok for you to share the login information with other developers to fix this, I was just weary about posting it publically here. And yes, that test case never crashed my copy.

I've sent Martijn Wargers the url, username and passwd. And confirmed that everything is still crashing on my version of firefox (which has changed from Windows to Linux in the interim).

This is based on how event is dispatched in ::Close(). This works, but I can't see the crash even without this, so if someone who can reproduce the crash on 1.8.0 could test this...

Is there a way to verify this fixes the original reporter's testcase? Land on 1.8 branch and test a nightly, for instance?

Ok, I just finished a 1.5.0.4 build. I managed to crash after the second try. After applying the patch and rebuilding, I retried 10 times, but I did not get a crash. So I'm pretty sure, the 1.8.0 version of the patch is helping.

Comment on attachment 225444 [details] [diff] [review] 1.8.0 version of the patch I've been told that jst is on vacation, so asking someone else to review....

Comment on attachment 225444 [details] [diff] [review] 1.8.0 version of the patch Looks reasonable.

Comment on attachment 225444 [details] [diff] [review] 1.8.0 version of the patch And to keep branches in sync, approval for 1.8.1 ?

Comment on attachment 225444 [details] [diff] [review] 1.8.0 version of the patch approved for 1.8.0 branch, a=dveditz for drivers

verified with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.5) Gecko/20060620 Firefox/1.5.0.5

So this bug caused the regression bug 342784 on the 1.8.0 branch by delaying the shutdown until other things on the stack and in the eventqueue has been processed during shutdown. In general our shotdown code is pretty shaky, so it's a bit scary to change it on the stable branch. So while bug 342784 has been fixed, i'm worried about further obscure regressions. How bad is this bug? Could we maybe back it out from the 1.8.0 branch and just leave it for trunk and 1.8?

(In reply to comment #32) > > How bad is this bug? Could we maybe back it out from the 1.8.0 branch and just > leave it for trunk and 1.8? > I agree, we should probably (but unfortunately) back out this from 1.8.0. This is not a topcrasher. I don't have this now in debugger (especially because I couldn't reproduce this on 1.8.0), but iirc, the crash was because of a null pointer. (but simple null check doesn't fix it.) Jonas, any chance that you could back out this? I may not have proper connection before Monday. Or just say if you don't have time, then I'll try to find some time and place where I could do it asap.

switching back to 1.8.0.5-nominated so we'll notice this in triage and can discuss the previous couple of comments.

We're keeping this one on the 1.8.0 branch