Closed
Bug 17568
Opened 25 years ago
Closed 25 years ago
[DOGFOOD] crash pulling down the Go menu
Categories
(Core :: XUL, defect, P2)
Tracking
()
VERIFIED
WORKSFORME
M15
People
(Reporter: warrensomebody, Assigned: saari)
Details
(Whiteboard: [PDT-])
I went to the bugzilla query page, did a query, and tried to go back with the GoBack button. In the middle of going back, I pulled down the Go menu and crashed here: nsMenuPopupFrame::SetCurrentMenuItem(nsMenuPopupFrame * const 0x031afa7c, nsIMenuFrame * 0x02070904) line 402 + 16 bytes nsMenuFrame::HandleEvent(nsMenuFrame * const 0x0206ee28, nsIPresContext & {...}, nsGUIEvent * 0x0012fbe8, nsEventStatus & nsEventStatus_eConsumeDoDefault) line 321 PresShell::HandleEvent(PresShell * const 0x01c738f4, nsIView * 0x035c3ad0, nsGUIEvent * 0x0012fbe8, nsEventStatus & nsEventStatus_eConsumeDoDefault) line 2209 + 38 bytes nsView::HandleEvent(nsView * const 0x035c3ad0, nsGUIEvent * 0x0012fbe8, unsigned int 0x00000008, nsEventStatus & nsEventStatus_eConsumeDoDefault, int & 0x00000000) line 834 nsView::HandleEvent(nsView * const 0x01c73d20, nsGUIEvent * 0x0012fbe8, unsigned int 0x0000001c, nsEventStatus & nsEventStatus_eConsumeDoDefault, int & 0x00000000) line 819 nsViewManager::DispatchEvent(nsViewManager * const 0x01c723b0, nsGUIEvent * 0x0012fbe8, nsEventStatus & nsEventStatus_eConsumeDoDefault) line 1739 HandleEvent(nsGUIEvent * 0x0012fbe8) line 63 nsWindow::DispatchEvent(nsWindow * const 0x035c3994, nsGUIEvent * 0x0012fbe8, nsEventStatus & nsEventStatus_eIgnore) line 401 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012fbe8) line 422 nsWindow::DispatchMouseEvent(unsigned int 0x0000012c, nsPoint * 0x00000000 {x=??? y=???}) line 3394 + 21 bytes ChildWindow::DispatchMouseEvent(unsigned int 0x0000012c, nsPoint * 0x00000000 {x=??? y=???}) line 3612 nsWindow::ProcessMessage(unsigned int 0x00000200, unsigned int 0x00000000, long 0x00840059, long * 0x0012fdf0) line 2617 + 24 bytes nsWindow::WindowProc(HWND__ * 0x00020c52, unsigned int 0x00000200, unsigned int 0x00000000, long 0x00840059) line 579 + 27 bytes USER32! 77e71820() if (mCurrentMenu) { PRBool isOpen = PR_FALSE; ==> mCurrentMenu->MenuIsOpen(isOpen); mCurrentMenu->SelectMenu(PR_FALSE); if (isOpen) mCurrentMenu->OpenMenu(PR_FALSE); } mCurrentMenu is garbage.
Comment 1•25 years ago
|
||
reassigning to saari as p2 for m12
Assignee: trudelle → saari
Priority: P3 → P2
Target Milestone: M12
Putting on the PDT+ radar. trudelle -Can we get this for M11? Any fix in hand?
Comment 3•25 years ago
|
||
mass-moving all m12 bugs to m13
Updated•25 years ago
|
Severity: normal → critical
Target Milestone: M13 → M11
Comment 4•25 years ago
|
||
setting severity to critical, pulling back to m11
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 5•25 years ago
|
||
I think I know what the problem is here, so I'm going to leave this in M11 for now.
Updated•25 years ago
|
Target Milestone: M11 → M12
Comment 6•25 years ago
|
||
Having trouble reproducing this, so I'm going to push it to M12 - saari
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → WORKSFORME
Assignee | ||
Comment 7•25 years ago
|
||
I'm still unable to reproduce this. Buler? Buler?
Reporter | ||
Updated•25 years ago
|
Status: RESOLVED → REOPENED
Reporter | ||
Comment 8•25 years ago
|
||
I suspect this is a race condition. As I said in my description, I was in the middle of going back when I tried to pull down the menu, so I suspect that something wasn't set up to deal with the menu being generated on the fly while simultaneously loading a page. You're just going to have to study the code to find the window. It's probably going to be difficult to reproduce.
Assignee | ||
Comment 9•25 years ago
|
||
I'm trying to ponder a race condition with a single threaded UI... In any case, is this really a dogfood bug?
Comment 10•25 years ago
|
||
Clearing WORKSFORME resolution due to reopen. Clearing PDT+ to confirm this is REALLY dogfood.
Comment 11•25 years ago
|
||
I don't consider any of this class of bug (interrupting operations, timing related, hard to reproduce) to be dogfood blockers. It has typically been a struggle to get these all fixed for the beta. For dogfood, we're better off fixing bugs that we can reproduce rather than chasing after these, even though they sometimes crash.
Comment 12•25 years ago
|
||
Don't interrupt while loading and you should be ok. Putting on the PDT- radar.
Assignee | ||
Updated•25 years ago
|
Target Milestone: M12 → M13
Comment 13•25 years ago
|
||
spam: changing qa contact from ckritzer -> paulmac for xul bugs
Assignee | ||
Updated•25 years ago
|
Target Milestone: M13 → M15
Assignee | ||
Comment 14•25 years ago
|
||
Moving to M15
Comment 15•25 years ago
|
||
Can anyone reproduce this reliably? I don't want to leave any common crashes in the beta.
Updated•25 years ago
|
QA Contact: paulmac → sairuh
Comment 16•25 years ago
|
||
I think most of these bugs have been fixed. I will ask sairuh to try to reproduce. Sairuh?
Comment 17•25 years ago
|
||
not able to repro using the 2000-01-11-xx builds on winNT, linux or mac. feel free to mark as WFM...
Updated•25 years ago
|
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → WORKSFORME
Comment 18•25 years ago
|
||
thanks, resolving as wfm...
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 19•25 years ago
|
||
verifying...
Comment 20•25 years ago
|
||
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL. XUL component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: bugzilla → xptoolkit.widgets
You need to log in
before you can comment on or make changes to this bug.
Description
•