Closed Bug 336576 Opened 19 years ago Closed 19 years ago

Crash when window gets destroyed during contextmenu event [@ nsDOMUIEvent::GetClientPoint]

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: martijn.martijn, Assigned: smaug)

References

Details

(5 keywords)

Crash Data

Attachments

(3 files, 2 obsolete files)

See upcoming testcase, which crashes current trunk Mozilla build when right clicking on the iframe. This regressed between 2006-03-06 and 2006-03-07, probably a regression from bug 234455. Talkback ID: TB18282936W nsDOMUIEvent::GetClientPoint nsDOMMouseEvent::GetClientX XULPopupListenerImpl::LaunchPopup XULPopupListenerImpl::PreLaunchPopup XULPopupListenerImpl::ContextMenu nsEventTargetChainItem::HandleEvent nsEventTargetChainItem::HandleEventTargetChain nsEventTargetChainItem::CreateChainAndHandleEvent nsEventTargetChainItem::CreateChainAndHandleEvent nsEventTargetChainItem::CreateChainAndHandleEvent nsEventTargetChainItem::CreateChainAndHandleEvent nsEventTargetChainItem::CreateChainAndHandleEvent nsEventTargetChainItem::CreateChainAndHandleEvent nsEventTargetChainItem::CreateChainAndHandleEvent nsEventTargetChainItem::CreateChainAndHandleEvent nsEventTargetChainItem::CreateChainAndHandleEvent nsEventTargetChainItem::CreateChainAndHandleEvent nsEventTargetChainItem::CreateChainAndHandleEvent nsEventTargetChainItem::CreateChainAndHandleEvent nsEventTargetChainItem::CreateChainAndHandleEvent nsEventTargetChainItem::CreateChainAndHandleEvent nsEventDispatcher::Dispatch PresShell::HandleEventInternal PresShell::HandlePositionedEvent PresShell::HandleEvent nsViewManager::HandleEvent nsViewManager::DispatchEvent HandleEvent nsWindow::DispatchEvent nsWindow::DispatchMouseEvent
Attached file testcase
hmm, is this somehow related to Bug 304262
Attached patch fixes the crash (obsolete) — Splinter Review
This fixes the crash, but IMO the context menu shouldn't become visible at all in this case - or at least not the way it does with the patch.
Attached patch possible patch (obsolete) — Splinter Review
This fixes the crash and disables context menus when the "context" is deleted before showing the menu. Change to nsDOMUIEvent fixes the crash, change to nsEventListenerManager removes (IMO) extra assertion (which was coming from aPresContext->PresShell()), and the modification to XULPopupListenerImpl disables context menu if primaryframe is not found for the originalTarget of the event. Does this make sense?
Assignee: events → Olli.Pettay
Attachment #220768 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #220799 - Flags: review?(bzbarsky)
Mm... so if someone sets a content node display:none oncontextmenu we won't show the menu? I'm not sure I'm happy with that. The rest of the changes look good, though.
Attached patch fixes the crashSplinter Review
Attachment #220897 - Flags: superreview?(bzbarsky)
Attachment #220897 - Flags: review?(bzbarsky)
Attachment #220799 - Attachment is obsolete: true
Attachment #220799 - Flags: review?(bzbarsky)
Comment on attachment 220897 [details] [diff] [review] fixes the crash I think this would be good for branches too. Should fix the problems related to Bug 304262. (There are some TBs which have nsDOMUIEvent::GetClientPoint() in the stack)
Attachment #220897 - Flags: superreview?(bzbarsky)
Attachment #220897 - Flags: superreview+
Attachment #220897 - Flags: review?(bzbarsky)
Attachment #220897 - Flags: review+
Blocks: 337596
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Verified FIXED using build 2006-05-12-07 of SeaMonkey trunk on Windows XP with https://bugzilla.mozilla.org/attachment.cgi?id=220762. No crash.
Status: RESOLVED → VERIFIED
*** Bug 337596 has been marked as a duplicate of this bug. ***
No longer blocks: 337596
(In reply to comment #7) > (From update of attachment 220897 [details] [diff] [review] [edit]) > I think this would be good for branches too. Smaug, so you want this on branches, right? This probably slipped through your attention. This is number 14 on the list of crashes for FF1506 http://talkback-public.mozilla.org/reports/firefox/FF1506/index.html and number 49 for FF2b2 http://talkback-public.mozilla.org/reports/firefox/FF2b2/index.html (although this doesn't necessarily have to the same sort of crash) Probably the patch needs a slight rewrite for the branches. The testcase in this bug doesn't crash branch build, however, the testcase in bug 304262 does. If I understand Smaug correctly, that bug would be also be fixed by this patch for branches.
Flags: blocking1.8.1?
Flags: blocking1.8.0.8?
Attached patch for branchesSplinter Review
Attachment #236388 - Flags: approval1.8.1?
Attachment #236388 - Flags: approval1.8.0.8?
181 drivers say: Don't think we'd block on this, but we'll take a look at the patch as a non-blocker.
Flags: blocking1.8.1? → blocking1.8.1-
Summary: Crash when window gets destroyed during contextmenu event → Crash when window gets destroyed during contextmenu event [@ nsDOMUIEvent::GetClientPoint]
Comment on attachment 236388 [details] [diff] [review] for branches a=schrep for drivers for topcrash fix.
Attachment #236388 - Flags: approval1.8.1? → approval1.8.1+
Keywords: fixed1.8.1
*** Bug 352130 has been marked as a duplicate of this bug. ***
Restoring lost blocking flag
Flags: blocking1.8.0.9?
Blocks: 354810
*** Bug 354810 has been marked as a duplicate of this bug. ***
No longer blocks: 354810
Flags: blocking1.8.0.9? → blocking1.8.0.9+
Comment on attachment 236388 [details] [diff] [review] for branches a=mconnor on behalf of drivers for 1.8.0.9 checkin
Attachment #236388 - Flags: approval1.8.0.9? → approval1.8.0.9+
Keywords: fixed1.8.0.9
Verified, application doesn't crash using testcase in comment #1 with these: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061128 Minefield/3.0a1 Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9pre) Gecko/20061128 Firefox/1.5.0.9pre Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1pre) Gecko/20061128 BonEcho/2.0.0.1pre Notice that context menu shows in trunk when right clicking on the iframe.
I'm seeing a broken context menu with the testcase in this bug. I filed bug 418070 for it now (although I thought someone already filed a bug for it, but I couldn't find it).
Crash Signature: [@ nsDOMUIEvent::GetClientPoint]
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: