Closed
Bug 285419
Opened 20 years ago
Closed 18 years ago
Trunk FF101 crash with javascript alert method, html select box onchange event, form submission [@ nsIFrame::Invalidate ]
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: dlomelino, Unassigned)
References
()
Details
(Keywords: crash, helpwanted, platform-parity)
Crash Data
Attachments
(2 files)
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•20 years ago
|
||
How are you submitting the form? I get the alert and then I can't submit the form?
Comment 2•20 years ago
|
||
WFM Fx 1.0.1/WXP
dlomelino@netfor.com: Could you provide Talkback incident ID?
Severity: normal → critical
Keywords: crash
Comment 3•20 years ago
|
||
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)?
Assignee: firefox → nobody
Component: General → Layout
Product: Firefox → Core
QA Contact: general → layout
Summary: crash with javascript alert method, html select box onchange event, form submission → crash with javascript alert method, html select box onchange event, form submission [@ nsIFrame::Invalidate ]
Version: unspecified → 1.7 Branch
Comment 4•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
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•20 years ago
|
||
And with those reproduction steps, I was able to reproduce with
2005031005/SM-trunk/WXP -> TB4270318G (same stack)
Summary: crash with javascript alert method, html select box onchange event, form submission [@ nsIFrame::Invalidate ] → Trunk FF101 crash with javascript alert method, html select box onchange event, form submission [@ nsIFrame::Invalidate ]
Version: 1.7 Branch → Trunk
Comment 9•20 years ago
|
||
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....
Keywords: helpwanted,
pp
Comment 10•20 years ago
|
||
Backtrace from a recent debug build.
Updated•20 years ago
|
Attachment #177164 -
Attachment mime type: application/octet-stream → text/plain
Comment 11•20 years ago
|
||
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•20 years ago
|
||
Here is a call stack to the nsComboboxControlFrame destructor. It's reached
while the alert is displaying (done as in comment #6).
Updated•20 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 13•20 years ago
|
||
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•20 years ago
|
||
In fact, this is basically bug 231830
Comment 15•18 years ago
|
||
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•18 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Updated•14 years ago
|
Crash Signature: [@ nsIFrame::Invalidate ]
You need to log in
before you can comment on or make changes to this bug.
Description
•