407381 - [10.5] help menu items do not work the first time you select one (two clicks/key presses needed to "Check for Updates")

Status: RESOLVED FIXED

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

Description

[Marcia Knous [:marcia]]

Seen using the last few nightlies, including Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9b2pre) Gecko/2007120704 Minefield/3.0b2pre. I have seen this on more than one machine.

STR:
1. Update my nightly build by accessing the file menu, Help | Check for Updates
2. Nothing happens after first key press. I have to press the key again to see the dialog launch.

I have not seen this when running Tiger.

Comment 2

[Marcia Knous [:marcia]]

As Josh points out in the bug he filed, "Same goes for everything in the help menu, though once you select *any* of them then they all work."

Comment 3

[Bryan Henry]

I noticed this behavior when looking at bug 414699 earlier, but it was in current trunk rather than nightlies back from early December. I don't get it in 3.0b2.

Comment 4

[Bryan Henry]

Just a quick update...this is still present in trunk. Is there any idea of where the approximate range for this appearing is or does it need to be tracked down still?

Comment 5

[Bryan Henry]

Some observations:
- Tested with Gecko/2007120704 Minefield/3.0b2pre as noted in the original report as well as with Gecko/2008021304 Minefield/3.0b4pre - the following behavior is identical between the two builds which means the regression hit sometime before that b2pre build mentioned above.
- If you open the Help menu exactly one time and then click any of the menu items there, they will not open as described in the initial report.
- However, if you open the Help menu more than once the behavior disappears. The behavior also disappears if you perform an action like closing a tab before attempting to duplicate the bug.

In other words, it looks like this only happens when you open up Firefox, go straight to the Help menu, open it only once, and then try to click a menu item. That's an awfully specific case, no?

I'll try finding the regression range later today...if it seems like I forget, someone ping me so I remember.

Comment 8

[Chris Beard]

This bug is still present in the latest builds. This is a reasonably serious bug as from a user perspective it appears that software update is broken.

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

Comment 9

[Bryan Henry]

I think the seriousness of this bug has been a little overemphasized, although it is definitely something to fix. Not only is it only reproducible in a very specific situation (detailed above), but users are much more likely to simply try clicking a second time than to go crazy when a menu item doesn't work the first time around.

In any case, following is the regression range for this. All the way back into 2006, which is another reason I think this isn't serious (no one even noticed this for over a year?).

Last build before behavior appears: Build 2006092808
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006/09/2006-09-28-08-trunk/firefox-3.0a1.en-US.mac.dmg

First build where behavior appears: Build 2006092906
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2006/09/2006-09-29-06-trunk/firefox-3.0a1.en-US.mac.dmg

This seems to be somehow linked to the double File menu in the menubar bug that first appeared in the same build. It was addressed in bug 385966. I have no idea how its linked, though a look at what was landed on trunk for that build might lend some clues.

Comment 10

[Josh Aas]

This is a pretty strange bug. We set up the menu item and add a target/action to it before the menu is even opened, but the first time you select it the action doesn't get called - we simply get no notification that the user selected the item. The second time things work fine. Strange.

Comment 11

[Bryan Henry]

I really don't see anything that jumps out to me in the Bonsai query for those dates, though the behavior definitely appears in that timeframe.

Someone else want to take a look? Bonsai and I don't play well.

Maybe bug 333023? That's the only thing I see dealing with menus around that time period...

Comment 12

[Phil Ringnalda (:philor)]

Bryan: that's when Widget: Cocoa was turned on for Firefox - you won't find a specific bug, your range is just "it's always been this way."

Comment 13

[Bryan Henry]

Ah....excuse the noise then.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

I'm already working on another bug (bug 413681) that involves Cocoa
widgets menu wierdness, so I'll add this to my plate (since I might be
able to resolve it at the same time).

Comment 15

[Josh Aas]

While I agree that this is a serious bug, I'm giving blocking1.9- because I just don't see this holding up the release at the last minute - the workaround is very simple. I looked into this for a while and it looks like a nasty Apple bug where we just don't get informed of the user's selection the first time it is made. We should try to fix this in a dot release though.

Comment 16

[Chris Beard]

i still think that this is a blocker. it really sucks from a user experience perspective to have any of our default menus be non-functional on first run, doubly so that it affects perception that a core feature (i.e. software update) is broken. (cc'ing beltzner for his read)

Comment 18

[[e-mail]]

My observation to this problem is a bit different. In addition to the first choice of menu item doesn't work, the menu itself takes some time to drop down, too. The delay seems to be worsened recently. Clicking at the Help menu now hangs the application with 100% CPU usage.

Is this a different bug?

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

Comment 19

[Josh Aas]

It is a different bug, bug 414699.

Comment 20

[Samuel Sidler (old account; do not CC)]

(In reply to comment #19)
> It is a different bug, bug 414699.

Actually, it's bug 400291.

Comment 21

[Dave Miller [:justdave]]

11:20:38 < josh> can you reproduce 407381 with the latest nightly on 10.5? I think I might have fixed it in a recent patch that removed carbon from our menu event handling, I can't repro any more.

WFM currently:

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

There's still an excruciating delay before the Help menu opens the first time you click on it (5 to 10 seconds), but it no longer takes 2 clicks to open it.

Comment 22

[Dave Miller [:justdave]]

er, doesn't take 2 clicks to open items in it either.  I remember running into that all the time before.

now on:

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

Comment 23

[Carsten Book [:Tomcat]]

also works for me with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008040604 Minefield/3.0pre ID:2008040604

Comment 24

[Josh Aas]

Yeah, backing out my patch "no carbon command handling v1.0" on bug 398514 causes this bug to reappear for me so that did fix this.

We were installing a Carbon event handler on the Carbon menus that are behind the scenes in the Cocoa API. The Cocoa API probably wasn't expecting that and behaved strangely in response. I can't wait to kill off the rest of our Carbon event usage but unfortunately there are some things that we need to do that the Cocoa API can't do on 10.4.