Closed Bug 515700 Opened 16 years ago Closed 16 years ago

[10.6] Browser freezing when clicking 'Help'

Categories

(Firefox :: Menus, defect, P2)

Product:
Firefox
Component:
Menus
Version:
3.5 Branch
Platform:
x86
macOS
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 3.7a1
Tracking Flags:
Tracking Status
status1.9.2 --- beta2-fixed
status1.9.1 --- .8-fixed

People

(Reporter: mac, Assigned: smichaud)

References

(Regressed 1 open bug,
URL
)

Details

(4 keywords)

Attachments

(3 files, 3 obsolete files)

Trunk patch, updated to current code
3.69 KB, patch
jaas
: review+
Details | Diff | Splinter Review
1.9.1 branch patch, updated to current code
4.75 KB, patch
jaas
: review+
dveditz
: approval1.9.1.8+
Details | Diff | Splinter Review
1.9.2 branch patch, updated to current code
4.77 KB, patch
jaas
: review+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 If you click 'Help', the browser freezes for about 10 seconds, then unfreezes and shows the menu. I've attached a video; note: the video does not show the 'loading' wheel. Reproducible: Always Steps to Reproduce: 1. Click on Help (at the top) Actual Results: Freezes, then unfreezes after 10 seconds, after unfreezing the menu runs slowly as well. Expected Results: Instantly shown the menu
OK, if you start Firefox in safe mode, or create a new profile (or both) does it happen? http://support.mozilla.com/en-US/kb/Safe+Mode http://support.mozilla.com/en-US/kb/Managing+profiles
Severity: critical → major
Keywords: hang
Version: unspecified → 3.5 Branch
Creating a new profile fixes it, running in safe mode does not.
Probably an extension is causing this. Please disable them one by one, and then contact the developers of the one that is causing the issue. If all addons are disabled, and it still happens, it could simply be profile, so support can help you migrate your data over to the new profile.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
As the reporter said safe mode doesn't help. So it cannot be the fault of an extension because all of them are disabled. Reporter would you like to help us in finding the cause? If yes then please make a backup of your entire profile which shows this problem and delete file by file while firefox is not running. Start with prefs.js which contains all the preferences. When you have found the causing file we can do further steps and you can restore the former profile data. Thanks.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Does it only happen the first time or an each menu access? Could be related or a dupe of bug 504670.
Actually, it could be a the fault of an extension if Firefox was not closed down properly when safe mode was entered.
It cannot reuse a profile which is in use already. I would tend to exlude this assumption. Reporter, please report back.
no, what I meant is that if you open safe mode while you already have the firefox.exe process (ie, another windows) open, it will simply open a new, normal mode window. New profile is a simple way to ensure that there is not another firefox.exe process running.
Disabling all addons does not fix the problem.
Well I don't mind creating a new profile etc by myself But is there any more information you need? or should I just sort it out for myself, and leave it at that?
If you have time it would be great when you could follow the steps I pointed in comment 4. If the profile doesn't have private data in it you can also send it to me and I could analyse. But mostly thats not the case.
I don't mind following those steps What order shall I delete the files? And should I delete a file, reopen firefox, (problem persists), quit firefox, delete file etc etc
Right, I tried this and it appeared the problem was only solved after deleting all files. (I tried file by file, but it didn't help) Only fixed when all deleted.
That would be a really rare case I never had before. Keep in mind that some files are recreated after starting Firefox again. If you still feel ok to dig into it a bit more we should temporarily move the conversation to private email and continue here when we found the issue. If you don't have time for that please resolve this bug as WFM.
Yes, that's fine.
Please don't close as WFM. I can reproduce it. Current Shiretoko hangs for about 10 seconds when I try to open the Help menu. Shark shows lots of sqlite activity going on. After deleting places.sqlite, the Help menu works as fast as ever again. A little more digging showed that it seems to be bookmark tags which cause the problem. I have 47 of them, lots of bookmarks have multiple tags, and I have a tags folder on my bookmark toolbar (place:type=6&sort=1). The delay in opening the Help menu gets shorter and shorter the more of those tags I remove. With no tags at all, or (with tags but) without the tag folder on the toolbar, the Help menu opens instantly. (Note that the tag folder itself opens instantly, it only seems to be a problem when opening the Help menu).
yeah, this worked for me too.
Juergen, how often does it hang within a session? Only the first time when you access the menu or all the time? Further it would be good to know if a current nightly build of Firefox 3.6 shows the same problems for you or not. You can download it from the location below. Please think about making a backup of your profile first because this version is in alpha state. http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2/ If it solves the problem we should continue our work on bug 504670. Thanks for the additional information.
Works fine for me in Namoroka. On Shiretoko, opening the Help menu again right after closing it works fast. After doing a bit of work in the browser, the delay is there again, though. I also see most (sometimes all) Help menu items, including 'Check for Updates/'Apply downloaded update' grayed out sometimes. Not sure if it is related and what triggers it, it doesn't happen when opening the Help menu right after starting Shiretoko.
Thanks Juergen! One more question. Do you only see it with the help menu or are also other menus affected? I would like to dupe this bug against bug 504670.
Hi, I'm from a dupe. I'm only seeing this behaviour on the help menu and none of my other menus are affected.
Same here: happens with the Help menu exclusively. On first look bug 504670 might be a gconf thing which isn't used on OS X and it affects all menus. I'd say it's a different issue.
Ok, so it will be a different issue. Thanks for x-checking. Would someone has a bit of time and could check the 1.9.2 nighly builds back in time when this bug has been fixed on trunk/1.9.2 branch? The URL below gives access to nightly builds. Please use a copy of your profile for testing. Help would be really appreciated because I cannot reproduce this problem and cannot check on my own. Thanks! http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/
I experienced this behavior after upgrading my Mac to Snow Leopard (OS X 10.6); the bug was consistently reproducible. After I removed all add-ons and trashed all Firefox prefs, the Help menu began working properly again. I re-installed only two add-ons, StumbleUpon and FireBug. After installing those two add-ons, I noticed a slight delay after clicking on the Firefox Help menu before the menu was displayed, and I noticed that all of the menu items in the Help menu were disabled (gray). Uninstalling FireBug returned the Help menu function to normal. I hope this is helpful to those who are working on the problem. Regards, Doug
Doug, Please talk to firebug it=f their addon is causing slowdowns. If it ends up being our fault, they can tell us exactly where.
Fails up to: 2009-06-29-04-mozilla-central Fixed in: 2009-06-30-03-mozilla-central I don't see firebug playing a role here.
I have the same problem and I do not have Firebug. I also recently upgraded to Snow Leopard and I've only noticed the problem since then
http://hg.mozilla.org/mozilla-central/rev/8a9a15acc15c ? (a shot in the dark, I didn't try it yet) Anyway, the question is why opening the Help menu accesses places (and tags in particular) at all. Are the "release notes", "report broken web site" URLs stored there?
(In reply to comment #28) > Fails up to: 2009-06-29-04-mozilla-central > Fixed in: 2009-06-30-03-mozilla-central Thanks for your investigation. Could you please check about:buildconfig and post the changeset id's here?
Ok, sorry guys. I missed the 10.6 part. I can now reproduce this problem even with the todays Minefield build. It looks like that it hasn't been solved yet. Lets wrap-up the steps again: 1. Bookmark a couple of pages and assign a lot of tags to those bookmarks 2. When you have more than ~50 tags create a copy of the tags folder on the bookmarks toolbar 3. Open the Help menu Marco, do you imagine how it can affect opening the help menu?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf
Well, for me the problem is fixed (or at least the delay is no longer noticeable) by merging http://hg.mozilla.org/mozilla-central/rev/b1b2f9a366ca (from 2009-06-30-03-mozilla-central) and http://hg.mozilla.org/mozilla-central/rev/8a9a15acc15c into Shiretoko.
This reminds me a bit of bug 414699. That was fixed by my patch for bug 426499. But it's possible the fix was broken or disabled by 10.6. I'll take a closer look when I have time (probably later this week).
Attached patch Possible patch (1.9.1 branch) (obsolete) — — Splinter Review
> That was fixed by my patch for bug 426499. But it's possible the > fix was broken or disabled by 10.6. This turns out to be true -- the fix was disabled by 10.6. Here's a patch that re-enables it. And here's a tryserver build made with the patch (on the 1.9.1 branch -- i.e. FF 3.5.X or Shiretoko): https://build.mozilla.org/tryserver-builds/smichaud@pobox.com-bugzilla515700-debug-191branch/bugzilla515700-debug-191branch-macosx.dmg Whoever can reproduce these hangs, please try this out and let us know your results. This problem seems to have been fixed (in a different way) on the trunk and the 1.9.2 branch (Namoroka). So perhaps it's best to backport those fixes to the 1.9.1 branch (as suggested in comment #33). But if that's not practical (for some reason), my patch is at least a reasonable fallback. If it actually solves the problem. So please test!
this does appear to solve the problem.
(In reply to comment #36) > this does appear to solve the problem. Thanks for letting us know! I'd also like to hear from the rest of you. (Following up comment #35) > This problem seems to have been fixed (in a different way) on the > trunk and the 1.9.2 branch (Namoroka). Actually maybe not, or at least not fully -- Henrik says the following in comment #32: > I can now reproduce this problem even with the todays Minefield > build.
Fixes it for me too. Namoroka doesn't show long delays for me, but your tryserver build is definitely faster. The menu opens almost instantly instead of maybe 0.2s in Namoroka. So there's probably another change in Namoroko which made the problem pretty much non-existent with my bookmarks.
Summary: Browser freezing when clicking 'Help' → [10.6] Browser freezing when clicking 'Help'
Thanks, Juergen, for your information. Here's another tryserver build made with the patch from comment #35, this time on the trunk (mozilla-central, Minefield): https://build.mozilla.org/tryserver-builds/smichaud@pobox.com-bugzilla515700-debug/bugzilla515700-debug-macosx.dmg Those who can reproduce bug 513048 (on the trunk) should also try this.
fwiw, i see this on mac 10.5 and minefield.
> fwiw, i see this on mac 10.5 and minefield. Then good STR for what you see would be *really* useful. I suspect it's a different bug, though.
1. click help. 2. beachball for 30+ seconds. 3. help menu opens. no other menu shows the behavior. safe mode does not help. new profile does not show the problem.
> 2. beachball for 30+ seconds. This doesn't happen for me (testing with today's Minefield nightly on OS X 10.5.8). But I don't have a complex profile. Here's something that could be very useful: Download a Minefield Shark build, get it to hang for 30 seconds (using your STR), and use Shark to profile it while it's hung. Then attach your profile here.
The shark profile was too large ~2.5M to attach and wasn't decreased enough in size after bzip2ing. I did several sessions. The first showed the hang but interestingly the second and subsequent ones didn't. The difference appears to be sqlite related. The >1% entries were: 4.6% 4.6% mach_kernel ml_set_interrupts_enabled 3.8% 3.8% libobjc.A.dylib objc_msgSend 2.5% 2.5% libsqlite3.dylib sqlite3Step 2.1% 2.1% libobjc.A.dylib __spin_lock 1.9% 1.9% libsqlite3.dylib sqlite3BtreeMovetoUnpacked 1.9% 1.9% libSystem.B.dylib szone_free 1.7% 1.7% libmozjs.dylib js_Interpret 1.2% 1.2% libSystem.B.dylib tiny_malloc_from_free_list 1.2% 1.2% CoreFoundation __CFBagFindBuckets2 1.1% 1.1% XUL PL_DHashTableOperate 1.0% 1.0% libmozjs.dylib js_LookupPropertyWithFlags
(In reply to comment #42) > no other menu shows the behavior. safe mode does not help. new profile does not > show the problem. Bob, can you get rid of the prefs.js in the affected profile? Looks like that a user set pref is responsible for it.
> The shark profile was too large ~2.5M to attach and wasn't decreased > enough in size after bzip2ing. That's really too bad. Could you try sampling for a shorter period of time? And by the way, does the _SimulateMenuOpening() method show up anywhere in your traces? That's the sign of Apple's attempt to index all our menus when the Help menu is opened, which triggers this bug on 10.6, and used to trigger all kinds of problems on 10.5. > The difference appears to be sqlite related. That doesn't surprise me. I suspect the sqlite stuff also shows up on SnowLeopard. I'm not sure what we can do about it. I'm quite sure there's nothing *I* can do about it :-) I think your information about sqlite performance problems (possibly menu related) should go into another bug -- possibly into a new bug. A quick search for 'sqlite' in the bug summary found the following. I'm not sure if any of them is appropriate for your new information. Bug 514187 Bug 489173 Bug 506676 > Bob, can you get rid of the prefs.js in the affected profile? Looks > like that a user set pref is responsible for it. Do this, but please keep a copy of your old profile to test with!
The problem was with the large (~21M) places.sqlite file. Testing a new profile with my old prefs.js did not shot the problem, but copying the large places db into the profile did. I can not reproduce the problem with Namoroka.
Attached patch v1.1 trunk patch (obsolete) — — Splinter Review
Bob emailed me a link to his Shark profile, which (I think) has allowed me to figure out why he's seeing this bug on OS X 10.5.8, despite my patch for bug 426499 (which landed long ago). The trunk no longer builds or runs on OS X 10.4.X. And there's now a section of code in nsMenuX.mm (in the MenuDelegate class) that's only compiled when the minimum supported OS version is 10.5 or greater. This section contains a couple of methods (menuWillOpen: and menuDidClose:) that can be called from _SimulateMenuOpening() or _SimulateMenuClosed() when, on OS X 10.5 and higher, you open the Help menu. (When you open the Help menu the OS "simulates" opening all of FF's menus, so as to be able to index them.) These methods (menuWillOpen: and menuDidClose:) didn't exist when I landed my patch for bug 426499, so I wasn't able to stop them calling other code when the OS tries to "open" all of FF's menus at once. This patch takes care of the problem. A tryserver build will follow eventually. Please try it, Bob, once it becomes available. I think it will resolve your 30-second hang on OS X 10.5.8. > I can not reproduce the problem with Namoroka. I'm glad to hear this. Namoroka still works on OS X 10.4, and so doesn't contain the menuWillOpen: and menuDidClose: methods. Which means you shouldn't see hangs with it opening the Help menu on OS X 10.5.X.
(In reply to comment #49) > Here's the trunk tryserver build made with my v1.1 patch: works like a charm!
Excellent! Thanks for letting me know.
(In reply to comment #50) > (In reply to comment #49) > > Here's the trunk tryserver build made with my v1.1 patch: > > works like a charm! Given the success of the tryserver build, do we just need to find someone to review the patch? (I'm on 10.5.8 with the symptoms as Bob described in comment #42.)
I was waiting for someone to test whether not this patch also resolves bug 513048. But it doesn't look like anyone is willing/able to do that. On Monday I'll update this patch to current code and ask for a review.
(In reply to comment #53) > I was waiting for someone to test whether not this patch also resolves > bug 513048. But it doesn't look like anyone is willing/able to do > that. Sadly not. I don't have a native 10.6 installation running. Otherwise I would already have done this. Sorry. I think that should block 3.6.
Assignee: nobody → smichaud
Status: NEW → ASSIGNED
Flags: blocking-firefox3.6?
Tomcat has 10.6. Maybe he can test. See comment 53.
I have 10.6 too. What I need is people who have 10.6 and who can reproduce bug 513048 (I can't), and who are also willing to test this bug's patch (and tryserver build).
Steven: I am now back in the office and I can check Bug 513048 for you - I will report back. The difficult issue about that bug is it is not always reproducible.
Here are patches for the trunk, the 1.9.2 branch and the 1.9.1 branch, updated to current code. Tryserver builds will (I hope) be available by tomorrow morning. My patch for bug 426499 and bug 414699 stopped the OS from (virtually) opening all of FF's menus at once, in order to index them. This stopped a bunch of other problems from happening (on OS X 10.5.X, and before the menuWillOpen: and menuDidClose: methods were added to current trunk code). My patches for this bug make my earlier fix also work on OS X 10.6.X. My trunk patch makes it also work in current trunk code (on either OS X 10.5.X or 10.6.X). Though this bug's problems are (probably) at least partly Firefox's fault (particularly the sqlite hangs), there are definitely Apple bugs on 10.5 that need working around (see bug 426499). And there may also be different Apple bugs tnat need working around on 10.6 (see bug 513048). Sqlite problems of one kind or another have been troubling us for some time (see for example bug 454457 and bug 499124). They generally aren't easy to fix. This patch, which works around some of them, is very simple and self-contained. I think it makes a lot better sense to take this patch now (on the trunk and all branches) than to wait for the sqlite hangs problem to be fixed.
Attachment #402427 - Attachment is obsolete: true
Attachment #404346 - Attachment is obsolete: true
Attachment #406560 - Flags: review?(joshmoz)
Attachment #406561 - Flags: review?(joshmoz)
> Sqlite problems of one kind or another have been troubling us for some > time (see for example bug 454457 and bug 499124). The second bug should be bug 449124.
Oops, the previous patch was broken.
Attachment #406561 - Attachment is obsolete: true
Attachment #406569 - Flags: review?(joshmoz)
Attachment #406561 - Flags: review?(joshmoz)
(In reply to comment #64) > (In reply to comment #63) > > > https://build.mozilla.org/tryserver-builds/smichaud@pobox.com-bugzilla515700/bugzilla515700-macosx.dmg > > help works for me with no delay on 10.5. Thanks! The tryserver build works great for me as well -- the Help menu appears right away after clicking on it. (I'm on 10.5.8.)
Flags: blocking-firefox3.6? → blocking-firefox3.6+
Keywords: regression
Priority: -- → P2
I just tried out the 3.6 beta on 10.6 Snow Leopard - the bug is still there.
The fix has not yet been checked in. Please try the Tryserver builds in Comment 63 if you want to confirm the issue is resolved. (In reply to comment #66) > I just tried out the 3.6 beta on 10.6 Snow Leopard - the bug is still there.
Thanks. I can confirm that fixes it, yep.
Would be good to get this in the next beta release so we can get some wider testing.
Attachment #406560 - Flags: review?(joshmoz) → review+
On the current beta (3.6b1) this problem is still present, but instead of freezing for over 30s and not loading, firefox freezes for ~5s and the menu loads fine.
Josh says we should let this bake on the trunk for a day or two before landing on the 1.9.2 branch.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
v slow help menu on 10.5 is now fixed. thanks!
Attachment #406569 - Flags: review?(joshmoz) → review+
Landed on the 1.9.2 branch: http://hg.mozilla.org/releases/mozilla-1.9.2/rev/6a95f4955a3a I'll let it bake there for a while before seeking 1.9.1-branch approval.
status1.9.2: --- → beta2-fixed
(In reply to comment #73) > v slow help menu on 10.5 is now fixed. thanks! That means it's verified on trunk.
Status: RESOLVED → VERIFIED
Target Milestone: --- → Firefox 3.7a1
Henrik, the original bug is for 10.6. I think we should have someone with 10.6 verify the bug.
Thanks Bob. I missed that. Reverting to Resolved. Anyone who was able to see this bug on 10.6 could check tomorrows 1.9.2 nightly build is highly welcome. Here the url: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.2/
Status: VERIFIED → RESOLVED
Closed: 16 years ago → 16 years ago
Problem is still there in 1.9.2 nightly build. And I'm running 10.6 :)
(In reply to comment #78) > Problem is still there in 1.9.2 nightly build. > And I'm running 10.6 :) The todays builds aren't out yet. Please check the above URL in about 2-3 hours again when the links will mention November 7th. Thanks.
Just checked now - the bug is fixed in 3.6b2 nightly build.
(In reply to comment #80) > Just checked now - the bug is fixed in 3.6b2 nightly build. Thanks for checking it! Marking as verified fixed on 1.9.2.
Keywords: verified1.9.2
Attachment #406562 - Flags: review?(joshmoz) → review+
Comment on attachment 406562 [details] [diff] [review] 1.9.1 branch patch, updated to current code As I said in comment #74, I'd like this to bake on the trunk and the 1.9.2 branch for a while before landing it on the 1.9.1 branch. But the approval queue is probably at least a week long, so I'll seek approval now.
Attachment #406562 - Flags: approval1.9.1.7?
Comment on attachment 406562 [details] [diff] [review] 1.9.1 branch patch, updated to current code Approved for 1.9.1.8, a=dveditz for release-drivers
Attachment #406562 - Flags: approval1.9.1.8? → approval1.9.1.8+
(In reply to comment #80) > Just checked now - the bug is fixed in 3.6b2 nightly build. Mac@live.ba, could you do us a favor and also check a recent Shiretoko build so we can verify this bug will be fixed for Firefox 3.5.8 too? You can grab a build from here: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/01/2010-01-28-03-mozilla-1.9.1/ Thanks!
Will not work with ATT Yahoo ne mail server 3.5.8
Regressions: 1182229
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: