After closing the search fields context menu the ctrl-tab panel cannot be closed anymore and results in crash [@ ensureCorrectMouseEventTarget]

VERIFIED FIXED in mozilla1.9.1b2

Status

()

defect
--
critical
VERIFIED FIXED
11 years ago
8 years ago

People

(Reporter: whimboo, Assigned: smichaud)

Tracking

({crash, verified1.9.1})

Trunk
mozilla1.9.1b2
All
macOS
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(1 attachment)

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre)
Gecko/20081105 Minefield/3.1b2pre ID:20081105020338

This one is OS X only. I cannot reproduce it on Windows. If you open the context menu of the search field inside the ctrl-tab panel and click somewhere within the panel to close the context menu, the panel stays forever. There is no way to get rid of it except closing the whole browser.

Steps:
1. Open at least 3 tabs
2. Hit ctrl-tab to show the panel
3. Still hold the ctrl key and right click the search field
4. After the context menu has been opened click somewhere in the panel

After step 4 you cannot close the panel anymore. There are no reactions on mouse clicks and keyboard inputs.
Flags: wanted-firefox3.1?
Flags: blocking-firefox3.1?

Comment 1

11 years ago
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081105 Minefield/3.1b2pre ID:20081105020338
Crashes on cmd-tab out. Crash log was sparse so I'm not linking it but if the apple log would help I can dig it up.
Flags: in-litmus?
Same crash here. There are also no frames listed: bp-75d77c61-ab80-11dd-a990-001cc45a2c28.

Worth filing this as a separate bug?
The initial cause of this bug is probably bug 461519. The crash is reproducible and looks like we have a recursion here. Ted, could this be the reason why crash reports don't list any frames?

After getting my debug crashing 29105 frames were collected:

#0	0x9687bd2f in _CGSGetWindowListWithTags
#1	0x9687bd01 in CGSGetOnScreenWindowList
#2	0x92c26c14 in NSWindowList
#3	0x11858c9f in nsCocoaUtils::FindWindowUnderPoint at nsCocoaUtils.mm:140
#4	0x11869f50 in -[ChildView ensureCorrectMouseEventTarget:] at nsChildView.mm:3179
#5	0x118750ca in -[ChildView mouseMoved:] at nsChildView.mm:3691
#6	0x1185e6cb in -[PopupWindow sendEvent:] at nsCocoaWindow.mm:2319
#7	0x1186a09c in -[ChildView ensureCorrectMouseEventTarget:] at nsChildView.mm:3201
#8	0x118750ca in -[ChildView mouseMoved:] at nsChildView.mm:3691
#9	0x1185e6cb in -[PopupWindow sendEvent:] at nsCocoaWindow.mm:2319
#10	0x1186a09c in -[ChildView ensureCorrectMouseEventTarget:] at nsChildView.mm:3201
#11	0x118750ca in -[ChildView mouseMoved:] at nsChildView.mm:3691
#12	0x1185e6cb in -[PopupWindow sendEvent:] at nsCocoaWindow.mm:2319
#13	0x1186a09c in -[ChildView ensureCorrectMouseEventTarget:] at nsChildView.mm:3201
#14	0x118750ca in -[ChildView mouseMoved:] at nsChildView.mm:3691
#15	0x1185e6cb in -[PopupWindow sendEvent:] at nsCocoaWindow.mm:2319
#16	0x1186a09c in -[ChildView ensureCorrectMouseEventTarget:] at nsChildView.mm:3201
#17	0x118750ca in -[ChildView mouseMoved:] at nsChildView.mm:3691
#18	0x1185e6cb in -[PopupWindow sendEvent:] at nsCocoaWindow.mm:2319
[...]
#29092	0x1186a09c in -[ChildView ensureCorrectMouseEventTarget:] at nsChildView.mm:3201
#29093	0x118750ca in -[ChildView mouseMoved:] at nsChildView.mm:3691
#29094	0x1185e6cb in -[PopupWindow sendEvent:] at nsCocoaWindow.mm:2319
#29095	0x1186a09c in -[ChildView ensureCorrectMouseEventTarget:] at nsChildView.mm:3201
#29096	0x118750ca in -[ChildView mouseMoved:] at nsChildView.mm:3691
#29097	0x92c583a5 in -[NSWindow sendEvent:]
#29098	0x11861629 in -[NSWindow(MethodSwizzling) nsCocoaWindow_NSWindow_sendEvent:] at nsCocoaWindow.mm:2191
#29099	0x1185b633 in -[ToolbarWindow sendEvent:] at nsCocoaWindow.mm:1923
#29100	0x92c249fd in -[NSApplication sendEvent:]
#29101	0x92b81d0f in -[NSApplication run]
#29102	0x11855f16 in nsAppShell::Run at nsAppShell.mm:692
#29103	0x1255faa6 in nsAppStartup::Run at nsAppStartup.cpp:192
#29104	0x000f5e7f in XRE_main at nsAppRunner.cpp:3263
#29105	0x000026e3 in main at nsBrowserApp.cpp:156
Assignee: nobody → joshmoz
Severity: major → critical
Component: Tabbed Browser → Widget: Cocoa
Depends on: 461519
Flags: wanted-firefox3.1?
Flags: blocking-firefox3.1?
Keywords: crash
Product: Firefox → Core
QA Contact: tabbed.browser → cocoa
Summary: After closing the search fields context menu the ctrl-tab panel cannot be closed anymore → After closing the search fields context menu the ctrl-tab panel cannot be closed anymore and results in crash
Flags: blocking1.9.1?
Depends on: 463363
It's certainly possible that stack overflow makes it impossible for us to write out a minidump in some cases.

Comment 5

11 years ago
on windows at least, stack overflow isn't promised to be usefully handle-able as you're called from close to stack overflow, so if you need a lot of frames to do work, you're just going to trigger *another* stack overflow and die.
(In reply to comment #0)

Henrik, I don't fully understand your STR, and therefore can't
reproduce it.

> If you *open the context menu of the search field inside the
> ctrl-tab panel* and click somewhere within the panel to close the
> context menu, the panel stays forever.

What does the part between the stars mean? 

> 3. Still hold the ctrl key and right click the search field

I don't know what you mean by "search field".	

The ctrl-tab panel disappears (as it should) if I right-click anywhere
outside it.  But (as far as I can tell) right-clicking anywhere inside
it does nothing at all.
Assignee: joshmoz → smichaud
(Following up comment #6)

Now I understand.  The Search Tabs field in the ctrl-tab panel is a
new feature -- one that's been landed since I last built the tree on
Monday.

We're really cramming in a lot of new features at the last minute.
And it's not too surprising that they sometimes uncover hidden bugs --
as seems to have happened here.
I suspect this should block beta2.

Though I know that saying this will land the burden of fixing it on me.
Means, you can reproduce it?
Summary: After closing the search fields context menu the ctrl-tab panel cannot be closed anymore and results in crash → After closing the search fields context menu the ctrl-tab panel cannot be closed anymore and results in crash [@ nsCocoaUtils::FindWindowUnderPoint]
Turns out the crash bug has a trivial fix.

A tryserver build will follow in a while.  But testing with it won't
have much point, since the fix for bug 463363 (which landed earlier
today) should have covered up the crash bug again.

If I'm right, this bug (the crash bug) shouldn't block beta2.  But
since the fix is trivial, it should still land soon ... possibly even
in beta2?
Attachment #346736 - Flags: review?(joshmoz)
(In reply to comment #9)

The crash is a little tricky to reproduce, but here's a pretty good
STR:

Go through all the steps from comment #0, letting go of the ctrl key
after step 4.  Then

5) Right-click somewhere outside the panel (but on a browser page) to
   bring up a context menu.

6) Move the mouse outside the context menu.  I almost always crash at
   this point.
Although this crashes, if it doesn't crash you can get in a pretty funky state in which you can almost not even force quit out of the browser (I hit this situation yesterday). Hopefully users will not hit this bug often in Beta 2 because if they do they will have to be clever to work there way out of it.

Updated

11 years ago
Attachment #346736 - Flags: review?(joshmoz) → review+
Attachment #346736 - Flags: superreview?(vladimir)

Updated

11 years ago
Flags: blocking1.9.1? → blocking1.9.1+
Marcia, try this bug's tryserver build once it's finished.  It should
have both my patch and the patch for bug 463363.

Though the Linux tryserver just crapped out with a
twisted.internet.error.ConnectionLost (though my patch makes no
changes on Linux).  So I'm not sure when/if the Mac tryserver will
finish building my patch :-)
Now that the panel closes when clicking outside I cannot reproduce it any longer.
Hardware: PC → All
Summary: After closing the search fields context menu the ctrl-tab panel cannot be closed anymore and results in crash [@ nsCocoaUtils::FindWindowUnderPoint] → After closing the search fields context menu the ctrl-tab panel cannot be closed anymore and results in crash [@ ensureCorrectMouseEventTarget]
Attachment #346736 - Flags: superreview?(vladimir) → superreview+
Comment on attachment 346736 [details] [diff] [review]
Fix for crash bug
[Checkin: Comment 20]

So, if I understand things correctly, I can now land this patch for
beta2 without further approval (since this bug is a blocker).

If nobody tells me otherwise, I'll land it (on mozilla-central)
tomorrow morning.
Yes, you can if the tree is green.
As long as Steven isn't able to check-in, probably another one can do that meanwhile?
Keywords: checkin-needed
I'm here and can land the patch ... but for now the tree is closed (to track down a Ts regression).

I'll keep checking for the tree to reopen later today.
Landed on mozilla-central (changeset 796579e94fdc).
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
No longer depends on: 461519
Attachment #346736 - Attachment description: Fix for crash bug → Fix for crash bug [Checkin: Comment 20]
Keywords: checkin-needed
Target Milestone: --- → mozilla1.9.1b2
No more crash reports listed with this stack on Soccorro. Even that the panel closes now when clicking outside I can't find a way to reproduce this crash. Looks fine with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081111 Minefield/3.1b2pre ID:20081111020233.

Does the Litmus flag make sense? I don't think that we can cover this anymore.
Status: RESOLVED → VERIFIED
Flags: in-litmus?
Feature isn't anymore on 1.9.1 branch and was verified by me a month ago. Setting verified keyword.
Crash Signature: [@ ensureCorrectMouseEventTarget]
You need to log in before you can comment on or make changes to this bug.