289476 - [@ nsInlineFrame::RemoveFrame ] crash when Javascript removes '<BR><applet...>' from innerHTML

Status: RESOLVED WORKSFORME

(Core :: Layout: Block and Inline, defect)

Description

[Dave Greene]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

I was using some simple Javascript code to show or hide a Java applet at the
user's request (a 'Collapse' link would turn into 'Expand', and vice versa). 
The first solution I came up with worked fine on IE6, but reliably crashed
Firefox/Mozilla on Windows XP after a few cycles at most.

I found a workaround that amounted to adding whitespace between the Java-applet
tag and a preceding <BR> tag (!).  But it seemed worth reporting the bug anyway
-- I hate it when whitespace matters when it isn't supposed to...

Reproducible: Always

Steps to Reproduce:
1.  On a fresh default install of Firefox 1.02 (or Mozilla 1.7) on Windows XP,
with the 1.42 JRE installed, browse to
         http://cranemtn.com/life/oschem1/FirefoxCrash.htm
2.  Click 'Collapse' (above the applet window).
3.  If no crash occurs, hit Refresh and repeat steps 1 and 2 a few more times.

(Haven't tried other versions of Windows yet, or the 1.5 JRE -- though I'm
guessing the same thing will happen on other configurations.)
Actual Results:  
Firefox crashed and closed all open browser windows and tabs.

Expected Results:  
Should have behaved just the same as

http://cranemtn.com/life/oschem1/FirefoxNoCrash.htm

-- which is identical to FirefoxCrash.htm, except for a single space character
between <BR> and <applet...> in the associated Javascript code (and some
irrelevant changes to the descriptive text in the HTML).

Removing the <BR> tag completely also avoids the crash.

This crash has happened reliably since Firefox 1.0, on every (Windows) computer
I've tried it on -- including also a clean Windows XP machine running Mozilla
1.7.  It doesn't crash *quite* every time I try it -- on rare occasions I even
have to open a new browser and try it there -- but the failure rate is over 75%.

I sent in an incident for Firefox 1.02 and one for Mozilla 1.7 --
     Firefox 1.02 talkback ID:  TB4911335E
     Mozilla 1.7 talkback ID:  TB4913231Z
The stack signatures say 'nsInlineFrame::RemoveFrame'.

If I do have trouble reproducing it the first few times, I usually end up with a
hung process (where Firefox stops responding) rather than a crash.

The workaround for this bug is about as trivial as you can get, of course --
assuming you can change the Javascript on the Web page you're looking at. 
Still... I couldn't find any close matches in Bugzilla, but it seems as if this
might be a symptom of some weird problem in low-level parsing or
Java-applet-handling code (?) that might be bubbling out elsewhere as well.

I couldn't duplicate the issue on the only Linux box I have within reach at the
moment (which has Linspire 4.5 on it).  But then I couldn't get the JRE 1.5
plugin to work there either, though I _thought_ I put the symbolic link in the
right place...  Will try again this weekend, on a more recent Mandrake
installation, and report back if the bug shows up there.

Comment 1

[Adam Hauner]

-> Core / Layout

Comment 2

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050329

I´m seeing the crash on Mozilla Trunk, Win98SE, SUN Java JRE 1.5.0_02
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB4941124H
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB4941342E

Steps to repeat:
1: Load http://www.cranemtn.com/life/oschem1/oschem15FirefoxCrash.htm
2: there are 2 applets, monovalent or divalent oscillators, either works.
   Click in rapid succession on the expand/collapse link above one of the applets.
After clicking 5 to ten times, getting faster, Mozilla crashed. 

Comment 3

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050408
jre1.5.0_02

I used Editor and Hex-Editor to get Talkback working, seems to be successful.
 
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB4941670M
nsInlineFrame::RemoveFrame 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsInlineFrame.cpp,
line 278]
nsFrameManager::RemoveFrame 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsFrameManager.cpp,
line 708]
nsCSSFrameConstructor::ContentRemoved 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsCSSFrameConstructor.cpp,
line 9822]
PresShell::ContentRemoved 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 5463]
nsGenericElement::RemoveChild 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/base/src/nsGenericElement.cpp,
line 3224]
nsRange::DeleteContents 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/base/src/nsRange.cpp,
line 1592]
nsGenericHTMLElement::SetInnerHTML 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 926]
nsGenericHTMLElementTearoff::SetInnerHTML 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 213]
XPCWrappedNative::CallMethod 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp,
line 2065]
XPC_WN_GetterSetter 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp,
line 1311]
js_Invoke 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1314]
js_InternalInvoke 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1411]
js_InternalGetOrSet 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1454]
js_SetProperty 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
2862]
js_Interpret 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 3425]
js_Execute 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1545]
obj_eval 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line
1127]
js_Invoke 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1314]
js_Interpret 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 3589]
js_Invoke 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1334]
js_Interpret 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 3589]
js_Invoke 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1334]
js_InternalInvoke 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c,
line 1411]
JS_CallFunctionValue 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsapi.c, line
3804]
nsJSContext::CallEventHandler 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsJSEnvironment.cpp,
line 1384]
nsJSEventListener::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/events/nsJSEventListener.cpp,
line 184]
nsEventListenerManager::HandleEventSubType 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1545]
nsEventListenerManager::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp,
line 1642]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/base/src/nsGenericElement.cpp,
line 2103]
nsGenericHTMLElement::HandleDOMEventForAnchors 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/html/content/src/nsGenericHTMLElement.cpp,
line 1461]
nsHTMLAreaElement::HandleDOMEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/html/content/src/nsHTMLAreaElement.cpp,
line 178]
nsGenericElement::HandleDOMEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/base/src/nsGenericElement.cpp,
line 2132]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 6269]
PresShell::HandleEventWithTarget 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 6175]
nsEventStateManager::CheckForAndDispatchClick 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 2923]
nsEventStateManager::PostHandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventStateManager.cpp,
line 1950]
PresShell::HandleEventInternal 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 6338]
PresShell::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp,
line 6113]
nsViewManager::HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2508]
nsViewManager::DispatchEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsViewManager.cpp,
line 2228]
HandleEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/view/src/nsView.cpp,
line 174]
nsWindow::DispatchEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1150]
nsWindow::DispatchMouseEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 5764]
ChildWindow::DispatchMouseEvent 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 6017]
nsWindow::WindowProc 
[c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/widget/src/windows/nsWindow.cpp,
line 1442]
KERNEL32.DLL + 0x363b (0xbff7363b)
KERNEL32.DLL + 0x24407 (0xbff94407)
0x00638bea

Comment 4

[Ronald Tilby]

WFM using Mozilla Suite Trunk Nightly Build ID: 2005051105 on Windows XP.

Comment 5

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 6

[Dave Greene]

The steps described by Hermann Schwab still reliably cause a crash for me in 
the latest beta.  [So it looks to me as if this bug *has* been "confirmed by a 
second user", but maybe the later works-for-me trumped that...?]

I've added a new pair of test pages for Firefox 1.5 Beta 1 to make it a little 
quicker to reproduce the crash:

http://www.cranemtn.com/life/oschem1/Firefox15Beta1Crash.htm

and

http://www.cranemtn.com/life/oschem1/Firefox15Beta1NoCrash.htm

Use the first link above in place of the one in the original Steps to 
Reproduce.  On this machine I'm getting a crash reliably on the first click of 
the "Collapse" link.

Can't get Talkback to work for the moment, so no Talkback ID#s just yet...

Comment 7

[Hermann Schwab]

confirmed using three different JREs, AthlonXP1600, Win98SE, 512MB

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20050927 SeaMonkey/1.1a
TB9822730Z, TB9822594Z, TB9822362G
JRE1.5.0_05,JRE1.4.2_09,JRE1.5.0_04

http://www.cranemtn.com/life/oschem1/oschem15FirefoxCrash.htm
expand/collapse image => crash

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

Comment 8

[Dave Greene]

TalkBack ID# TB11347400G in Firefox 1.5RC1: Expand, then collapse --
http://www.cranemtn.com/life/oschem1/Firefox15Beta1Crash.htm
 

Comment 9

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051028 SeaMonkey/1.1a
jre1.5.0_05

TB11348211G
http://www.cranemtn.com/life/oschem1/Firefox15Beta1Crash.htm

Comment 10

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051101 SeaMonkey/1.1a
jre1.5.0_05

TB11350105E
http://www.cranemtn.com/life/oschem1/Firefox15Beta1Crash.htm

Comment 11

[Dave Greene]

Seems to have been also-fixed sometime between 1.5 and now -- the above links work fine in Firefox 2.0.0.9, where it used to be easy to get a failure.  Will try on a few other machines, but it looks like this bug can be resolved.