Noticed on another computer, OS X 10.9.5, Firefox 38 beta buildid 20150330154247 . Don't see anything in the browser console. No (enabled) add-ons on this profile besides "Kitten Block" ( https://addons.mozilla.org/en-us/firefox/addon/kitten-block/ ).

Just tested with FF 38b1 on OS X 10.8.5 in a clean profile, and didn't see this. Please test that, with and without "Kitten Block".

I can't reproduce this testing on OS X 10.7.5, 10.9.5 or 10.10.2, either (still testing with FF 38b1). > Flags: qe-verify+ > Flags: in-testsuite? > Flags: firefox-backlog+ I don't understand what this means. We shouldn't track this in any way if it isn't reproducible.

I see this with Dev Preview on one of my 10.9.5 machine, but it doesn't reproduce using a clean profile.

Marcia, thanks very much in advance if you can figure out what in your "non-clean" profile triggers this bug!

I see this on Beta as well (I think I saw it on Dev Edition as well, not sure now), using Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Firefox/38.0 ID:20150330154247 CSet: 604367e1fa5e. I restarted with a fresh profile and I don't see it - went back to my existing profile and haven't yet been able to reproduce it - so far for me it seems to be an intermittent issue. I will keep an eye to see if it happens again. Here are my extensions: Extensions ---------- Name: ADB Helper Version: 0.7.4 Enabled: true ID: adbhelper@mozilla.org Name: Firefox OS 1.2 Simulator Version: 6.0pre9.20140401 Enabled: true ID: fxos_1_2_simulator@mozilla.org Name: Firefox OS Simulator Version: 4.0.2 Enabled: true ID: r2d2b2g@mozilla.org Name: Nightly Tester Tools Version: 3.7 Enabled: true ID: {8620c15f-30dc-4dba-a131-7c5d20cf4a29} Name: Test Pilot Version: 1.2.3 Enabled: true ID: testpilot@labs.mozilla.com Name: Valence Version: 0.3.0 Enabled: true ID: fxdevtools-adapters@mozilla.org Name: Norton Identity Toolbar for Firefox Version: 1.9.0f7 Enabled: false ID: nortonconfidential@symantec.com

(In reply to Marcia Knous [:marcia - use ni] from comment #6) > I see this on Beta as well (I think I saw it on Dev Edition as well, not > sure now), using Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) > Gecko/20100101 Firefox/38.0 ID:20150330154247 CSet: 604367e1fa5e. I > restarted with a fresh profile and I don't see it - went back to my existing > profile and haven't yet been able to reproduce it - so far for me it seems > to be an intermittent issue. I will keep an eye to see if it happens again. Same here. On the machine this happened on originally this has gone away again, and now I'm reproducing on my main dev machine.

Steven, is there something I can do to diagnose this when I have a reproducing instance beyond checking the browser console ?

Gijs, I have *no* idea :-( All I can suggest to you and Marcia is that you keep your eyes open. Since this is "intermittent", the profile may not matter ... or then again it might. It's also quite likely that it isn't "intermittent" at all, but that you just haven't noticed the STR yet. So please keep your eyes open :-)

> Gijs, I have *no* idea :-( But do also take a look at the system console (using the Console app in /Applications/Utilities).

I'm going to run FF 38b2 for a while as my main browser (on OS X 10.8.5). With luck I'll also see this bug, and be able to figure out the STR.

07/04/2015 14:54:48.672 firefox[41155]: GetDYLDEntryPointWithImage(/System/Library/Frameworks/AppKit.framework/Versions/Current/AppKit,_NSCreateAppKitServicesMenu) failed. This seems relevant... :-\

So it does. Let me see what information I can glean from that error message.

Gijs and Marcia: Do either of you have something "unusual" in your Services menu (in Firefox or in other apps like Safari)? In particular I'm looking for an Adobe app (since this error message seems to be associated with Photoshop and Adobe "After Effects" http://en.wikipedia.org/wiki/Adobe_After_Effects).

In fact do you have anything at all in your Firefox Services menu? I don't, on OS X 10.8.5.

> In fact do you have anything at all in your Firefox Services menu? > > I don't, on OS X 10.8.5. Or on OS X 10.9.5.

(In reply to Steven Michaud from comment #14) > Gijs and Marcia: > > Do either of you have something "unusual" in your Services menu (in Firefox > or in other apps like Safari)? In particular I'm looking for an Adobe app > (since this error message seems to be associated with Photoshop and Adobe > "After Effects" http://en.wikipedia.org/wiki/Adobe_After_Effects). No, I don't have either After Effects or Photoshop installed. (In reply to Steven Michaud from comment #15) > In fact do you have anything at all in your Firefox Services menu? > > I don't, on OS X 10.8.5. There isn't supposed to be anything there, AIUI, except if you select text (and/or maybe in input fields, haven't tried that). And that seems to be broken in e10s on Nightly, but works if you turn e10s off, at least.

Note that as the screenshot shows, the about/preferences/services items *don't show up at all* so I can't check this while keeping my "broken" instance running... which I'd like to keep doing for now both to keep all my open tabs and their contents, and so I can try any debugging steps...

> There isn't supposed to be anything there, AIUI, except if you select text Yes, this is correct. I didn't realize. > and/or maybe in input fields Not in my tests, at least. > while keeping my "broken" instance running Go ahead and keep it running. But please also test in Safari and other apps to see if anything "unusual" shows up in your Services menu while you have text selected.

In both Firefox and Safari, on both OS X 10.8.5 and 10.9.5, I see the following in my Services menu when I have text selected: Text Add to iTunes as a Spoken Track Make New Sticky Note New TextWrangler Document with Selection Searching Look Up in Dictionary Search With Google Messaging New Email With Selection Gijs and Marcia, please let me know what you see in addition to that (if anything). (In my case, the only service that didn't come with the OS is the TextWrangler one. Judging by the icon, the "Search With Google" service is provided by Safari.)

(In reply to Steven Michaud from comment #20) > In both Firefox and Safari, on both OS X 10.8.5 and 10.9.5, I see the > following in my Services menu when I have text selected: > > Text Add to iTunes as a Spoken Track > Make New Sticky Note > New TextWrangler Document with Selection Don't have this one, but I have 1 macvim and 3 openpgp items Then I have a: Files and folders: Tweet item. > Searching Look Up in Dictionary > Search With Google > Messaging New Email With Selection > > Gijs and Marcia, please let me know what you see in addition to that (if > anything). (In my case, the only service that didn't come with the OS is > the TextWrangler one. Judging by the icon, the "Search With Google" service > is provided by Safari.)

By the way, if there's STR for this bug it must (presumably) involve selecting text.

> GetDYLDEntryPointWithImage( > /System/Library/Frameworks/AppKit.framework/Versions/Current/AppKit, > _NSCreateAppKitServicesMenu) failed. Here's a declaration for the (undocumented) GetDYLDEntryPointWithImage(), which at least on OS X 10.8.5 is defined in the CarbonCore framework (inside the CoreServices framework): Boolean GetDYLDEntryPointWithImage(const char *path, const char *unused, const char *symbol, void **addr); Interestingly, the AppKit framework (at least on OS X 10.8.5) only contains a _NSCreateAppKitServicesMenu() method for 32-bit mode callers. But there's code in the HIToolbox framework (in a non-exported event handler) that uses GetDYLDEntryPointWithImage() to try to get a pointer to AppKit's _NSCreateAppKitServicesMenu method in 64-bit mode: ServicesHandleMenuEvent(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) This must be what's going on here, though I haven't yet figured out exactly how. And this is ultimately an Apple bug, though I haven't yet figured out why it doesn't happen all the time. The plot thickens.

(Following up comment #23) Same deal on OS X 10.9.5 and 10.10.2. I have a hunch this is a timing problem, and that if we create (or trigger the creation of) the services menu ourselves, at the "appropriate" time (whatever that turns out to be), we'll be able to work around this Apple bug.

Just a guess, but I wouldn't be surprised to find that STR for this bug includes selecting text and then pressing some kind of cmd+key combination (which would among other things try to bring up the Services menu).

Just saw this on Nightly. I was running a 3-16 build, launched it, and then updated to Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Firefox/40.0 ID:20150408030205 CSet: 078128c2600a. Quit the browser and the menu returned. In my case I didn't select any text. Both times it happened (on 2 different machines, 10.9.5 and 10.10.3), I believe I might not have been using the browser. I don't see anything odd in the Services menu on my 10.10.3 machine when text is selected. 10.10.3 machine has Adobe Lightroom installed, but not Photoshop.

Just to make sure: Marcia, when you see this bug happen do you see (in the system console) the message Gijs reported in comment #12? Gijs, do you always see that message when the bug happens?

I finally had this happen to me once, with yesterday's m-c nightly. I *don't* see Gijs's error message, so that must be a red herring.

(In reply to Steven Michaud from comment #28) > I finally had this happen to me once, with yesterday's m-c nightly. > > I *don't* see Gijs's error message, so that must be a red herring. Sounds like this is answered.

(In reply to Steven Michaud from comment #25) > Just a guess, but I wouldn't be surprised to find that STR for this bug > includes selecting text and then pressing some kind of cmd+key combination > (which would among other things try to bring up the Services menu). FWIW, I tried to use cmd-, to trigger this (to open the preferences menu) on Nightly and that didn't work. I also noticed that that doesn't flash the menu, so it seems the item is really not there...

Gijs and Marcia: Most of my STR hints above were based on Gijs's error message (about _NSCreateAppKitServicesMenu) being relevant. If it *isn't* relevant they're all invalid, and we're back to square one. I'll keep trying to reconstruct STR for the one instance I saw. But if that doesn't work out I'm going to give up on this bug. So, Gijs and Marcia, we really do need you to figure out STR, if that's at all possible.

Steven: I will try to see if notice this more consistently - as I said, so far I have only seen it twice, and I don't really a set of clear STR.

I've found I can simulate this bug by making nsMenuBarX::CreateNativeAppMenuItem() return null. Here's a test build that logs the various ways this can happen: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-b27af1d0543d/try-macosx64/firefox-40.0a1.en-US.mac.dmg https://treeherder.mozilla.org/#/jobs?repo=try&revision=b27af1d0543d Please test with this until you see the bug. Once you do see it, there should be interesting information in the system console (viewable using the Console app in /Applications/Utilities). Note that these messages will be logged when the browser starts up. So if you only discover the bug a while after the browser started, other messages may since have gotten logged to the system console, and you may have to scroll back to see the relevant ones. All the "interesting" messages will start with the following string: nsMenuBarX::CreateNativeAppMenuItem

(In reply to Steven Michaud from comment #33) > I've found I can simulate this bug by making > nsMenuBarX::CreateNativeAppMenuItem() return null. Here's a test build that > logs the various ways this can happen: > > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com- > b27af1d0543d/try-macosx64/firefox-40.0a1.en-US.mac.dmg > https://treeherder.mozilla.org/#/jobs?repo=try&revision=b27af1d0543d I was going to use beta with this patch because trunk will break indexeddb if I take the same profile back to release... but 'make check' failed. Should this worry me? :-) > Please test with this until you see the bug. Once you do see it, there > should be interesting information in the system console (viewable using the > Console app in /Applications/Utilities). Note that these messages will be > logged when the browser starts up. So if you only discover the bug a while > after the browser started, other messages may since have gotten logged to > the system console, and you may have to scroll back to see the relevant > ones. All the "interesting" messages will start with the following string: > > nsMenuBarX::CreateNativeAppMenuItem Interesting... do we call this every time you open the menu? Or on startup, or lazily the first time it's opened and then we keep it (for that window or for all windows?)? Trying to figure out if it makes sense to keep running an instance after successfully using the menu once... (I've had to reboot the machine for security updates so I no longer have the broken instance running)

> but 'make check' failed. Should this worry me? :-) I don't know for sure, but I really doubt it. Notice that it also failed for me. I'll investigate more fully before I land any debug logging on trunk (which I'm currently considering). I suspect it has something to do with turning on RTTI support (ac_add_options --enable-cpp-rtti), which my current debugging patch uses. I won't do that on trunk. > Interesting... do we call this every time you open the menu? Or on > startup, or lazily the first time it's opened and then we keep it > (for that window or for all windows?)? nsMenuBarX::CreateNativeAppMenuItem() is called several times, but only on startup. I don't yet know what the trigger is. But the bug may happen if it's called "too early". > Trying to figure out if it makes sense to keep running an instance > after successfully using the menu once... I think probably not -- I think the bug only happens on startup. > (I've had to reboot the machine for security updates so I no longer > have the broken instance running) I doubt this matters. I doubt there's anything you can tell from a running instance with the bug -- at least anything more than I've already been able to find out.

(In reply to Steven Michaud from comment #35) > I think probably not -- I think the bug only happens on startup. > > > (I've had to reboot the machine for security updates so I no longer > > have the broken instance running) > > I doubt this matters. I doubt there's anything you can tell from a > running instance with the bug -- at least anything more than I've > already been able to find out. Sure, but that means that if I have a working instance that's never going to reproduce, and so I should try restarting it. :-)

Yes :-)

More STR guessing: It now seems this bug only happens on start/restart. It may happen preferentially (or even only) on restart. Marcia saw it once on restarting after an update (comment #26). I saw it once restarting after choosing a profile in the Profile Manager. Gijs, does this fit your experience? Is it possible that you've only seen this bug on restarting (after an update or from the Profile Manager)? If I'm right, my tryserver build is only of limited use -- you can't update it. So I'm considering landing a variant of my debugging patch on the trunk (one that doesn't use RTTI). I'd mark it trunk-only, so it doesn't accidentally get into a release. Gijs, it sounds like this wouldn't help you, since you've stopped using m-c nightlies thanks to this change: https://groups.google.com/forum/?fromgroups#!topic/mozilla.dev.platform/3IqDew1O-Vk. But Marcia might find it useful, and so would I. One could always launch it from the Profile Manager, and let it update itself whenever it wanted to.

Here's another way to restart the browser, which works even with my tryserver build: Since it's built from trunk code, you can make it restart by turning e10s support off or on (in Preferences).

I've just restarted my tryserver build about 20 times in a row, either from the Profile Manager or by turning e10s mode off or on. I didn't see the bug even once. I tested on OS X 10.8.5 (where I was testing the one time I saw the bug).

Interestingly, though, I *did* trigger the GetDYLDEntryPointWithImage error several times in my tests this morning. For lack of anything better to do, I'll try to figure that out.

(In reply to Steven Michaud from comment #38) > More STR guessing: > > It now seems this bug only happens on start/restart. It may happen > preferentially (or even only) on restart. Marcia saw it once on restarting > after an update (comment #26). I saw it once restarting after choosing a > profile in the Profile Manager. Gijs, does this fit your experience? Is it > possible that you've only seen this bug on restarting (after an update or > from the Profile Manager)? I think this might be right. Note that profiles that need add-on updating might also induce restarts... I wonder if this is reproducible by downloading an old build, repeatedly copying it out of the DMG, opening it, and forcing it to update...

For what it's worth, I can make the GetDYLDEntryPointWithImage() error message appear 100% of the time by doing the following. But it happens in the Firefox instance that's triggering the restart, not the one that's restarting (in other words it happens *before* the restart). This is further evidence, I think, that it's unrelated (and also completely benign): 1) Run the Profile Manager (i.e. go to run FF from the Profile Manager, but don't yet proceed further). 2) Choose a profile, but don't double-click on it (e.g. click once on the profile). 3) Press Enter/Return to run FF from the selected profile, but keep holding the key down until after FF has restarted.

(Following up comment #43) In fact you also see the GetDYLDEntryPointWithImage() error message every time you press a cmd-key combination while the Profile Manager is running.

(Following up comment #44) Actually only the first time you press a cmd-key combination (any one) while the Profile Manager is running.

(Following up comment #33) > I've found I can simulate this bug by making nsMenuBarX::CreateNativeAppMenuItem() return null. I think I've found another way this bug can happen -- though (for reasons that aren't yet clear) I can't (yet) use it to simulate this bug. So I'm going to post another debug logging patch and tryserver build.

Tracking for 38. It seems likely this would affect 39+ as well.

I did see this again on a 10.9 machine when updating nightly. I had an older nightly on the machine, and then went to the about:firefox menu to check for updates. I believe after the update was applied by selecting the update button in the about:firefox dialog, only the quit button showed when hovering over the menu at the top of the browser.

I've tried to reproduce this on-purpose with both nightly and beta restarts and have so far been unsuccessful. :-( Marcia, when did you open the "Firefox" menu again after the update-induced restart? One thing which may or may not be related/helpful at all, and may be a total red herring (in fact, I suspect it is one!) is that it seems to me like the "about firefox" window sticks around for longer than it used to after clicking "Restart Firefox" when an update is available and staged. Going to CC + needinfo rstrong to see if he can think of anything that (semi-)recently changed regarding the update mechanism that might explain something like this. Answer might be "nope, no idea", but we won't find out without asking. :-)

We have mar signing on Mac but that is entirely outside of the application. I haven't heard anything like this happening and there has been a lot of testing done on Mac recently for the mar signing. Stephen, any ideas?

No, unfortunately I have no idea what might be the trigger here...

(In reply to :Gijs Kruitbosch from comment #49) > I've tried to reproduce this on-purpose with both nightly and beta restarts > and have so far been unsuccessful. :-( > > Marcia, when did you open the "Firefox" menu again after the update-induced > restart? > > One thing which may or may not be related/helpful at all, and may be a total > red herring (in fact, I suspect it is one!) is that it seems to me like the > "about firefox" window sticks around for longer than it used to after > clicking "Restart Firefox" when an update is available and staged. > > Going to CC + needinfo rstrong to see if he can think of anything that > (semi-)recently changed regarding the update mechanism that might explain > something like this. Answer might be "nope, no idea", but we won't find out > without asking. :-) I opened the menu right after the browser had restarted. As I noted in a previous comment, I have seen this happen intermittently and haven't been able to reproduce the issue each time I updated, which I usually do once a day on all my Mac machines.

Do you only see this after updating? Does it then start working later? You might want to try reproducing by installing an add-on that requires restarting since it is essentially the same process and is easier to repeat than installing updates.

Yes, so far I have only seen it on my machines when updating to the latest build. After I update, the quit menu is seen - restarting the browser again - the menu shows correctly.

It would be interesting to see if it can be reproduced when installing a non-restartless add-on since it is essentially the same process and is easier to repeat than installing updates.

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #55) > It would be interesting to see if it can be reproduced when installing a > non-restartless add-on since it is essentially the same process and is > easier to repeat than installing updates. I just tried three extensions that don't require a restart, and I didn't see the issue on a 10.8.5 machine which is the latest machine I have seen it on.

That would be expected with an extension that doesn't require a restart (e.g. a restartless extension). What would be interesting to see is if it can be reproduced when installing a NON-restartless add-on since it is essentially the same process and is easier to repeat than installing updates.

For example https://addons.mozilla.org/en-US/firefox/addon/saved-password-editor/

(In reply to Robert Strong [:rstrong] (use needinfo to contact me) from comment #58) > For example > https://addons.mozilla.org/en-US/firefox/addon/saved-password-editor/ Yes, tried that and wasn't able to reproduce the issue. Will keep trying some different scenarios with addons like that. I have now seen this on all the Mac machines I use: 10.8.5 Laptop 10.9.5 Mac Mini 10.10.3 - 2 different laptops

Stephen, could you try out Marcia's steps to reproduce over the next week to see if you can reproduce?

Just reproduced it again on an older 10.6.8 machine as well with Developer Edition. Exact STR I followed: 1. Started with an older Dev Edition build (20150318) that was installed on the Desktop (not in the Applications directory) 2. Updated that build to the latest build (20150417) by selecting About: Firefox in the FirefoxDeveloperEdition menu 3. When the update check, finishes, press the restart button. 4. When the browser restarts, I selected "Not Now" as far as making it the default browser. 5. Before doing anything else, I hovered over the FirefoxDeveloperEdition menu and observe only the quit menu is present.

I recall seeing something like that awhile back where on first run when one the app caches had to be rebuilt the menu wouldn't paint until the second time I opened a menu. No idea if there was a bug for it.

Marcia, try running a day or more older build, download a newer build, install the newer build on top of the older build, and launch it to see if that reproduces it.

Be sure to install the new build into the same location, app name, etc. as the old build.

First try, on a 10.10.4 machine using Steps from Comment 63 and Firefox Developer Edition - issue did not reproduce. I will rinse on repeat on all machines I have seen, and include nightly since I have seen it there as well.

After re-reading the comments it appears that smichaud has reproduced using the profile manager which also does a restart. Have you been able to also reproduce it using the profile manager.

I just tried the steps in comment 61, with the older dev edition build being from 2015-03-21. I've been unable to reproduce the problem so far.

I need to land some debug logging on the trunk, which I'll make trunk-only. Then we'll all need to test with trunk builds until someone sees this bug again. I should be able to get that done in the next few days. I doubt it's worth spending more time trying to figure out how to reproduce this bug.

(In reply to Steven Michaud from comment #68) > I need to land some debug logging on the trunk, which I'll make trunk-only. > Then we'll all need to test with trunk builds until someone sees this bug > again. I should be able to get that done in the next few days. > > I doubt it's worth spending more time trying to figure out how to reproduce > this bug. Agreed - I have spent a fair amount of time starting and restarting various ways and haven't been able to yet nail down steps, although I have seen it on a variety of machines. I haven't see the issue with profile manager, only updating the browser.

Here's my debug logging patch. I've added NSLog() calls at every point where things happen which I think can trigger this bug. These messages should appear both in the system log (/var/log/system.log) and in Terminal (if you run FF from there). Messages in the system log can be viewed using the Console app (in Applications : Utilities). I've prevented this stuff from ever getting into a release. But once it's on the trunk it will get into both "regular" and "debug" mozilla-central nightlies. And if need be we can uplift it to aurora, where it will get into the Developer Edition. Once this gets into mozilla-central nightlies (or the Developer Edition), people will need to run those distros until they see this bug, then use Console to look at the system log and report here what they see. Even that data (once we have it) may not be enough to decipher this bug. But at the very least it should allow me to revise this patch to look for more data.

Thanks, Pulsebot, glad to meet you :-)

Anybody see this since my debug logging patch landed on the trunk (in the 2014-04-24 nightly)?

Steven: Have not seen it yet, but I am updating nightly every day to see if I can reproduce it.

Too late for 38 but we can take a patch for 39 if you have a fix.

I haven't seen this, but I also don't habitually run Nightly. I'll try updating it more regularly.

(In reply to Steven Michaud from comment #74) > Anybody see this since my debug logging patch landed on the trunk (in the > 2014-04-24 nightly)? Yes, here is an example log from latest nightly. 2015-05-13 13:30:12.615 firefox[12405:707] nsMenuBarX::ConstructFallbackNativeMenus(): labelUTF16 Quit, keyUTF16 q It happens pretty often for me. So I'm happy to help get to the bottom of this.

(In reply to comment #79) Yes, but are those messages associated with this bug? I've seen them, too -- but *never* associated with this bug. If I remember right, you see them when you use the Profile Manager.

> If I remember right, you see them when you use the Profile Manager. I see them whenever the Profile Manager starts up.

(In reply to Steven Michaud from comment #80) > (In reply to comment #79) > Yes, but are those messages associated with this bug? Yes, I got the truncated Firefox menu on that instance. It happens relatively frequently.

(In reply to comment #82) Sigh. So I'm going to need to figure out how to distinguish when the Profile Manager is running and "normal" Firefox is running, and only write to the syslog in the latter case. New patch coming up in the next few days. Its logging should be much more informative, though -- since I'll be able to use what I landed at bug 1159473, which can log stack traces.

Hi, I just signed up here to contribute to this bug. I'm not an expert, but maybe my input can be of a little help anyway: I encountered the bug after installing FF 38.0.1 on Mac OS X 10.10.3 Deactivating all add-ons fixed the problem, so I tried to find out which of the add-ons was responsible. Turns out it was "StartupMaster" (https://addons.mozilla.org/de/firefox/addon/startupmaster/). I can reproduce the bug by starting FF with the add-on activated. If StartupMaster is deactivated, FF runs fine. I hope the bug can be fixed soon, since I really like the functionality that is provided by the add-on. Right now, I prefer to have it activated even though that means the menu bar will not work properly. If any of you guys know a similar (but working) add-on, please feel free to let me know. Thanks for all your work!

Thanks, clabastian. Your information may be critical to fixing this bug. I won't be able to resume working on this bug until next week or the week after -- other more urgent things have preempted it. But when I do come back, the first thing I'll do is test your STR.

This may be caused by extensions or other circumstances that cause a modal window (or perhaps any window) to be opened very early. I can reproduce this problem using the StartupMaster extension -- but only if a master password has been set, which causes StartupMaster to force the password prompt to be displayed before any browser windows are opened. And we are also seeing this problem with Tor Browser (which we are in the process of moving from an ESR 31 codebase to an ESR 38 codebase). In the Tor Browser case, we bundle a Tor Launcher add-on which opens a settings wizard or status/connecting dialog during the "profile-after-change" notification.

I wonder if the modal dialog thing could be the update/addon-compat dialog that disappears quite quickly. It wouldn't appear every update though, so I'm surprised it would show up for within-the-same-release-number nightly updates, for instance. It could be that the Nightly issue that Marcia was seeing was for the updates to 41 on various machines? Marcia, do you know if you reproduced after the update to 41?

Hooray! Clabastian's STR from comment #84 works! I still don't have time for this bug, but I hope to be able to come back to it in the next few days. Other attempts to reproduce it or understand it can cease ... short of working from clabastian's STR.

I had this issue and had lastpass installed but not enabled. I was on 37.0.1. and went to 38. I know someone had this issue with only last pass addon but enabled.

I'm back on this bug and am working on a patch. When it's ready I'll post it and a tryserver build (for others to test).

Here's a possible fix. I've started a set of tryserver builds: https://treeherder.mozilla.org/#/jobs?repo=try&revision=b159ba935175

Here's a tryserver build made with my patch from comment #92: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/smichaud@pobox.com-b159ba935175/try-macosx64/firefox-41.0a1.en-US.mac.dmg Whoever's seen this bug, please test with it and let us know your results.

I wonder how this should be tested. We don't have updates available for try server builds and as far as I got from this bug and others, which have been duped against this one, this is necessary. No-one has seen it yet by simply starting Firefox.

(In reply to Henrik Skupin (:whimboo) from comment #94) > I wonder how this should be tested. We don't have updates available for try > server builds and as far as I got from this bug and others, which have been > duped against this one, this is necessary. No-one has seen it yet by simply > starting Firefox. Read comment #88 and comment #84

(In reply to Steven Michaud [:smichaud] from comment #93) > Whoever's seen this bug, please test with it and let us know your results. I have applied the patch to our ESR 38 branch and the issue is fixed in the resulting build. Thanks!

Anyone who sees this bug using the master password dialog (with or without an extension) should be able to test with my tryserver build. But it's true that those who only see this bug on updating will only be able to test my patch after it's landed on the trunk. This patch does seem to work, and is the best I can think of on current evidence. It makes sure that, if for some reason we've created a "crippled" app menu (one that only contains "Quit"), we dump it before going into full UI mode (so that another app menu gets created that's more appropriate). This patch is very simple, and it's possible (though I think very unlikely) that (in its current form) it may cause crashes when sApplicationMenu is re-created. But if that happens, the crashes' cause should be quite obvious, and we can deal with the problem when/if it happens.

These started with the firefox-2015-02-19-03-02-04-mozilla-central nightly. And so they did indeed start on the 38 branch.

Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?&fromchange=9696d1c4b3ba&tochange=360b5f211180

I have no idea which patch in that range triggered this bug. Hopefully it doesn't matter.

(In reply to Steven Michaud [:smichaud] from comment #102) > I have no idea which patch in that range triggered this bug. Hopefully it > doesn't matter. In case it does matter for some reason, I think it was this one: http://hg.mozilla.org/mozilla-central/rev/c87629c34fcc (bug 1127205)

(In reply to comment #103) Yes, that makes a lot of sense. I agree it's a very likely candidate.

I am currently trying to identify the changeset using a binary search. We'll see if I come up with the same result. More interestingly, I applied the patch to the 38.0.5 release and it didn't fix the issue for my test case. I will try again with a clean build in case gremlins in the build system interfered, and confirm. But we might not have got to the bottom of this bug yet.

My patch from comment #98 is in mozilla-central nightly builds starting with today's. Please test with it/them and let us know your results. I'm particularly interested in hearing from Ben Schmidt.

Reporting back that building from the Hg repo from the FF 38.0.5 release tag, with the patch applied (which didn't apply cleanly as I didn't apply the previous debug-adding patch, but nevertheless all but removing the debugging code applied), with a clean build, does NOT fix this issue for me. The build is currently breaking for me (or I've updated to a wrong revision), so I can't try building from current mozilla-central. And I know this may sound ridiculous, but I can't afford decent Internet at home at the moment, so can't afford to download the ~100MB nightly build. I will do so on Tuesday (AEST--Monday afternoon PDT) and report back.

I can now confirm that change c87629c34fcc introduced this bug (at least for my second test case).

I can now further confirm that the current Nightly (http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-central/firefox-41.0a1.en-US.mac.dmg) does NOT fix the problem for me. Let me know if/how I can help further to diagnose/fix this. I am a programmer, though my time and knowledge of the Mozilla codebase and workflow is limited. However, I do have the Hg repository checked out already, so can easily test patches, etc., but you'll need to be quite specific about which revision to update to, etc., as I don't know how all the branches relate to each other.

What we need now, Ben, is precise, detailed descriptions (steps to reproduce) for the bug(s) my patch doesn't fix. Whatever resources these steps use will need to be publicly available.

Hi, Steven. You can use the second scenario in bug 1170889. I believe your patch fixes the first scenario there. Ben.

I'm also seeing this on 38.0.5, Mac OS 10.10.3.

Jen, please report if you still see the bug with today's mozilla-central nightly (which contains my fix from comment #98).

I downloaded Nightly, and the About menu is there. However, I notice something else. There's an issue with Tree-style Tabs and the notification within at the top of the browser page. I'll email a screenshot to Liz Henry to find out how/if to report it.

(In reply to comment #112) I've had to put this bug aside again. Hopefully I'll be able to get back to it next week.

Comment on attachment 8614895 [details] [diff] [review] Remove debug logging and fix this bug Approval Request Comment [Feature/regressing bug #]: bug 1127205 [User impact if declined]: Users of password managers likely to see this bug [Describe test coverage new/current, TreeHerder]: Baked for 2 weeks on m-c [Risks and why]: Low risk. The patch is extremely unlikely to cause trouble, though it may not fix all cases of this bug. [String/UUID change made/needed]: None This patch doesn't (apparently) fix all cases of this bug. But it probably fixes the great majority, and is low risk. So let's get it on aurora and beta now. If I find a better fix later, we can uplift that as needed.

Comment on attachment 8614895 [details] [diff] [review] Remove debug logging and fix this bug Important to take this even though we're late in beta because it's a regression very noticeable to many users. Approved for uplift to aurora and beta

Comment on attachment 8614895 [details] [diff] [review] Remove debug logging and fix this bug Landed on mozilla-aurora: https://hg.mozilla.org/releases/mozilla-aurora/rev/73a10017683c

Comment on attachment 8614895 [details] [diff] [review] Remove debug logging and fix this bug Landed on mozilla-beta: https://hg.mozilla.org/releases/mozilla-beta/rev/9b8f7ed4e0d2 (Note that I didn't have to remove the debug logging patch from the 39 branch, since it never landed there.)

Hi! I'm concerned that this bug is marked fixed, etc. when so far the fix is only partial. Of course, a partial fix is better than no fix, and nothing wrong with pushing it out to beta, but this still does need further work. Should we perhaps 'unduplicate' bug 1170889 since it contains the STR for the unfixed cases, and close this bug?

> Should we perhaps 'unduplicate' bug 1170889 since it contains the STR for the unfixed cases, > and close this bug? Yes, things are a bit confusing. But I don't think we need to do any of this. When I once again have time for this, I'll come back to it at bug 1170889. Remind me if I forget, by needinfoing me on bug 1170889.

Because this issue was affecting Thunderbird 38 users, we landed it in the THUNDERBIRD_38_VERBRANCH of mozilla-esr38: https://hg.mozilla.org/releases/mozilla-esr38/rev/07b9ccbfb490

Reproduced the initial issue using Firefox 38.0.1 on Mac OS X 10.10, verified that the issue is fixed using Firefox 39 beta 7, latest Aurora and Nightly.

I had the same issue in 38 and after reading the tread I downloaded beta 39. Still have the issue. Any thoughts anybody?

Steven, I can also (intermittently, of course) trigger this in TenFourFox on 10.4/10.5. The patch seems like it would work there as well. I notice it's been landed on T-bird, but would you be fine with nominating it for regular uplift to ESR38? It seems low risk and high yield. If not, I'll add to our local changesets.

(In response to comment #128) First check to be sure you're running at least FF 39 beta 7 (the first beta containing my patch). Then, if you still see the problem, please open a new bug. Be sure to use publicly available resources and provide detailed, precise steps to reproduce.

Thanks Steven. I have downloaded Firefox 39.0b7 and still have the issue. Opening a new thread. Appreciate your help.

Comment on attachment 8614895 [details] [diff] [review] Remove debug logging and fix this bug I'm happy to ask for approval to upload this to ESR38, but I'm not entirely sure it's appropriate (since it isn't a security fix). [Approval Request Comment] If this is not a sec:{high,crit} bug, please state case for ESR consideration: This patch fixes a bad UI bug that's often encountered, especially by people who use password managers. User impact if declined: Bad UI bug, often encountered by users of password managers. Fix Landed on Version: 41 Risk to taking this patch (and alternatives if risky): Low risk String or UUID changes made by this patch: None See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

I support the ESR38 approval request. Because the ESR cycle is long, users without this fix will be stuck with this bug for about 10 months. Also, this is a regression from ESR31.

#1177197 is not a duplicate of this bug, I can also reproduce it with the patch.

I can still reproduce this consistently in Nightly in a new empty profile with the following command line: /Applications/FirefoxNightly.app/Contents/MacOS/firefox -p "Test" -jsconsole -purgecaches One difference seems to be that, with -purgecaches, the Browser Console opens first, whereas without it the browser window opens first. I've also gotten it to occur intermittently in other situations without -purgecaches (but still with -jsconsole) where the Browser Console opening first isn't predictive. (We're also seeing it with standard launching in Zotero Standalone, using Firefox 39 as XULRunner, but since that's a more complicated situation I'll hold off on that until we debug this in Firefox itself. But started there with recent versions as well.)

Comment on attachment 8614895 [details] [diff] [review] Remove debug logging and fix this bug Based on the comments, I don't feel we have nailed down all the scenarios in which this bug surfaces so far. ESR releases typically have a high bar and focus primarily on security bug fixes and as such this bug does not meet that bar. Thanks!

Chiming in that I've been seeing this bug for a while now, and am still seeing it on 39.0 (it just happened to the copy I'm writing this on!) This is on Yosemite 10.4. From the discussion above I seem to gather that a lot of people were (only?) seeing the problem occur immediately upon opening Firefox, but I know this copy was working fine when I opened it early this morning--the app menu was empty upon returning just now, after 8+ hours idle. This agrees with my general observation that the bug will just happen over time, but I tend to have 2-3 copies of Firefox open with different profiles on two different computers, and before this bug they would all tend to be open for days. Now I'm restarting annoyingly often, because when the app menu goes, it takes with it my ability to hide the application with Cmd-H. One more note: another copy of Firefox that was opened at approximately the same time as the now-bugged one is working fine.

(In reply to comment #138) There are still some edgecases where this bug still happens. I'll be working on them at bug 1181977. If you have reliable steps to reproduce, please comment there. If you don't then keep your eyes open -- maybe you'll be able to find STR.

Found an instance with the Firefox menu only showing Quit today. From about:support, I'm running FireFox 42.0 build 20151029151421, OS is Mac OS 10.7.5. Not sure if I can reproduce this bug.

(In reply to Glenn Johnson from comment #140) > Found an instance with the Firefox menu only showing Quit today. From > about:support, I'm running FireFox 42.0 build 20151029151421 I wouldn't worry about it unless you see it in Fx43. Additional edge cases (bug 1181977) were fixed in 43, not 42.