Why does gConstructingMenu start with a g and not with an m

NEW
Unassigned

Status

()

7 years ago
7 years ago

People

(Reporter: mano, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Created attachment 603319 [details] [diff] [review]
naive patch, v0

If a change happens in the bookmarks menu while I open the File menu, cocoa menus says it's not important. Here's a naive patch just for this problem. If there's actually a reason for using a global, meaning further work is necessary, the time better be spent on bug 733415, which would, in theory, remove the SetRebuild way of live-updating.
Attachment #603319 - Attachment is patch: true
Attachment #603319 - Flags: review?(smichaud)
Comment on attachment 603319 [details] [diff] [review]
naive patch, v0

This looks fine to me in principle.

The existence of a gConstructingMenu global dates back to the very first Cocoa widgets commit.  But I, too, don't understand why it wasn't just a member variable of nsMenuX.

Have you tested these changes?  I'm a little concerned that the changes to the observer methods might cause performance problems, especially if the cross-platform live menu update isn't very efficient (for example large numbers of intermediate changes, or changes back and forth).  But then I suppose the best way to fix these problems would be to fix the live menu update code.

I'd also want to be sure that changes to an open menu do in fact get reflected in it, without UI glitches.
Attachment #603319 - Flags: review?(smichaud) → review+
You need to log in before you can comment on or make changes to this bug.