Menu bar becomes unresponsive when hovering Toolbar menus [M641597]

[GoogleCodeExporter]

* This is a startup crash or failure to start (Y/N): N

* This is a fault of JavaScript acceleration (Y/N): (Use the steps above to
find out. Do NOT report if it is not.) N

* What steps are necessary to reproduce the bug? These must be reasonably 
reliable.

If you have the Bookmarks Toolbar and/or the Web Developer Toolbar (anything 
with submenus/folders), you can hover these left and right when they are open. 
See the video below, I don't know a better way to describe this. If you do this 
for a while (about 10 times right and left), the TFF Menu bar (including the 
Apple menu) stops working until you restart TFF. Other applications are not 
affected. When I rightclick the nonworking Menu bar, I get a contextual menu 
that I should get when rightclicking a toolbar in the browser window. I made a 
reduced testcase bookmarks file with only empty folders.

* Describe your processor, computer, operating system and any special
things about your environment.

PowerBook G4 1.33 GHz (7450), 10.5.8

* Include any useful additional information, steps you have tried, etc.:

attached testcase bookmarks file.
video (how to trigger the bug): http://www.youtube.com/watch?v=l7H1Conr42U

Additional information:
Machine: PowerBook G4 1.33 GHz (7450), 10.5.8
Created new OS X user account for testing; there are no haxies installed on 
this machine
The content of the folders in the toolbar doesn't matter, they can even be empty
It doesn't matter if nanojit for chrome is enabled or not.
It also happens in TFF 4.0.2., but not in Seamonkey 2.0.x
It doesn't seem to happen on G3 with 10.4.11 (at least I was unable to trigger 
it)
It does happen reliably on G4 with 10.5 (but I don't know if it's the processor 
type or the OS)
I don't know if this is a TFF, Mozilla, or OS X bug 

Original issue reported on code.google.com by chtru...@web.de on 21 Jun 2011 at 12:57

Attachments:

• bookmarks.html

[classilla]

Reopened as "regressed" in FPR1 (most likely it had just been wallpapered).

Current speculative fix idea is to just close the drop down popup when moving the mouse off. @chris-chtrusch , what do you think of that? Would that be annoying?

[chris-chtrusch]

I'm not sure. We might get more complaints about unexpected UI behavior than we would have about the actual bug. Maybe first give it a shot in the next beta and see if it fixes the bug at all?

Is there a way to get hold of a debug build to see what's happening in the browser when the bug is triggered? Anything to look for in the console or browser toolbox (the one that can debug the browser's own JS with remote access)?

[chris-chtrusch]

Log from debug build with comments.
issue72 console.pdf

[classilla]

It looks like that whole code segment is being triggered as a fall through with the popup open, so I'll probably need to put more debugging lines in there to figure it out. However, it does not seem to be caught by the solution for issue #248 and it should be unless it's not a mousedown that is being misdelivered.

[chris-chtrusch]

Log from debug build for FPR2 (release version) with comments.
issue72 console with TenFourFoxDebug-FPR2.pdf

[classilla]

Event type 5 is NSMouseMoved. I guess that makes sense.

[classilla]

One idea I have is to move the check for menubar clicks being misdelivered to the top of the event routine. Then it doesn't matter if the target is shot or not. Do other clicks in the window still work when this happens?

[chris-chtrusch]

Yes, inside the application window everything works as it should when the bug has been triggered.