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

Status: VERIFIED FIXED

(Core :: Widget: Cocoa, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 1

[Jack Laxson]

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.

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Same crash here. There are also no frames listed: bp-75d77c61-ab80-11dd-a990-001cc45a2c28.

Worth filing this as a separate bug?

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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

Comment 4

[(not currently active) Ted Mielczarek]

It's certainly possible that stack overflow makes it impossible for us to write out a minidump in some cases.

Comment 5

[timeless]

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.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

(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.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

(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.

Comment 8

[Steven Michaud [:smichaud] (Retired)]

I suspect this should block beta2.

Though I know that saying this will land the burden of fixing it on me.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Means, you can reproduce it?

Comment 10

[Steven Michaud [:smichaud] (Retired)]

Attachment: Fix for crash bug [Checkin: Comment 20]

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?

Comment 11

[Steven Michaud [:smichaud] (Retired)]

(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.

Comment 12

[Marcia Knous [:marcia]]

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.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

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 :-)

Comment 14

[Steven Michaud [:smichaud] (Retired)]

Here's a tryserver build made with my patch and that for bug 463363 (which has already been landed on the trunk):

https://build.mozilla.org/tryserver-builds/2008-11-06_13:[e-mail]-bugzilla463285/[e-mail]

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Now that the panel closes when clicking outside I cannot reproduce it any longer.

Comment 16

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Yes, you can if the tree is green.

Comment 18

[Henrik Skupin [:whimboo][⌚️UTC+1]]

As long as Steven isn't able to check-in, probably another one can do that meanwhile?

Comment 19

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 20

[Steven Michaud [:smichaud] (Retired)]

Landed on mozilla-central (changeset 796579e94fdc).

Comment 21

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Feature isn't anymore on 1.9.1 branch and was verified by me a month ago. Setting verified keyword.