Closed Bug 3317 Opened 26 years ago Closed 25 years ago

Crash when unwinding frame stack after script event change.

Categories

(Core :: Layout, defect, P2)

Product:
Core
Component:
Layout
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: morse, Assigned: joki)

References

Details

Attachments

(1 file)

[YOUR TEST CODE]
(deleted), text/html
Details
The content shown below displays a single drop-down list. If that list is selected, browser will crash. Stack trace at time of crash is shown after the content. Note: this was originally reported as a side comment in bug report 3286. But the stack traces are different so this is now being reported as a separate bug. Furthermore, the crash in report 3286 is on startup and only on linux (not win32). This bug occurs when element is selected and occurs on win32 (not tested on linux). So they definitely are two separate bugs. CONTENT: -------- <HTML> <HEAD> <SCRIPT> function loadMain() { top.frames[0].document.open(); top.frames[0].document.write( "<FORM>" + "<TABLE>" + "<TR>" + "<TD>" + "<SELECT ONCHANGE=top.loadMain();> </SELECT>" + "</TD>" + "</TR>" + "</TABLE>" + "</FORM>" ); top.frames[0].document.close(); } </SCRIPT> </HEAD> <FRAMESET ROWS=*,1 BORDER=0 FRAMESPACING=0 onLoad=loadMain()> <FRAME SRC=about:blank NAME=main_frame SCROLLING=AUTO MARGINWIDTH=0 MARGINHEIGHT=0 NORESIZE> <FRAME SRC=about:blank NAME=dummy_frame SCROLLING=AUTO MARGINWIDTH=0 MARGINHEIGHT=0 NORESIZE> </FRAMESET> <NOFRAMES> <BODY> <P> </BODY> </NOFRAMES> </HTML> stack trace: ------------ nsGenericElement::HandleDOMEvent(nsIPresContext & {...}, nsEvent * 0x0012fa5c, nsIDOMEvent * * 0x0012fa10, unsigned int 1, nsEventStatus & nsEventStatus_eIgnore) line 750 + 33 bytes nsHTMLSelectElement::HandleDOMEvent(nsHTMLSelectElement * const 0x01377cfc, nsIPresContext & {...}, nsEvent * 0x0012fa5c, nsIDOMEvent * * 0x00000000, unsigned int 1, nsEventStatus & nsEventStatus_eIgnore) line 460 nsSelectControlFrame::MouseClicked(nsIPresContext * 0x0130ff30) line 999 nsFormControlFrame::HandleEvent(nsFormControlFrame * const 0x013c66b0, nsIPresContext & {...}, nsGUIEvent * 0x0012fdd0, nsEventStatus & nsEventStatus_eIgnore) line 686 PresShell::HandleEvent(PresShell * const 0x013753a4, nsIView * 0x013c7db0, nsGUIEvent * 0x0012fdd0, nsEventStatus & nsEventStatus_eIgnore) line 1448 + 33 bytes nsView::HandleEvent(nsView * const 0x013c7db0, nsGUIEvent * 0x0012fdd0, unsigned int 8, nsEventStatus & nsEventStatus_eIgnore) line 825 nsView::HandleEvent(nsView * const 0x01377630, nsGUIEvent * 0x0012fdd0, unsigned int 8, nsEventStatus & nsEventStatus_eIgnore) line 808 nsView::HandleEvent(nsView * const 0x01376240, nsGUIEvent * 0x0012fdd0, unsigned int 8, nsEventStatus & nsEventStatus_eIgnore) line 808 nsView::HandleEvent(nsView * const 0x01376ef0, nsGUIEvent * 0x0012fdd0, unsigned int 8, nsEventStatus & nsEventStatus_eIgnore) line 808 nsScrollingView::HandleEvent(nsScrollingView * const 0x01376ef0, nsGUIEvent * 0x0012fdd0, unsigned int 8, nsEventStatus & nsEventStatus_eIgnore) line 810 nsView::HandleEvent(nsView * const 0x0132fcc0, nsGUIEvent * 0x0012fdd0, unsigned int 28, nsEventStatus & nsEventStatus_eIgnore) line 808 nsViewManager::DispatchEvent(nsViewManager * const 0x0132fa00, nsGUIEvent * 0x0012fdd0, nsEventStatus & nsEventStatus_eIgnore) line 978 HandleEvent(nsGUIEvent * 0x0012fdd0) line 64 nsWindow::DispatchEvent(nsWindow * const 0x013c8130, nsGUIEvent * 0x0012fdd0, nsEventStatus & nsEventStatus_eIgnore) line 358 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fdd0) line 374 nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 1855 + 15 bytes nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 786452, long * 0x0012fef4) line 1394 + 24 bytes nsWindow::WindowProc(void * 0x00a80282, unsigned int 514, unsigned int 0, long 786452) line 417 + 27 bytes US
Assignee: rickg → kostello
Assignee: kostello → mjudge
Status: NEW → ASSIGNED
I will take a look at this, but it looks like a Pixley bug.
Assignee: mjudge → karnaze
Status: ASSIGNED → NEW
This seems to be a crasher in nsSelectControlFrame. Reassigning to Chris Karnaze
(Ignore Last Comment) The crasher is actually in HandleDOMEvent, but the start point is when a mouse down occurs in a nsFormControlFrame. It appears that the parent pointer is refering to garbage.
Assignee: karnaze → joki
The crash occurs because the <SELECT>'s ONCHANGE=top.loadMain() destroys the existing document in the top frame (I assume) including the single nsHTMLTableCellElement (I verified). Then before the nsHTMLSelectElement is destroyed it gets a mouse up event and its mInner's mParent is referenced. But its mInner's mParent is the nsHTMLTableCellElement that was destroyed, so it crashes. Tom, I'm reassigning this to you because you surely have more insight on what is going on than I do. I gave Steve a workaround - to include at least one <OPTION> inside the <SELECT>. Why this works in light of my comments above, I have no clue.
Tom, The workaround is inappropriate for my actual application so I do need a fix for this and ASAP. It is one of several blocking problems in the walled development.
Status: NEW → ASSIGNED
Unfortunately I'm not sure if I can give you a fix right away. This crash stems from a more serious problem that we're working to fix. I can possibly give you a better workaround, though. Try replacing "<SELECT ONCHANGE=top.loadMain();> </SELECT>" + with "<SELECT ONCHANGE=\"setTimeout('top.loadMain();', 0)\"> </SELECT>" + The addition the quotes is just because they really should be there anyway. But the general concept is just to prevent immediate processing of the script, pushing it back to the top of the stack with a zero length timeout.
The workaround using the timeout is acceptable for me and I am no longer blocked on this.
Product: MozillaClassic → Browser
Version: 1998-03-31 → other
per leger, assigning QA contacts to all open bugs without QA contacts according to list at http://bugzilla.mozilla.org/describecomponents.cgi?product=Browser
Summary: crash when element selected → Crash when unwinding frame stack after script event change.
I have a couple other bugs with this same basic problem. Duping them together. Setting fix for M5.
Target Milestone: M5
I have a couple other bugs with this same basic problem. Duping them together. Setting fix for M5.
*** Bug 3950 has been marked as a duplicate of this bug. ***
*** Bug 4092 has been marked as a duplicate of this bug. ***
Not making these for M5
Moving out to M7
Blocks: 7530
Target Milestone: M7 → M8
With the June 28th Build (1999062809), I can't reproduce the crash descricbed using the test provided. This problem may have been fixed.
Attached file [YOUR TEST CODE] (deleted) —
M7 on Win98 does not seem to crash either.
Target Milestone: M8 → M9
Far to major to fix in the next four days.
Target Milestone: M9 → M10
This isn't gonna make M9
Target Milestone: M10 → M11
sounds to hairy for m10. -> m11. let me know if something is in hand
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Can't reproduce on Mac. Can we get this tested on other platforms? Marking worksforme to get people's attention.
It's working for me now as well (on win32).
Status: RESOLVED → VERIFIED
With Oct 1 build, the problem is not occuring.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: