Closed Bug 641597 Opened 9 years ago Closed 4 years ago
Main menu stops working after a while of using Firefox 4
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_6) AppleWebKit/534.24 (KHTML, like Gecko) Chrome/11.0.696.3 Safari/534.24 Build Identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0) Gecko/20100101 Firefox/4.0 The file menu stopped working after using Firefox 4 RC1 for a span of hours. I can still use the file menu in other applications if I switch to other apps, but whenever I switch back to Firefox, the menu does not respond to any clicks. (Apple Firefox File Edit View History Bookmarks Tools Window Help). Restarting Firefox temporarily fixes the issue. Reproducible: Always
Is only the file menu affected or all menus? Do you see any error in the Error Console for that issue?
Version: unspecified → Trunk
It's the file menu (the one shared by all applications in OS X), but it's only unresponsive in Firefox 4 RC. Switch to another application like Chrome or iTunes, and it behaves normally. The menulet icons on the right behave just fine in either situation. Is there a keyboard shortcut to trigger the error console? I can't access it from the file menu if this happens.
So you mean the whole main menu bar at the top of the screen? You can hit Cmd+Shift+J to open the error console. But as it sounds you will not see an error in such a case. But please report back first.
I am also experiencing this problem. All menu items on the left side of the menu bar (Apple menu through Help) are unresponsive. The non-Firefox-specific items on the right (system clock, battery level, etc...) are working just fine. The problem is somewhat recent: I was using the FF4 betas for a while, and this started happening with the RC.
Chris, can you reproduce this constantly? Do you see any error in the error console? Does it also happen in Safe Mode with all extensions disabled? Or even with a fresh profile? http://support.mozilla.com/en-US/kb/Managing+profiles
Summary: File menu stops working after a while of using Firefox 4 RC1 → Main menu stops working after a while of using Firefox 4 RC1
I can reproduce this, but I'm not sure what causes it, so it can take a day or two of using the browser to reproduce. I tried Safe Mode and the menu was still working after a couple of days. I am now selectively disabling extensions to see if a bad extension is the problem. I just got the bug with both Firebug and Test Pilot enabled, and now I am going to try with only Test Pilot enabled. Pressing Ctrl-F2 selects the menu and apparently gives it focus, because I am then able to select menus and menu items. However, once I click on a menu item (or otherwise cause the menu to lose focus -- e.g., click on the page), the menu becomes unresponsive again. It seems like the menu is just fine -- the problem is that something is intercepting the mouse click events before they reach the menu? The error console has the following messages: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIURI.host]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: resource://testpilot/modules/feedback.js :: FeedbackManager_isInputUrl :: line 109" data: no] Error: uncaught exception: [Exception... "Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIIOService.newURI]" nsresult: "0x804b000a (NS_ERROR_MALFORMED_URI)" location: "JS frame :: resource://testpilot/modules/feedback.js :: FeedbackManager_isInputUrl :: line 107" data: no] These are repeated, especially the first one listed here. Don't know if it's related to the problem, though (possibly the Test Pilot extension causing the problem?).
Gordon, does disabling Test Pilot fixes it for you? Jono or Tracy, is this problem somewhat known already?
I've had Test Pilot running for a while with no problems. Switching off Test Pilot 1.1 and switching on Firebug 1.7.0...
(In reply to comment #7) > Gordon, does disabling Test Pilot fixes it for you? Jono or Tracy, is this > problem somewhat known already? I haven't seen the issue come up recently, and it was nearly impossible to intentionally reproduce the issue to begin with, so I have no additional data to provide at this time.
There could have been a study in test pilot which caused this problem for you. If that study has been finished already, you will not see it anymore. As long as we do not have more information I will close this bug as incomplete. Feel free to reopen if it happens again. Thanks.
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → INCOMPLETE
I had exactly this bug for a while with Firefox 4.0. Never used the RC1, and never had the Test Pilot installed. It happened very consistently, between 0.5 and 2 hours after starting Firefox. I did CC myself to this bug on 2011-04-01, but it hasn't happened in a few days now. I think I was using the browser quite heavily when it occurred, browsing some large, picture-heavy pages, had possibly a few tabs open, and haven't been doing that when it hasn't happened. (I started out with a virgin profile for Fx4.0, and have only imported bookmarks and installed 12 extensions.)
Now it happened again, with Firefox 4.0. I'm leaving the browser up running if theres's something I should check ?
This time the menu stopped working around 8 hours after Firefox was started. I can't think of anything particular I was doing, and I didn't have many tabs or any particularly big pages or images loaded this time. The browser is still running with the non-responding menu bar, in case there is anything I should check before I restart it.
Arne, have you ran Firefox in safe mode when this problem happened for you? If not please do so and check again. Also a test with a fresh profile would be good. http://support.mozilla.com/en-US/kb/Safe+Mode http://support.mozilla.com/en-US/kb/Managing+profiles
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: INCOMPLETE → ---
Well, to check again would consist of waiting for the bug to happen, and in the last three days of 7-hours-a-day-on-and-off surfing it has happened 3 times, once 8 hours after Firefox was started, once after a few minutes, and once somewhere in-between. I think I could make 3 new profiles, one with half of my current extensions, one with the other half, and a third fresh one running in safe mode, and then run them in parallel, using them alternately. How about that? Is there anything particular I could look for when the bug occurs? (I grepped the system log for firefox, and there was something about "plugin-container ... invalid context" that once seemed too occur at roughly the same time as the bug, but that actually occurs much more often than the bug does.)
Josh and Steven, have you both an idea what could be done here to investigate that problem even more beside running in safe mode? Arne, that should work, even it could take a longer time to verify.
Can you guys please post the list of the installed extensions? You can find those in the troubleshooting page (help | troubleshooting information). Thanks.
Adblock Plus 1.3.6 British English Dictionary 1.19.1 Context Search 0.4.6 Dictionary Switcher 1.0.1 QuickJava 1.7.2 Resurrect Pages 2.0.6 Status-4-Evar 2011.04.06.18 Stop Autoplay 1.2.1 Stylish 1.1.1 SubmitToTab 0.3.5.1 United States English Spellchecker 5.0.1 YesScript 1.9
Good, came from Bug 647889, glad I'm not alone with this issue. It's so sporadic, can't tell what's causing it. Error console doesn't save..need to keep it open. Is there a ability to output the Error console results to a file? Posting extensions so we all are on the same page (all updated): Ad Block Plus **match to Arne** Back To Top Click&Clean Close Tab by DoubleClick Dictionary Tool Tip Flagfox Ghostery Locator Make Address Font Bar Size Bigger New Tab Homepage NoScript NoSquint SmoothWheel Status-4-Evar **match to Arne** Tab Scope Theme Font & Size Changer TinEye Reverse Image Search WOT HTTPS Everywhere (via Electronic Frontier Foundation) I think we have a possible with Status-4-Evar, lots of people use Ad block Plus.
Looking at my backups, I installed Status-4-Evar on 28 Mars, and I do recall having the bug a couple of days before 1 April, when I cc'd myself here. Also, I don't think I have had the bug with my regular profile since it was updated on Sunday 10th to the current version of Status-4-Evar (2011.04.06.18). This may of course be coincidental ...
I have disabled the Status-4-Evar Add-on, awaiting to see if that fixes the issue.
The Status-4-Evar I installed on 28 Mars was version 2011.03.21.22. The bug occurred consistently from around that time to around 2 April, with the same version still installed. Then it stopped, and then it occurred sporadically (just 3 times) from 8 April to 10 April. On 10 April, version 2011.04.06.18 was installed, and the bug hasn't yet occurred since then. There likely was an upgrade to version 2011.04.01.00 somewhere between 2 April and 10 April, but if Status-4-Evar is the culprit, the bug not occurring from 3 April to 7 April can't be explained by that upgrade (I was thinking of a buggy version followed by a bug-free version followed by a new buggy version, but it doesn't fit). So maybe it's just coincidence. None of my other extensions changed at all since 24 Mars (except for an ABP upgrade). I have restored my profile from 1 April to see if the bug will show up again.
Has anyone had this bug without Status-4-Evar installed ?
I have never installed Status-4-Evar, and I have had this bug.
I have seen this occur prior to the S4E extension, including the early 4.0 betas before it was required, and with different profiles. It's hard to narrow the conditions under which it occurs; most often, it manifests itself after an extended browsing session wherein only one window is used with many tabs opened and closed during that period. The remedy is simple, however--closing that window and opening a new one restores functionality to the menu bar. But it can be inconvenient to have to "lose" a bunch of tabs when one is in private browsing mode with no history being recorded.
Has anyone had this bug occur with just default install of Firefox with no plug-ins/add-ons? Reason why I ask is there is a new Flash exploit making the rounds again, and if carmudgeon is right, the exposure across multiple sites increases the chance of encountering the bug, may be contained to one window. For a Windows user it would likely exploit their machine, perhaps for OS X it just locks the FF menu?
I have the nagging suspicion this has something to do with private browsing mode. Does everyone who's seen this bug use private browsing mode? Or has anyone seen this bug who doesn't use private browsing mode?
I don't use private browsing mode.
> I don't use private browsing mode. One hypothesis shot down :-) Thanks for the info.
No private browsing mode here neither. Problem has not occurred since Status-4-Evar and the plug-ins: Flash, iPhotoPhotoCast, Java and Quicktime been disabled. Will enable one at a time until problem resurfaces. Enabling Status-4-Evar
I just experienced a fresh occurrence, after a browsing session with multiple Flash elements, including a few video clips, and a product showcase with animation. Normally, I rarely click on Flash elements at all (FlashBlock is one of my extensions). Just an observation; not enough to draw a correlation. However, while the menu bar was non-functional, I did toggle in and out of Private Browsing mode, and it had no effect on the menu bar, which remained broken.
Problem just occurred here too, 1 hour and 15 minutes since enabling Status-4-Evar in my last post. Flash and all other plug-ins are turned off like I've mentioned above. Error from yahoo.com: (have seen this before without the bug) Error: uncaught exception: [Exception... "Component returned failure code: 0x805e0006 [nsIDOMLocation.replace]" nsresult: "0x805e0006 (<unknown>)" location: "JS frame :: http://mail.yimg.com/d/combo?... :: line 12" data: no]
Wild theory, it took me a bit to discover I had the bug, could have been 30 minutes or so easily. I'm wondering if it's something at occurs at set times, like 5:00 PDT is one of them?
No occurrence of the bug since applying Security Update 2011-002 (released on April 14, 2011). Same status as before, Status-4-Evar enabled, no Flash or plug-ins enabled http://support.apple.com/kb/DL1376
I have seen this recently on my Mac with only Test Pilot 1.2preX enabled on Fx 4. Not sure how to reproduce. I am testing around the auto-submit pref. That may be causing it, trying again to repro....
Spoke too soon, just occurred again. Menu frozen solid. Nothing in the Error logs, yet again. Ok, disabling Status-4-Evar, sure like to get it out of the way as a possible. Firefox 4 is just too dam sexy for it's shirt :)
(In reply to comment #38) > Ok, disabling Status-4-Evar, sure like to get it out of the way as a possible. Did that help? I haven't seen a reply in the last 8 days. (In reply to comment #37) > I have seen this recently on my Mac with only Test Pilot 1.2preX enabled on Fx > 4. Not sure how to reproduce. I am testing around the auto-submit pref. > That may be causing it, trying again to repro.... Tracy, did that happen again?
(In reply to comment #39) > > That may be causing it, trying again to repro.... > > Tracy, did that happen again? I was not able to find steps to reproduce this. My gut feeling is this may be something in Fx JS somewhere that some extensions are triggering.
>Did that help? I haven't seen a reply in the last 8 days. Yes Henrik, no occurrence of the issue since I removed Status-4-Evar 8 days ago. Not saying it's specifically responsible. Perhaps it's just the icing on the cake? Conflict? I'll download and install it fresh, see if the issue occurs again, if it does I guess the next step is to run just it alone.
(In reply to comment #41) > I'll download and install it fresh, see if the issue occurs again, if it does I > guess the next step is to run just it alone. Right. Please use the same version as before, just in case it got an update with a fix.
Status-4-Evar 2011.04.06.18 installed...same add-ons as before, plugins enabled. Here little bug...got a nice cracker for you...
Summary: Main menu stops working after a while of using Firefox 4 RC1 → Main menu stops working after a while of using Firefox 4.0
I think it's gone, hard to attribute what fixed it. A re-download of Status-4-Evar or the OS X update that just occurred.
Perhaps the Firefox 4 on OS X memory leak issue is really the culprit? https://support.mozilla.com/en-US/questions/811790 I've noticed the memory usage drop from apx 425 to 390 just doing nothing. I do notice problems running Firefox with other large OS X applications, I thought it was the other program, but it's Firefox I got to force quit when it's hung.
(In reply to comment #45) > Perhaps the Firefox 4 on OS X memory leak issue is really the culprit? > https://support.mozilla.com/en-US/questions/811790 I don't think so. I can see the same as reported on that link but I have never experienced the menu hang. > I've noticed the memory usage drop from apx 425 to 390 just doing nothing. Well, that's the garbage collector which frees unused memory. So that's a good thing. :)
(In reply to comment #46) > > Perhaps the Firefox 4 on OS X memory leak issue is really the culprit? > > https://support.mozilla.com/en-US/questions/811790 We track that on bug 634895 now.
Finally! Had the menu lock occur without Status-4-Evar. It seems to occur, like the other bug reports says, by having a lot of open/closing of tabs for awhile. Status-4-Evar accelerates the occurrences of menu lock in my case. When I have huge memory needs like from a virtual machine, FF locks up more often. I've done extensive memtests, bad sector map off, reinstalled FF, all add-ons, OS X, just to rule those out.
Like I stated before, this predates the S4E extension in my experience. In my usage, I find that resource-intensive browsing seems more likely to trigger the issue, whether viewing lots of large images from imageboards, or watching video. More recently, I observed that viewing a variety of different flash videos (each their own players), soon after launch, was all it required. That suggests to me that it's not necessarily confined to a longer-term session, or one with lots of tabs used.
Yes carmudgeon your correct, the more resource-intensive the browsing, the easier it is to trigger the menu lock. Video's and images for you, S4E for myself. Take a look at this I've found: "While in both Firefox and Chrome, memory does tend to increase the longer you use the browser (e.g. if you keep opening and closing a bunch of tabs) but it isn't a memory leak. What is actually happening in both browsers is that when you open a new tab, if the browser doesn't have enough memory for the tab the browser requests more memory from the OS. Then when you close a tab, the memory is not deallocated, instead that memory is held by the browser in case the user wants to open a new tab, the browser does not have to request more memory from the OS. If it was a memory leak, then the browser wouldn't be able to reuse this memory. I've only seen it become bothersome once in Chrome when the memory reach around 2GB after the person used Chrome for about a week without closing it." I also read on the Apple Developer site that OS X assigns certain portions of memory as executable as a security feature. So perhaps the two are conflicting? It used to be in the Classic OS days we could increase the memory needs of programs to deflect these sort of lockup issues. Does anyone have a idea how I can increase FF's default memory footprint?
Not strictly related, but I'm also having high memory usage on Firefox 4.0.1 on Mac 10.6.7, which then leads to Firefox crashing. Anyone here facing problems similar to Bug 642351 ?
An update. I stopped using 4.0, and dabbled some with the 5.0 betas, but have been mainly using the 6.0a builds ever since they moved to the Aurora channel, and it has been smooth sailing since. However, after I updated to the June 23 6.0a2 build (from the June 21; skipped the 22nd) whatever changed in the interim brought this bug back to life.
I've been using Aurora for awhile now, starting with a clean profile, and have consistently had this problem while Aurora was on the 5.0 line and now that it is on the 6.0 line as well. Didn't see anything in the error console, but I'll look again when it happens again. Could there be something to look for in the Mac OS X Console?
I have the menu bar problem as well - it comes and goes without any trigger that I can discern. However, reading through the comments I did notice that I have a plugin in common with two other posters (AdBlock Plus). Also, note that this problem didn't start for me until I switched to Firefox 4 - which was also the same time that I added Adblock Plus. I'm going to try removing it and see what happens. P.S. Thanks for the tip on Ctrl+(Fn+)F2 to access the menu bar... very useful.
I haven't had any recurrences of this bug in 5.0.
I've had this bug since FF 4.0 days (as far as I can remember), and I continue to have it in FF 5.0.1 on Snow Leopard. I do have Adblock Plus installed, if that helps any in solving this bug.
I've also had this happen from FF 4.0 through 5.0.1. It just happened again this afternoon, which led me to this bug. I'm in the "seems to happen with lots of tabs/media" camp. Anyway, here are some interesting entries from the system console: 8/2/11 3:17:14 AM [0x0-0x1b01b].org.mozilla.firefox firefox-bin(1206,0xa0501540) malloc: *** mmap(size=140087296) failed (error code=12) 8/2/11 3:17:14 AM [0x0-0x1b01b].org.mozilla.firefox *** error: can't allocate region 8/2/11 3:17:14 AM [0x0-0x1b01b].org.mozilla.firefox *** set a breakpoint in malloc_error_break to debug 8/2/11 3:17:14 AM [0x0-0x1b01b].org.mozilla.firefox firefox-bin(1206,0xa0501540) malloc: *** mmap(size=140087296) failed (error code=12) 8/2/11 3:17:14 AM [0x0-0x1b01b].org.mozilla.firefox *** error: can't allocate region 8/2/11 3:17:14 AM [0x0-0x1b01b].org.mozilla.firefox *** set a breakpoint in malloc_error_break to debug 8/2/11 3:17:14 AM [0x0-0x1b01b].org.mozilla.firefox Tue Aug 2 03:17:14 localhost firefox-bin <Error>: CGDataProviderCreateWithCopyOfData: failed to vm_allocate 140083200 bytes: 3. 8/2/11 3:17:14 AM [0x0-0x1b01b].org.mozilla.firefox firefox-bin(1206,0xa0501540) malloc: *** mmap(size=140083200) failed (error code=12) 8/2/11 3:17:14 AM [0x0-0x1b01b].org.mozilla.firefox *** error: can't allocate region 8/2/11 3:17:14 AM [0x0-0x1b01b].org.mozilla.firefox *** set a breakpoint in malloc_error_break to debug 8/2/11 3:17:23 AM [0x0-0x1b01b].org.mozilla.firefox firefox-bin(1206,0xa0501540) malloc: *** mmap(size=140087296) failed (error code=12) 8/2/11 3:17:23 AM [0x0-0x1b01b].org.mozilla.firefox *** error: can't allocate region 8/2/11 3:17:23 AM [0x0-0x1b01b].org.mozilla.firefox *** set a breakpoint in malloc_error_break to debug 8/2/11 3:17:23 AM [0x0-0x1b01b].org.mozilla.firefox firefox-bin(1206,0xa0501540) malloc: *** mmap(size=140087296) failed (error code=12) 8/2/11 3:17:23 AM [0x0-0x1b01b].org.mozilla.firefox *** error: can't allocate region 8/2/11 3:17:23 AM [0x0-0x1b01b].org.mozilla.firefox *** set a breakpoint in malloc_error_break to debug 8/2/11 3:17:23 AM [0x0-0x1b01b].org.mozilla.firefox Tue Aug 2 03:17:23 localhost firefox-bin <Error>: CGDataProviderCreateWithCopyOfData: failed to vm_allocate 140083200 bytes: 3. 8/2/11 3:17:23 AM [0x0-0x1b01b].org.mozilla.firefox firefox-bin(1206,0xa0501540) malloc: *** mmap(size=140083200) failed (error code=12) 8/2/11 3:17:23 AM [0x0-0x1b01b].org.mozilla.firefox *** error: can't allocate region 8/2/11 3:17:23 AM [0x0-0x1b01b].org.mozilla.firefox *** set a breakpoint in malloc_error_break to debug
ChrisX, great to hear that you can reproduce this issue constantly. Would you mind helping us here to nail down the issue so we could have an initial starting point to fix it? We would really appreciate that. For the beginning it would be wonderful if you could test the beta releases of Firefox 4, which you can find here: ftp://ftp.mozilla.org/pub/firefox/releases/ If you can tell us between which versions the mentioned issue occurs the first time we would already be a bit closer. I will follow-up with more instructions then. Thanks a lot!
The problem starts with FF 4.0beta3. Beta2 and beta 1 don't have the problem. At least I was unable to trigger it although I tried very thoroughly for an extended period of time to avoid chance. Beta 3 and all versions after it have the bug, and it is easily and instantly triggered. The very first Tenfourfox version publically released (TFF 4.0beta7) also has the problem. Coincidentilly (?) beta 3 is the first version to show the fake greyish-blue Leopard style folder icons in the toolbar by default. Disabling the icons (via userChrome.css) does not fix the problem, though. NB: All my Macs are PPC machines, so I'm testing the PPC component of the universial binary. The last official FF version I can test is 4.0beta6. After that, the builds are Intel only. Tested on PowerBook G4 7450 Mac OS X 10.5.8
Ok, that already gives us a better idea. There are still a lot of changes which went in for beta 3 so we have to nail down the regression range to a specific day. Here is what we got so far: PASS: Firefox 4.0b2 from 20100720190347 FAIL: Firefox 4.0b3 from 20100805192522 That means all the nightly builds between those two dates would have to be tested for this bug. You can do that as best when bisecting the date range. Start with the build from July 28th first and divide the remaining range by 2. All the builds you can find under the following location: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/ Navigate to the month and download the mozilla-central build from the appropriate day. In case of above it would be: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/07/2010-07-28-03-mozilla-central/firefox-4.0b3pre.en-US.mac.dmg Thanks a lot for your efforts in taking this task!
No big deal. I don't know how long this would have taken on Windows, though. Thanks for suggesting the bisecting method, saved me a lot of time… I tested some more in-between and around just to make sure my results and triggering method are consistent. I also tripple-checked Gecko/20100727 to make sure it *really* passes (it does). BTW, the added folder icons in the bookmarks toolbar are not the culprit. Mozilla/5.0 (Macintosh; PPC Mac OS X 10.5; rv:2.0b2pre) Gecko/20100720 Minefield/4.0b2pre: pass Mozilla/5.0 (Macintosh; PPC Mac OS X 10.5; rv:2.0b3pre) Gecko/20100722 Minefield/4.0b3pre: pass Mozilla/5.0 (Macintosh; PPC Mac OS X 10.5; rv:2.0b3pre) Gecko/20100724 Minefield/4.0b3pre: pass Mozilla/5.0 (Macintosh; PPC Mac OS X 10.5; rv:2.0b3pre) Gecko/20100726 Minefield/4.0b3pre: pass Mozilla/5.0 (Macintosh; PPC Mac OS X 10.5; rv:2.0b3pre) Gecko/20100727 Minefield/4.0b3pre: pass Mozilla/5.0 (Macintosh; PPC Mac OS X 10.5; rv:2.0b3pre) Gecko/20100728 Minefield/4.0b3pre: fail Mozilla/5.0 (Macintosh; PPC Mac OS X 10.5; rv:2.0b3pre) Gecko/20100729 Minefield/4.0b3pre: fail Mozilla/5.0 (Macintosh; PPC Mac OS X 10.5; rv:2.0b4pre) Gecko/20100805 Minefield/4.0b4pre: fail
(In reply to ChrisX from comment #62) > Mozilla/5.0 (Macintosh; PPC Mac OS X 10.5; rv:2.0b3pre) Gecko/20100727 > Minefield/4.0b3pre: pass > > Mozilla/5.0 (Macintosh; PPC Mac OS X 10.5; rv:2.0b3pre) Gecko/20100728 > Minefield/4.0b3pre: fail Can you start those two builds, open about:buildconfig, and give us the changeset ids? That way we can get the list of check-ins which happened during this day.
Mozilla/5.0 (Macintosh; PPC Mac OS X 10.5; rv:2.0b3pre) Gecko/20100727 Minefield/4.0b3pre: changeset - 48244:0ed73d56efd5 Mozilla/5.0 (Macintosh; PPC Mac OS X 10.5; rv:2.0b3pre) Gecko/20100728 Minefield/4.0b3pre: changeset - 48287:beab39d49de9
May I also point to bug 587358 and repeat what I said in comment 58 above: When I rightclick the nonworking Menu bar, I get a contextual menu that I should get when rightclicking a toolbar in the browser window.
Steven, is there anything in this range which could have caused this issue at least on PPC? http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0ed73d56efd5&tochange=beab39d49de9 Marcia, could we get this tested on our PPC box in the QA lab?
Based on Chris' STR, I'm suspicious of bug 552982. I still don't know why 10.4 would be fine with it. Steven, anything that might have changed in widget behavior between 3.6 and 4 that might be related? We link against the 10.4SDK in TenFourFox and it still happens in 10.5, so it's not that. It would be nice to see if an Intel Mac user can reproduce with Chris' steps. He attached a bookmarks file to our TenFourFox tracking bug that people can try (link in comment 58). I use 10.4 to develop, so it's hard for me personally to test.
(In reply to comment #66) > Steven, is there anything in this range which could have caused this > issue at least on PPC? Nothing stands out. (In reply to comment #67) > Based on Chris' STR, I'm suspicious of bug 552982. Are you able to reproduce the bug? And if so, are you able to build the tree just before and just after this bug landed, to see if it triggered the problem? > I still don't know why 10.4 would be fine with it. Steven, anything > that might have changed in widget behavior between 3.6 and 4 that > might be related? I have no idea. And I no longer have a PPC machine to test on. So it's unlikely that I'll be able to fix this bug if it turns out to only be easily reproducible on PPC.
Alas, no, I don't run 10.5 on PPC. I'm tempted to commandeer my father's 10.5 G4 mini, but that will have to wait until I visit the folks' next.
Went to an Apple dealer and pretended interest in a MacBook Pro running 10.6.8. Downloaded FF 6.0.2, created some bookmark folders in the bookmarks toolbar and was able to reproduce the bug twice in a row before a store assistent started occupying me. (The 10.7 Macs on display were secured against arbitrary downloads.) Note that it takes considerably longer to trigger the bug on Intel – about 40 swipes left and right with the method described above instead of just 10 or less on PPC. This is why we see only few bug reports.
I was also able to trigger the bug on my sister's eMac (G4/10.5.8/TenFourFox).
I did it! Though only once so far. I used ChrisX's STR from comment #58, in FF 6.0.2 on a 2-3 year old Intel MacBook Pro running OS X 10.5.8. I'll try to find time in the next couple weeks to dig further.
I hadn't seen much, if any recurrence of this bug during the period of v8-10a. However, with v11.0a2, it has returned. Perhaps it's a coincidence, or maybe there's some correlation, but image-heavy sites seem to trigger the behavior. I did make a new discovery though--previously the only way to restore menu function was to close the affected window, and open a new one. I've now found that issuing a command to customize the toolbars (invoked via a right click, and not the menu, obviously), will restore menu function for the affected window. It's not necessary to actually make any changes, just opening the button palette and closing it is sufficient. Keyboard commands have always been unaffected, and Private browsing mode seems to make no difference either.
The problem was there all along. I'm using 10.0 now (TenFourFox), and it's still there. Coincidentally, I also wanted to post additional measures how to „cure“ the problem. In addition to closing all browser windows, and carmudgeon's discovery, you can also toggle Tabs on top, and the menue bar becomes functional again.
Looks like Version should be Trunk rather than "4.0 Branch" ?
I'm unable to trigger this bug in TenFourFox 12 and 13. So I figure it must have been repaired (maybe by accident) somewhere between FF 11 and 12.
I get this bug on 14.0.1, running on a MBP (intel). Screen menubar becomes unresponsive. I searched for: firefox mac screen menu bar unresponsive - and found this bug. Here is the default user-agent string: "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20100101 Firefox/14.0.1"
On FF25 I had the same problem, uninstalled 'WiseStamp', restarted and the menu bar was back to normal again. Still having issues with the navigation buttons. Navigation buttons show as disabled but after switching tabs they seem to function ..
WFM per reporter's comment 5. Anyone still seeing a problem with firefox started in safe mode, please file a new bug report
Status: NEW → RESOLVED
Closed: 9 years ago → 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.