285419 - Trunk FF101 crash with javascript alert method, html select box onchange event, form submission [@ nsIFrame::Invalidate ]

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[dlomelino]

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

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050225
Firefox/1.0.1

This is the only version I have tested with. Tested on Windows 2000.

I have a form with a select box with multiple option entries. An onchange event
for this select element is handled with the javascript alert() method. Any time
the select option is changed with the keyboard and the form is submitted,
firefox crashes. Crashes every single time. It seems to only be when the alert()
method is used in the onchange event. I tested it with some other
methods/functions to be sure.

Reproducible: Always

Steps to Reproduce:
1. Set focus to the select box.
2. Change selected option with the keyboard.
3. Submit form.
Actual Results:  
Program Error box pops up saying: "firefox.exe has generated errors and will be
closed by Windows. You will need to restart the program. An error log is being
created." Firefox then proceeds to close.

Expected Results:  
submitted the form and displayed the result page.

Comment 1

[Mike Kaply [:mkaply]]

How are you submitting the form? I get the alert and then I can't submit the form?

Comment 2

[Adam Hauner]

WFM Fx 1.0.1/WXP

[e-mail]: Could you provide Talkback incident ID?

Comment 3

[Adam Hauner]

TB4265333X:
nsIFrame::Invalidate 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsFrame.cpp,
line 2506]
nsComboboxControlFrame::SetFocus 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/forms/src/nsComboboxControlFrame.cpp,
line 539]
nsHTMLSelectElement::HandleDOMEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/html/content/src/nsHTMLSelectElement.cpp,
line 1891]
nsEventStateManager::SendFocusBlur 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
line 4256]
nsEventStateManager::SetContentState 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
line 4040]
nsHTMLInputElement::SetFocus 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/html/content/src/nsHTMLInputElement.cpp,
line 1112]
nsEventStateManager::ChangeFocus 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
line 3023]
nsEventStateManager::PostHandleEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/content/events/src/nsEventStateManager.cpp,
line 1933]
PresShell::HandleEventInternal 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/layout/html/base/src/nsPresShell.cpp,
line 6111]
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 2326]
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::DispatchMouseEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 5261]
ChildWindow::DispatchMouseEvent 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 5511]
nsWindow::WindowProc 
[d:/builds/tinderbox/Fx-Aviary1.0.1/WINNT_5.0_Depend/mozilla/widget/src/windows/nsWindow.cpp,
line 1349]
USER32.DLL + 0x2ca8 (0x77e12ca8)
USER32.DLL + 0x2dc5 (0x77e12dc5)
USER32.DLL + 0x2f0f (0x77e12f0f)
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 + 0x87f5 (0x7c4e87f5)

-> Core / Layout 

Boris, should this be dupe of bug 231830 (stack is same as in duped bug 230842
comment #6)?

Comment 4

[Boris Zbarsky [:bzbarsky]]

Doesn't look like we're setting display here, so not likely to be a dup, unless
the windows native theming code is causing reframes or something.

Which is possible, since I don't see a problem with Firefox 1.0 on Linux...

Comment 5

[Adam Hauner]

BTW with 2005031005/SM-trunk/WXP I'm getting JS error after hitting Enter:

Error: [Exception... "'Permission denied to get property XULElement.accessKey'
when calling method: [nsIDOMXULLabelElement::accessKey]"  nsresult: "0x8057001e
(NS_ERROR_XPC_JS_THREW_STRING)"  location: "JS frame ::
http://www.homecode.org/~visit0r/firefox_select_bug.html?test_select=test3&frm_submit=Submit
:: onchange :: line 1"  data: no]
Source File:
http://www.homecode.org/~visit0r/firefox_select_bug.html?test_select=test3&frm_submit=Submit
Line: 1

Comment 6

[Boris Zbarsky [:bzbarsky]]

Though note that the steps to reproduce are unclear.... What I did was tab to
the select, hit the down arrow, then click the button with the mouse.  Comment 0
doesn't say whether that's what I should be doing or not...

Comment 7

[Adam Hauner]

Incident report has this reporter's comment:

  used the keyboard to change the select box option and then immediately clicked   
  the submit button. The javascript alert pops up from the onchange event and 
  then it crashes.

and I was able to reproduce it with 2005022304/FF10-branch/WXP -> TB4269156Y
(same stack).

Comment 8

[Adam Hauner]

And with those reproduction steps, I was able to reproduce with
2005031005/SM-trunk/WXP -> TB4270318G (same stack)

Comment 9

[Boris Zbarsky [:bzbarsky]]

Yeah, no crash on Linux with those steps.  I'll bet $5 native theming is
involved (testing on Windows before 2k would be one way to tell, I guess).
Someone who can reproduce the crash will need to debug it....

Comment 10

[Martijn Wargers (dead)]

Attachment: backtrace

Backtrace from a recent debug build.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Right.  This is trying to focus an already-destroyed nsComboboxControlFrame....

Martijn, can you set a breakpoint in nsComboboxControlFrame::Destroy and see
what the callstack looks like when we hit this breakpoint (which we presumably
do during the steps to reproduce....)

Comment 12

[Ere Maijala (slow)]

Attachment: Call stack at nsComboboxControlFrame destructor

Here is a call stack to the nsComboboxControlFrame destructor. It's reached
while the alert is displaying (done as in comment #6).

Comment 13

[Boris Zbarsky [:bzbarsky]]

Fun.  So the problem is that the onchange handler puts up an alert, then we
start loading the new page.. if you wait long enough on the alert, the new page
will come in, then when the alert comes down it will process the reflow event
for the new page, which will unsuppress painting and tear down the old page. 
All this before we return from that FireOnChange() call in
nsComboboxControlFrame::SetFocus.

Of course it would be just as easy to have the onchange remove the select from
the document; that would trigger the crash too....

I think we have an existing bug on firing the onchange event from inside frame
code somewhere, but I'm not sure. In any case, the simple solution here is to
make sure to fire onchange _after_ we've done this invalidate/repaint thing
we're doing.

Comment 14

[Boris Zbarsky [:bzbarsky]]

In fact, this is basically bug 231830

Comment 15

[Adam Guthrie]

Can someone who is able to reproduce this check and see if it was fixed by bug 231830 (which got checked in to trunk on 2006-08-11 05:09).

Comment 16

[Martijn Wargers (dead)]

It was already worksforme in a 2006-08-10 build. I'm marking this worksforme, if anyone can still reproduce this crash with current trunk builds, please reopen.