Closed Bug 414699 Opened 17 years ago Closed 16 years ago

Help menu extremely slow to open on 10.5

Categories

(Core :: Widget: Cocoa, defect, P2)

Product:
Core
Component:
Widget: Cocoa
Platform:
x86
macOS
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: asa, Assigned: jaas)

Details

Attachments

(1 file)

Hang report
154.59 KB, text/plain
Details 
Not sure if this is us or Mac, but on the latest nightly builds on 10.5, the help menu can take up to 10 seconds to open. This is a pretty awful experience
Flags: blocking-firefox3?
Help menu, or the actual help page? The Help menu itself seems to open immediately for me, though the "Minefield Help" page does require two clicks before it opens. Build 2008012804.
Help menu. 

I see some slowdown overall with the Help menu for all my applications since it now contains the spotlight item, but Firefox suffers particularly extremely on my system (10.5 on first gen MBP)
I dunno, it only takes about 1/2 a second to open for me which seems about par for the Help menus because of Spotlight. 2.4GHz MBP, but I don't think hardware would have much to do with it in this case (a 1st gen MBP isn't going to have any problems). It could be a difference between the build I'm on and 10.5 if you've got 10.5.0.
I'm on 10.5.1 on a 2 GHz Intel Core Duo with 2 GB RAM. 
It is really slow for me as well. I accidentally mouse over it and it lags my computer.
Asa, did you have a chance to find any more 10.5.x testing machines? If its really something that's regularly noticed on current builds, then I have a feeling this is more a OS thing like we talked about since I still get nothing. You made me notice another possible bug with the help page in trunk, though.
I don't see it my Mac Mini running Leopard, but I have seen it previously on other machines. A while back there was another bug filed about this issue.
Hey Patrick or Asa, I don't suppose either of you use the del.icio.us bookmark extension as bug 403761 notes? Could be a duplicate, and that would explain my inability to reproduce.
nope. I've got zero add-ons. 
Might be a good idea to just revisit this once more people get the next update since there's not really any way to tell if its really something fixed there without at least someone else to try. Your call though, Asa. If Marcia isn't getting it either it seems somewhat random. Is there any slowness with the help menu on other apps, it could just be related to Spotlight.
I've seen this too, though I assumed it was a problem with the fancy new Help menu styling on 10.5, and not something specific to Firefox.
Assignee: nobody → joshmoz
Component: OS Integration → Widget: Cocoa
Flags: blocking-firefox3?
Product: Firefox → Core
QA Contact: os.integration → cocoa
(In reply to comment #1)
> Help menu, or the actual help page? The Help menu itself seems to open
> immediately for me, though the "Minefield Help" page does require two clicks
> before it opens. Build 2008012804.
> 

Is there a bug on the issue with the help page requiring 2 clicks to open?
(In reply to comment #12)
> Is there a bug on the issue with the help page requiring 2 clicks to open?
> 

Yes, bug 407381.
On OS X 10.5.2 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008021504 Minefield/3.0b4pre ID:2008021504

I see this in my profile with add-ons (both ordinary launch and in safe-mode) but when I tried it in a fresh profile, Help Menu opened faster, although the problem of bug 407381 remained.

Default profile (with add-ons)
ordinary launch: slow Help menu, first click doesn't work
safe mode: same as above 

Fresh profile (add-on DOM Inspector only)
ordinary launch:no lag opening Help menu, but first click doesn't work

(In reply to comment #11)
> I've seen this too, though I assumed it was a problem with the fancy new Help
> menu styling on 10.5, and not something specific to Firefox.
> 

other applications like Safari and iTunes do not have this problem while Firefox takes about 5 seconds to open.

From "HIToolbox Release Notes for Mac OS X v10.5" (http://developer.apple.com/releasenotes/Carbon/%20HIToolbox.html):


"Menu Context Flags

The Spotlight Help feature in Leopard requires scanning the contents of an application's menus to build an index of the menu item text. This index is used when you type into the Help menu to find menu items that match your search string.

In order to support menu content that changes dynamically, the Spotlight Help feature has to re-index the menu content each time that the Help menu is opened. Before examining the content of a menu, Spotlight Help sends several Carbon events to allow the application to populate the menu with new menu content. This can be quite slow at times, especially if the menu content is expensive to determine.

To allow applications to optimize menu content updating, several new bit flags have been defined as part of the MenuContext bitfield. These flags are:

    * kMenuContextInspection: indicates that a Carbon event is being sent because someone is inspecting the menu content.
    * kMenuContentDontUpdate[Text|Icon|Key|Enabled]: indicates that the sender of the Carbon events does not need to inspect the specified menu content. This allows an event handler to optimize its content updating by not updating this content. For example, Spotlight Help doesn't need command keys, icons, or enable state, so it will set all of those flags. 

These flags are included in Carbon events such as kEventMenuOpening, kEventMenuPopulate, kEventMenuEnableItems, and kEventCommandUpdateStatus."
As users' bookmark more and more and leverage the power of places, I worry that this will hit us harder and harder. Adding wanted-1.9.0.x as I think it's the type of thing that (with tests!) we could take once we've branched.
Flags: wanted1.9.0.x+
Priority: -- → P2
I've been having this problem and the latest nightlies are getting worse and worse on the delay. The ones from the past 3 days now hang the application when clicking at the Help menu. Have to force quit it. I tried with a fresh profile and still have the same thing.

This is on my iBook G4:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008033104 Minefield/3.0pre ID:2008033104

But when I do the same thing on a Mac Pro, the delay is much longer then before but it does return and drop the menu. Maybe it's specific to PPC?
Attached file Hang report — 
The stack trace seems to indicate it's looping at:
5 -[SCTGRLIndex indexCarbonMenu:withParentMenu:resultGRLs:isRootMenu:systemHelpMenu:] + 832 (in Shortcut) [0x9274b89c]
Attachment #312846 - Attachment mime type: application/octet-stream → text/plain
So is this supposed to happen when I click the help button in minefield?  Cos it takes maybe half a second.  MacBook C2D 2.16ghz 2gb ram

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008033004 Minefield/3.0pre

I do have an iBook G4 downstairs on 10.5.2, I'll check it in a bit.
I couldn't post from it because it crashed, but I grabbed latestnightly trunk about 15 minutes ago and yes, clicking help sent it beachballing for 20 seconds before I had to force close it.  G4 1.33ghz 1.5gb ram on 10.5.2 all updates.

probably the 2008033104 nightly because that's what check updates says on this copy on the intel mac.
Tom & Stephen, you guys want bug 400291. This bug is about the Help menu being slow to open *but actually opening*. Your hangs, requiring a force quit, are the other bug.
(In reply to comment #21)
> Tom & Stephen, you guys want bug 400291. This bug is about the Help menu being
> slow to open *but actually opening*. Your hangs, requiring a force quit, are
> the other bug.
> 

Note that this is related. The long hang is due to Apple indexing the main menu, in particular the bookmarks menu, the first time you open the Help menu. The problem in bug 400291 was that this caused an *infinite* hang because the bookmarks menu contained self references, and therefore was essentially infinitely large. There are also bugs (e.g. bug 426499) where this indexing process leads to a crasher.

Basically, the indexing exposes *every* problem that can exist with the menu, bookmarks and places code.

This particular problem is really about the fact that generating the bookmarks (?) menu is very slow (at least when called by the indexing process, see my comment 151 in bug 400291). So the question that should be asked is: why is the process so inefficient, and how can this be fixed?

So is this really a Widget problem? I doubt it. 
Is there a switch in the Apple menu API that lets us opt out of the sexxy new help menu search and indexing features? We no longer include actual help documentation in the product so this service isn't actually very useful anyway.
(In reply to comment #23)
> Is there a switch in the Apple menu API that lets us opt out of the sexxy new
> help menu search and indexing features? 

No. I filed a bug report with Apple about this, no useful reply yet.

> We no longer include actual help
> documentation in the product so this service isn't actually very useful anyway.
> 

Note that this particular feature is not just about searching the help, but about searching the menu. So you can easily find a menu for a feature without the need to go through the whole menu. For example, it offers a way to search the bookmarks menu, which can be very useful. 
(In reply to comment #23)
> Is there a switch in the Apple menu API that lets us opt out of the sexxy new
> help menu search and indexing features? We no longer include actual help
> documentation in the product so this service isn't actually very useful anyway.
> 

The proper name (from Apple) for this is "Spotlight For Help", and as far as I can tell via extensive searching, no, it cannot be disabled.
Steven's "tryserver" build in comment 53 of bug thread 

https://bugzilla.mozilla.org/show_bug.cgi?id=426499

has reduced my first-click help menu hang time from 25 seconds to about 8-9 seconds.  Second clicks are speedy as expected.

Additionally, note that if I open a NEW WINDOW and click the Help Menu again it goes back to the 8-9 second time frame, but if I open just a NEW TAB in an existing menu it keeps the quick second-click behavior.
(In reply to comment #25)
> The proper name (from Apple) for this is "Spotlight For Help", and as far as I
> can tell via extensive searching, no, it cannot be disabled.
> 

It's actually disabled when you use a language pack in firefox (at least french and japanese language pack) and the help menu is again instantaneous.
(In reply to comment #27)
> (In reply to comment #25)
> > The proper name (from Apple) for this is "Spotlight For Help", and as far as I
> > can tell via extensive searching, no, it cannot be disabled.
> > 
> 
> It's actually disabled when you use a language pack in firefox (at least french
> and japanese language pack) and the help menu is again instantaneous.
> 

The reason for this is probably that Apple identifies the Help menu by name. So if you don't use the (localized) name Apple expects, it treats it just as any other menu.
(In reply to comment #26)
> Steven's "tryserver" build in comment 53 of bug thread 
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=426499
> 
> has reduced my first-click help menu hang time from 25 seconds to about 8-9
> seconds.  Second clicks are speedy as expected.
> 

Confirmed, I see similar results.

> Additionally, note that if I open a NEW WINDOW and click the Help Menu again it
> goes back to the 8-9 second time frame, but if I open just a NEW TAB in an
> existing menu it keeps the quick second-click behavior.
> 

That's just because the index is regenerated.

So the delay seems to be in the image lookup/generation? Aren't these icons cached? And did anyone check my hypothesis about too many regenerations of the menu?

could it be that apple has a hidden function that builds the index at startup of for example safari ?
I've posted a patch (and tryserver build) at bug 426499 comment #66
that should greatly reduce or eliminate delays opening the Help menu
(on OS X Leopard).  Please test the tryserver build and let us know
your results.

Steven: You Da Man!!

Instantaneous opening, even w/ a fairly fat batch o' bookmarks.

Well done!
(In reply to comment #31)
> Please test the tryserver build and let us know
> your results.

Near instantaneous menu display on first access (vs. 12 seconds), and even the subsequent displays seemed a little faster.


This should be fixed by the patch for bug 426499, which just landed on trunk.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Flags: wanted1.9.0.x+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: