Closed Bug 629324 Opened 13 years ago Closed 13 years ago

Mac OS X Menubar is inactive

Categories

(Core :: Widget: Cocoa, defect)

Product:
Core
Component:
Widget: Cocoa
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- final+

People

(Reporter: rik, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [mozmill][hardblocker])

Attachments

(1 file)

stack (debug build)
3.63 KB, text/plain
Details 
After using a Firefox nightly for a while, my menubar is sometimes inactive.

It's working fine in other apps but not when I'm in Firefox.

I don't have steps to reproduce this, sorry.
That's interesting that you have filed this bug because I see the same with current nightly builds by running our Mozmill tests. And I can reproduce it 100% of the time. Looks like a fairly recent regression. I will check.
blocking2.0: --- → ?
Keywords: regression, regressionwindow-wanted
Hardware: x86 → All
Whiteboard: [mozmill]
Regression is between 4.0b9 and 4.0b10. Will work on a daily window now.
Here some steps so it will be easier for you all to reproduce...

1. Download the test environment for OS X: http://people.mozilla.com/~hskupin/mozmill-crowd/mozmill-mac.zip
2. Unzip and run the setup.sh
3. Execute run.sh
4. Run hg clone http://hg.mozilla.org/qa/mozmill-tests/
5. Start Mozmill: mozmill -b /Applications/Minefield.app/ -t mozmill-tests/firefox/testAwesomeBar/
6. Wait until the location bar autocomplete dropdown opens and immediately open the bookmarks menu. Click around

With step 6 the Menu doesn't respond very sluggish or stops completely and stays open even you click somewhere outside in the browser window.
It's a Cocoa widget issue, so moving to the correct component.
Component: Menus → Widget: Cocoa
Product: Firefox → Core
QA Contact: menus → cocoa
Well, I see this too using the SeaMonkey-Trunk-Builds on MacOS X 10.6.6. I can reproduce the empty Menubar every time when I restarted SeaMonkey after using the Autoupdater.
Severity: normal → major
FWIW, last time I had this bug, I tried resizing the window (suspecting bug 625454) and it "fixed" the menubar.
(In reply to comment #6)
> Well, I see this too using the SeaMonkey-Trunk-Builds on MacOS X 10.6.6. I can
> reproduce the empty Menubar every time when I restarted SeaMonkey after using
> the Autoupdater.

An empty menu bar doesn't seem like the same issue.

In any case, it sounds like somehow our event loop is getting stuck in event tracking mode. Strange.
I'm not going to have time to work on this until sometime next week.
(In reply to comment #9)
> I'm not going to have time to work on this until sometime next week.

I'll back bug 625454 out in the meantime. Is that okay?
> I'll back bug 625454 out in the meantime. Is that okay?

Sounds good to me :-)

> it sounds like somehow our event loop is getting stuck in event
> tracking mode

Can someone post a gdb stack trace taken while this bug is happening?
It would (I think) confirm or deny Patrick's hunch.
(In reply to comment #11)
> Can someone post a gdb stack trace taken while this bug is happening?
> It would (I think) confirm or deny Patrick's hunch.

Means when the menu is open and doesn't react anymore?
(In reply to comment #12)
> (In reply to comment #11)
> > Can someone post a gdb stack trace taken while this bug is happening?
> > It would (I think) confirm or deny Patrick's hunch.
> 
> Means when the menu is open and doesn't react anymore?

Yeah.
Not sure, if that's what you want:

(gdb) backtrace
#0  0x00007fff886d22da in mach_msg_trap ()
#1  0x00007fff886d294d in mach_msg ()
#2  0x00007fff8004f932 in __CFRunLoopRun ()
#3  0x00007fff8004edbf in CFRunLoopRunSpecific ()
#4  0x00007fff87f6f93a in RunCurrentEventLoopInMode ()
#5  0x00007fff87f6f73f in ReceiveNextEventCommon ()
#6  0x00007fff87f6f5f8 in BlockUntilNextEventMatchingListInMode ()
#7  0x00007fff80441e64 in _DPSNextEvent ()
#8  0x00007fff804417a9 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#9  0x0000000100c7c803 in nsAppShell::ProcessNextNativeEvent ()
At least BlockUntilNextEventMatchingListInMode sounds suspicious.
Henrik's stack doesn't show event tracking mode on.

But it might also have been taken at the "wrong" time.  Switching to a Terminal window to take the stack might change conditions.  If you're using gdb from the command line, it's probably best to ssh in from another machine and use gdb in that session.

> BlockUntilNextEventMatchingListInMode ()

That's normal in every mode, I think.
> it's probably best to ssh in from another machine and use gdb in
> that session.

When doing this, you'll need to make gdb "attach" to an existing
browser parent process:

gdb firefox-bin [pid]
Another thing, Henrik:

We need the whole stack (on the main thread), not just the top part.

And please attach it instead of pasting it in :-)
Now tried from the console logged in via ssh:
#0  0x00007fff886d22da in mach_msg_trap ()
#1  0x00007fff886d294d in mach_msg ()
#2  0x00007fff8004f932 in __CFRunLoopRun ()
#3  0x00007fff8004edbf in CFRunLoopRunSpecific ()
#4  0x00007fff87f6f93a in RunCurrentEventLoopInMode ()
#5  0x00007fff87f6f73f in ReceiveNextEventCommon ()
#6  0x00007fff87f6f5f8 in BlockUntilNextEventMatchingListInMode ()
#7  0x00007fff80441e64 in _DPSNextEvent ()
#8  0x00007fff804417a9 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#9  0x0000000100c7c803 in nsAppShell::ProcessNextNativeEvent ()

That's everything. I don't get more output with bt.
OK, so Patrick's hunch seems to have been disproved -- we're not stuck in event tracking mode.
But there's another thing that's very peculiar about both your stacks,
Henrik:

> #9  0x0000000100c7c803 in nsAppShell::ProcessNextNativeEvent ()

I've never seen this at or near the bottom of a stack.

Either the rest of the stack is somehow missing, or something very
strange is going on.
Henrik, please redo your stack with a build that has optimization turned off (ac_add_options --disable-optimize).
I think the easiest thing here would be to really execute my steps from comment 4. Those can be done in under 2 minutes. I'm stuck here and it will definitely take more time for me, which I don't really have at the moment, to find out how to get you the correct stack. One of you should be able to get that information way faster with my steps.
I'll be back next week, then (probably late next week).
Attached file stack (debug build) — 
Ok, here a quick test with a debug tinderbox build downloaded from our FTP server. Is that better Steven?
> Is that better Steven?

Much better.  Thanks.

From this you can tell we *are* (probably) stuck in event tracking
mode (tracking the menu):

> ...
> #72 0x9857e7ac in IsUserStillTracking ()
> #73 0x9855f62a in TrackMenuCommon ()
> #74 0x985572bf in MenuSelectCore ()
> ...

I can't say more without digging into this bug myself.  For which I
probably won't have any time until late next week.
Yeah, that's what I suspected. I bet event tracking mode is activated during menu selection. I wonder if we can special case the native event suppression to only happen during resize, and not while the user is using a menu.
I also see a strange menubar behaviour with a current Thunderbird nightly (since 21. Jan), but I'm not sure if it is the same issue. So I will wait until this bug is fixed to see if it also fixes the TB thing.
So when Steven will be away the next couple of days, can we get the causing patch backed-out? It would be a bad user experience for Beta 11 for OS X users otherwise.
Yes, I'm in the landing queue to do so.
Bug 625454 has been backed out:

http://hg.mozilla.org/mozilla-central/rev/a7b806aebf09

(And rats, I got the bug number wrong.)
OK, let's let further work go on in bug 625454.
Status: NEW → RESOLVED
blocking2.0: ? → final+
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [mozmill] → [mozmill][hardblocker]
Yeah, works again. Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b11pre) Gecko/20110128 Firefox/4.0b11pre

Anthony, can you also please test?
Status: RESOLVED → VERIFIED
It doesn't seem fixed in my test with a 20110128 nightly.

It's the first time I'm running mozmill so not sure I'm doing it right. When the bar autocompletes, the bookmark menu doesn't respond. But just after, when there is no autocomplete, the bookmark menu responds again.
An easier way to reproduce are the following steps:
1. Download the nightly tester tools (https://addons.mozilla.org/de/firefox/addon/nightly-tester-tools/)
2. Update it's maxVersion so it is compatible with 4b11pre builds
3. Start Mozmill with "mozmill -b /Applications/Minefield.app -t mozmill-tests/firefox/ --addons=nnt.xpi
4. Try to select an entry from "Tools | Nightly Tester Tools | Crash me!"

Before the backout it was not possible for me.
Just to note, this also fixed the strange menubar behaviour in Thunderbird, I've mentioned in Comment 28. So it was the same issue.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: