265962 - new windows opened into tabs crashes on self.close() - FF10x FFTrunk [@ nsFrameManager::GetPropertyListFor]

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Phil Randal]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041025 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041025 Firefox/1.0

Firefox crashes on "OnUnload popup stopper test" at
http://popupcheck.com/freescan/popup/test_unload.asp

Reproducible: Always
Steps to Reproduce:
1.
2.
3.




Talkback ID TB1510879Y

Comment 1

[Phil Randal]

This bug's also being discussed on the Mozillazine forums: 
http://forums.mozillazine.org/viewtopic.php?t=150115

Comment 2

[Phil Randal]

Oops, wrong url (fixed).  Click on item (2) "onUnLoad" Pop Up Stopper Test to crash.

Comment 3

[timeless]

you'll need to fish for a build where talkback really works.

Comment 4

[Phil Ringnalda (:philor)]

Only crashes with "Force links that open new windows to open in a new tab" set,
which probably makes it a dup of bug 265790 (though who knows what evil lurks in
their obfuscated JavaScript).

Comment 5

[Dan M]

Yes, this is the same as bug 265790. Unfortunately that bug been closed against
some obscure bug. It seems more fit to mark this one dependent on the urbug,
rather than obscure it by closing it as a duplicate. The steps to reproduce are
after all very different.

Comment 6

[sairuh (rarely reading bugmail)]

crashes in 2004102209-0.9+ bits. searching for regression window...

Comment 7

[sairuh (rarely reading bugmail)]

...downloads slow, sigh, still getting regression window... in any case, marcia
and i found that this crashes quite easily on linux and mac.

Comment 8

[sairuh (rarely reading bugmail)]

nm, asa (via danm from bug 232356 comment 14) says that this is likely a
regression for the fix for bug 263844 which checked in on 10/16.

Comment 9

[Dan M]

The patch checked in for bug 263844 exposes a deeper issue, yes. Eventually
we'll want to fix both.

Comment 10

[Nagappan]

Its not crashing in Linux.

Comment 11

[sairuh (rarely reading bugmail)]

tested with 2004102609-0.11 on linux fc2: now that the fix for bug 263844 was
backed out, this no longer crashes.

Comment 12

[Tracy Walker [:tracy]]

not crashing on windows firefox branch build 2004102607

Comment 13

[Marcia Knous [:marcia]]

i'll chime in on the Mac side - looks good using FF branch 2004-10-26-06-0.11/

Comment 14

[Scott Halstvedt]

fine on winxp 20041026-.11

Comment 15

[Asa Dotzler [:asa]]

Can we resolve this now?

Comment 16

[Dan M]

Only if you can figure out a combination of keywords and status flags that
reflect the bug's true state, which is this: it isn't really crashing any more
because the bug that exposed it (bug 263844) has been backed out. However the
crash remains an issue that's still being worked on in that bug and in bug
265790. I expect we'll want fixes for those bugs in Aviary 1.0. So this is not a
crash in RC1 but the issue will return in 1.0-for-real as those bugs progress.
Got a flag for that :) ?

Comment 17

[Brendan Eich [:brendan]]

Maybe jst should take this from blake?

/be

Comment 18

[Johnny Stenback (:jst)]

Attachment: Prevent nested close calls from actually closing a window.

Part of the problem here is that the're a window that's being closed whose
unload handler closes the window, and that cuses bad things to happen. This
change makes the global window code track that and makes just the outer-most
close() call actually close the window. Fixes the crash.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 163731 [details] [diff] [review]
Prevent nested close calls from actually closing a window.

sr=bzbarsky

Comment 20

[chris hofmann]

getting jay to look at talkback for top crash data, but thinking it will be hard
to distinguish this particular crash.   if we can find lots of pages that might
be tickling this crash we would reconsider, but now it looks like it will be
better to take this fix on the trunk

Comment 21

[Jay Patel [:jay]]

As Dan M said in comment #16, this crash was fixed for RC1 (with the backout of
bug 263844 combined with the fix for bug 265790), however, it is now back (I'm
guessing as a result of some regression from the second patch checked in for bug
263844).  

So unless we figure out a solution that covers both issues in those 2 bugs and
does not cause any crashes, this might have a good chance of becoming a
topcrasher in 1.0. 

Perhaps jst can shed some more light based on the patch presented in this bug?

Comment 22

[Johnny Stenback (:jst)]

Jay, do you knwo if the talkback reports all refere to this particular test, or
to random sites out there that happen to trigger the same bug? If it's all from
this test, I don't so much care, but if it's random sites out there then I'd
like to see us accept this patch for 1.0, after we've verified that this patch
does indeed fix the other sites as well, not just this popup blocker test.

Comment 23

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Crash is confirmable with current builds Mozilla/5.0 (Windows; U; Windows NT
5.0; en-US; rv:1.7.5) Gecko/20041112 Firefox/1.0.

I already mentioned it in bug 265790. The stack trace of this one is identically
to bug 265790. Shouldn't we close this bug as dupe? It's confusing to have two
bug reports for the same crash. :/ 

Comment 24

[Dan M]

Bug 265790 and this one are indeed identical. I prefer this one: it's more
concise and we've already begun work on a patch. But mainly 265790 is full of
keywords marking its patch(es) as universal and I don't want to confuse the
future trunk merge by mixing that with a patch not yet checked in. I'm closing
the other bug and changing this one's summary to be more general.

Comment 25

[Dan M]

Attachment: support file for testcase reduced from popupcheck.com

Comment 26

[Dan M]

Attachment: support file for testcase, simplified

Comment 27

[Dan M]

Attachment: support file for testcase, pathological

Comment 28

[Dan M]

Attachment: testcase

Comment 29

[Dan M]

Other testcases known to crash the current build (with new windows diverted into
tabs):

this bug's original testcase:
http://popupcheck.com/freescan/popup/popup_test_advanced.asp
  Click test (2) "onUnLoad" Pop Up Stopper Test

bug 265790 comment 32
http://de.shuttle.com/de/desktopdefault.aspx/tabid-72/170_read-4934/
  Open it, open new empty tab, return to de.shuttle.com and click an image
  to open a third tab, close that third tab.

---

These similar tests have also caused problems in the past, but I believe they're
already fixed. Still worth noting:

bug 265790's original testcase
http://www.niho.com/forsale/detail2.asp?prop=241
  Click on a map picture, close the tab

bug 68454, reloaded
http://cyndilauper.com/pictures_det.php
  Click on a picture, close the tab

Comment 30

[Dan M]

Attachment: soft landing from nested close() calls

Similar to the original patch in this bug but larger in scope. That original
patch didn't fix the crash for me. All feedback I've received on this patch
(umm, that's one other person) is that it fixes this crash.

Comment 31

[Johnny Stenback (:jst)]

Comment on attachment 166112 [details] [diff] [review]
soft landing from nested close() calls

r=jst

Comment 32

[Boris Zbarsky [:bzbarsky]]

So why are we destroying the treeowner for the case when we have a tab?

Also, does this work for the case when we're dealing with a <browser> but not a
<tabbrowser>?

Finally, how does that patch interact with the earlier patch in this bug?  Or
was that never checked in?

Comment 33

[Dan M]

window.close hails from the days before tabbed browsing. Prior to this patch, it
assumes it owns the entire window. This seems to have been fixed for most cases
by overriding window.close in the tab browser, but the comment in the patch to
ReallyCloseWindow describes a case where the close sneaks through anyway.

Boris, I don't follow your second comment. Do you mean, like, embedded Gecko?

The earlier patch never finished the approval process.

Comment 34

[Boris Zbarsky [:bzbarsky]]

> Boris, I don't follow your second comment. Do you mean, like, embedded Gecko?

For example, yes.  Anything that doesn't use the <tabbrowser> XUL element.

I seem to have miscommunicated my first question.  The code in that patch
destroys the treeowner if we're the root window, if there is no
nsIBrowserDOMWindow, or if |this| is a window for a tab.  Why that last case? 
The comment doesn't really make it clear to me why that check is needed.  What
happens when |this| is not a window for a tab (eg it's a window for an iframe or
a <browser>'s content area in a non-tabbed setup, etc, etc).

Comment 35

[Brendan Eich [:brendan]]

I am confused.

> window.close hails from the days before tabbed browsing. Prior to this patch,
> it assumes it owns the entire window. This seems to have been fixed for most
> cases by overriding window.close in the tab browser

This doesn't square with the code that sends the custom DOM event, and tests
whether tab-browser JS called preventDefault() on it.  That was the way hyatt
hacked tabs in while keeping window.close backward compatible.

So I'm a bear of little brain today.  Can you revise your statement to allow as
to how, in spite of window.close hailling from the days before tabbed browsing
(well before: 1995 summer, my misspent youth hacking Netscape 2), there *was*
code to handle tabs added by hyatt (IIRC), but it is somehow insufficient -- and
exactly how it is insufficient?

Probably all is well, and I'm just balking at an inaccurate thumbnail history
statement.  Thanks,

/be

Comment 36

[Dan M]

Boris:

The bug is about a very specific crash in tabbrowser Mozilla. My primary concern
was catching that case while allowing less tabby installations to function
normally. tabbrowser is invoked in this patch only by an implementation detail
in browser.js, which is already shot full of tabbrowser. Other Mozilla windows
behave normally because they don't have an nsIBrowserDOMWindow object. An
embedded tabbed window, if such a chimera is even possible, would probably need
to implement nsIBrowserDOMWindow just as Mozilla does.

As for why the IsTabContentWindow check is necessary, man I wrote this a month
ago. You're probably confused by my choice of implementation. I could have
looked very specifically for the exact situation that arises in this bug but I'm
trying to keep the API generic. nsIBrowserDOMWindow::AvoidDeathBySpiralingClose
would have been fun to write but a little too specific. I must have run into a
case where window.close needed to succeed for a lone tab. But it's that check
specifically that stops this crash; a multi-tabbed browser window shutting down
a boneheaded tab that closes itself in its unload handler.

Brendan:

Well yes. The tab browser handles close(), itself. Close a DOM window by
clicking the tab-close widget and the window is disposed of (usually*) without
ever invoking the close function. If you try hard enough you can get it to
invoke close(), but it never gets as far as ReallyCloseWindow because tabbrowser
unhooks the window itself and stops the event from propagating that far. But if
you try really really hard, boneheaded hard, like popup_test_advanced.asp does
(see my pathological testcase in this bug's fourth attachment) you can sneak a
close event through that tabbrowser doesn't stop.

* I know of at least one leak.

Comment 37

[Boris Zbarsky [:bzbarsky]]

> Other Mozilla windows behave normally because they don't have an
> nsIBrowserDOMWindow object.

OK.  That answers my question about what happens in the absence of <tabbrowser>.
 Thank you.

> You're probably confused by my choice of implementation.

No, I'm confused by the fact that the comments are unclear and the code is not
self-descriptive.  The latter is fine if the implementation is generic, but then
the comments need fixing.

> I must have run into a case where window.close needed to succeed for a lone
> tab.

Then that needs to be documented in the code accordingly.

So let me see if I understand this correctly.

Per the code as written, we want to Destroy() the treeOwner if we're the window
of the root treeitem or if we're the window of a tab in a tabbrowser and the tab
has not been closed yet.

Somehow, all cases when we're a tab that has not been closed yet and not the
only tab are already caught in some other code somewhere, who knows where.  So
when we reach this code, if we're the window for a tab we know it's the _only_
tab.  And then we want to actually close the window.

Is that all correct?  If so, it would be good to clearly document that, possibly
pointing out where the other codepaths (the ones where we're not the only tab)
are trapped.  I hope it's elsewhere in globalwindow, because I'd really rather
not have this code depending on the proper functioning of tabbrowser...

Comment 38

[[e-mail]]

Comment on attachment 166112 [details] [diff] [review]
soft landing from nested close() calls

>+    nsCOMPtr<nsIDOMChromeWindow> thisChrome =
>+      do_QueryInterface(NS_STATIC_CAST(nsIDOMWindow *, this));
Why do only chrome windows need the extra addref?

Comment 39

[Brendan Eich [:brendan]]

> If so, it would be good to clearly document that, possibly
> pointing out where the other codepaths (the ones where we're not the only tab)
> are trapped.  I hope it's elsewhere in globalwindow, because I'd really rather
> not have this code depending on the proper functioning of tabbrowser...

bz: see
http://lxr.mozilla.org/mozilla/source/dom/src/base/nsGlobalWindow.cpp#3529 and
below in GlobalWindowImpl::Close, where I believe (danm and jst correct me if
I'm wrong) the "other codepaths" involving more than one tab open in the window
are handled.  This is the custom DOM event that tab-browser JS prevent-defaults
in order to suppress the top-level window close.

/be

Comment 40

[Boris Zbarsky [:bzbarsky]]

Great.  So the comment here should point to that code in its explanation of
what's going on.

Comment 41

[Dan M]

Boris: The comment is clear to me, of course. But let me be the first, or maybe
third, to allow that "clear to the author" isn't the best of all measures. Maybe
it's book time. How's this for a comment?

        /* Normally we destroy the entire window, but not if
           this DOM window belongs to a tabbed browser and doesn't
           correspond to a tab. This allows a well-behaved tab
           to destroy the container as it should but is a final measure
           to prevent an errant tab from doing so when it shouldn't.
           This works because we reach this code when we shouldn't only
           in the particular circumstance that we belong to a tab
           that has just been closed (and is therefore already missing
           from the list of browsers) (and has an unload handler
           that closes the window). */

If that's a good comment, there aren't many good comments in the codebase. But
what the heck. I could also of course add pointers to related code but we're
really starting to go overboard here.

Neil: you're my conscience and a steady reminder that I'm going senile, bless
you. The nsIDOMChromeWindow code is part of an experiment I forgot to remove; it
should be excluded from the patch.

Comment 42

[Boris Zbarsky [:bzbarsky]]

> How's this for a comment?

Much much better.  Again, it'd help to point to the code that prevents us
reaching this code in other circumstances (so that someone who comes along can
make sense of this complicated setup more easily).... but I'll take what I can
get.  ;)

> there aren't many good comments in the codebase.

That's correct.  There aren't.

Comment 43

[Brian Ryner (not reading)]

Comment on attachment 163731 [details] [diff] [review]
Prevent nested close calls from actually closing a window.

removing obsolete review request

Comment 44

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 166112 [details] [diff] [review]
soft landing from nested close() calls

sr=bzbarsky with the improved comments.

Comment 45

[Ger Teunis]

Seems to be fixed, can't reproduce it anymore on the recent trunk.

Comment 46

[sairuh (rarely reading bugmail)]

johnny, should this be marked as fixed now? or is it pending other fixes?

Comment 47

[Jay Patel [:jay]]

Adding topcrash info for tracking.  There have been a lot of crashes under
"nsFrameManager::GetPropertyListFor" for Firefox 1.0.  Although a few cases were
fixed prior to release, hopefully this last patch after will cover the remaining
ones.

Comment 48

[Jay Patel [:jay]]

A link to all "nsFrameManager::GetPropertyListFor" crashes currently in the
Talkback db so people can verify whether the ones for FF10 (build: 20041107) are
indeed this crash:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsFrameManager%3A%3AGetPropertyListFor&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid

Comment 49

[Nickolay_Ponomarev]

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

Comment 50

[Jay Patel [:jay]]

Still see crashes on the Aviary branch, so looks like this only made it onto the
Trunk.  Here is a recent Aviary incident:

Incident ID: 3742333
Stack Signature	nsFrameManager::GetPropertyListFor 5792f22c
Product ID	Firefox10
Build ID	2005020805
Trigger Time	2005-02-16 13:36:14.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	firefox.exe + (00234961)
URL visited	http://www.basscentral.com/
User Comments	Closing one of multiple tabs
Since Last Crash	119257 sec
Total Uptime	196614 sec
Trigger Reason	Access violation
Source File, Line No.
d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsFrameManager.cpp,
line 1879
Stack Trace 	
nsFrameManager::GetPropertyListFor 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsFrameManager.cpp,
line 1879]
nsFrame::Destroy 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsFrame.cpp,
line 622]
nsSubDocumentFrame::Destroy 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/document/src/nsFrameFrame.cpp,
line 567]
nsFrameList::DestroyFrames 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/base/src/nsFrameList.cpp,
line 129]
nsBoxFrame::Destroy 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsBoxFrame.cpp,
line 1065]
nsFrameList::DestroyFrame 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/base/src/nsFrameList.cpp,
line 214]
nsFrameManager::RemoveFrame 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsFrameManager.cpp,
line 757]
nsCSSFrameConstructor::ContentRemoved 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/style/src/nsCSSFrameConstructor.cpp,
line 9535]
PresShell::ContentRemoved 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5278]
nsGenericElement::doRemoveChild 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 3122]
nsXULElement::RemoveChild 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 853]
XPCWrappedNative::CallMethod 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2034]
XPC_WN_CallMethod 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1287]
js_Invoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 941]
js_Interpret 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 2978]
js_Invoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 958]
js_InternalInvoke 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsinterp.c,
line 1035]
JS_CallFunctionValue 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/js/src/jsapi.c,
line 3698]
nsJSContext::CallEventHandler 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1297]
nsJSEventListener::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/events/nsJSEventListener.cpp,
line 184]
nsEventListenerManager::HandleEventSubType 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1436]
nsEventListenerManager::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1516]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2841]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2673]
PresShell::HandleDOMEventWithTarget 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6139]
nsMenuFrame::Execute 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsMenuFrame.cpp,
line 1671]
nsMenuFrame::Enter 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsMenuFrame.cpp,
line 1272]
nsMenuFrame::ShortcutNavigation 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsMenuFrame.cpp,
line 1216]
nsMenuListener::KeyPress 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/xul/base/src/nsMenuListener.cpp,
line 229]
DispatchToInterface 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 127]
nsEventListenerManager::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1524]
nsXULDocument::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/document/src/nsXULDocument.cpp,
line 1261]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2823]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 2821]
nsXULElement::HandleChromeEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/xul/content/src/nsXULElement.cpp,
line 3988]
GlobalWindowImpl::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp,
line 916]
nsDocument::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsDocument.cpp,
line 3742]
nsGenericElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/base/src/nsGenericElement.cpp,
line 1918]
PresShell::HandleEventInternal 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6059]
PresShell::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 5921]
nsViewManager::HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2280]
nsViewManager::DispatchEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/view/src/nsViewManager.cpp,
line 2066]
HandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/view/src/nsView.cpp,
line 77]
nsWindow::DispatchEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1067]
nsWindow::DispatchKeyEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 2978]
nsWindow::OnChar 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 3162]
nsWindow::ProcessMessage 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 3878]
nsWindow::WindowProc 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1349]
USER32.dll + 0x86cb (0x77d486cb)
USER32.dll + 0x879f (0x77d4879f)
USER32.dll + 0x8a31 (0x77d48a31)
USER32.dll + 0x8ab4 (0x77d48ab4)
nsAppShellService::Run 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/xpfe/appshell/src/nsAppShellService.cpp,
line 495]
main 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/browser/app/nsBrowserApp.cpp,
line 58]
kernel32.dll + 0x2141a (0x77e8141a)

Nominating for 1.0.1 to see if this patch is safe enough to include in that
release.  If not, it should already be in for 1.1. It is currently the #25
topcrasher for Firefox 1.0.

dveditz:  I could not set the flag, so if you think we can get this in, please
update the blocker status.  Thanks.

Comment 51

[Jay Patel [:jay]]

Marking fixed since this is no longer an issue on the Trunk (0 Talkback
incidents).  BUT, this missed 1.0.1 b/c the flag did not get set as I requested.
 Nominating to get this into 1.0.3 if possible (might be too late).  There are
quite a few crashes on the Aviary branch for 1.0.x releases:

http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=nsFrameManager%3A%3AGetPropertyListFor&vendor=All&product=Firefox10&platform=All&buildid=2005&sdate=&stime=&edate=&etime=&sortby=bbid

The patch doesn't look that simple, so I'll leave it up to drivers to decide. 
It will be a nice one to have, but if it's too risky, we can just wait for 1.1
(since it's already fixed on the Trunk).

Comment 52

[Chase Phillips]

blocking-aviary1.0.3-

Comment 53

[Ferdinand]

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

Comment 54

[Peter van der Woude [:Peter6]]

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

Comment 55

[timeless]

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