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)

x86
Windows NT
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: morse, Assigned: joki)

References

Details

Attachments

(1 file)

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

Created:
Updated:
Size: