316268 - Submenus of XUL Menu (made with toolbarbuttons) don't work correctly when using in a frame or iframe because a mouseout event is fired when moving over with the mouse.

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[Holger Meyer]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/412.7 (KHTML, like Gecko) Safari/412.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051107 Firefox/1.5

When using XUL menu buttons with submenus, the submenus don't apear when the mouse is over the sub menu entry (menupopup). Also the highlighting of the menu entry is flickering. On the example (http://www.we06.de/xulMenuBug/) the first submenu works, but the others don't. I checked out that a mouseout event is fired when moving over the menu entry. The mouseover event should only be fired when moving out the entry.  When calling the XUL file directly (without frames) everything works ok. The example works very well on Firefox 1.0.x. but not in Firefox 1.5

Reproducible: Always

Steps to Reproduce:
1. open the URL http://www.we06.de/xulMenuBug/
2. open the menu "Datei"
3. move the mouse over "Löschen" or the other submenus under it

Actual Results:  
The submenu does not appear and the highlighting of the menuentry is flickering

Expected Results:  
The submenu should appear like in Firefox 1.0.x and the menuentry should not flicker

the not working example is also attached

Comment 1

[Holger Meyer]

Attachment: this is the html and XUL code which does not work

It is the same example like on http://www.we06.de/xulMenuBug/

Comment 2

[Holger Meyer]

Hello XUL Team,

can you please look for this bug and fix it if possible? It is very important for us, because we use a XUL - Menu for our CMS webEdition, which is the most sold in germany (over 15000 Licences) If the bug will not be fixed in Firefox 1.5 final we will have a lot of trouble from our customers, who mostly uses Firefox (we recomend Firefox as the best browser for our CMS).

Thanks in advance,

Holger Meyer


-------------------------------------------------------------------------------------

Holger Meyer
Director Software Development

webEdition Software GmbH  Karlsburgstr. 2  76227 Karlsruhe  Germany
Phone: +49 (0)721 - 20 188 - 0
Fax: +49 (0)721 - 20 188 - 99
[e-mail]  http://www.webedition.de

Comment 3

[Jan Klier]

Attachment: Patch #1

Patch that I belive fixes the problem - based on Seamonkey source.

The EventStateManager in Seamonkey generates what I believe is an extraneous MouseOut notification, which results in the delay timer that was just created in nsMenuBar to be killed causing the funny popup menu behavior.

The patch skips over the NotifyMouseOver if there's no mLastMouseOverElement and sets it appropriately.

This is my first bug-fix in Firefox, so I'm still learning the process here :-)

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 204254 [details] [diff] [review]
Patch #1

re-requesting review (to roc instead of jst) on behalf of jklier, although I'm a bit skeptical of the patch at first glance.

Comment 5

[Jan Klier]

A bit more background this patch (is this the right place to put that info?):

After receiving the NS_MOUSE_MOVE event the nsMenuFrame sets up a delay timer. When that timer fires, the popup menu opens. If a NS_MOUSE_EXIT_SYNTH event is received prior to the firing, the sequence is cancelled.

That works ok in 1.0.7. In Seamonkey, the code goes into ::NotifyMouseOver in the nsEventStateManager. Not finding a matching mLastMouseOverElement it starts a sequence which ends up switching to ::NotifyMouseOut, which eventually generates the NS_MOUSE_EXIT_SYNTH event, which cancels the timer in nsMenuFrame.

Since this all happens on the very first NS_MOUSE_MOVE after the element became active, and not an NS_MOUSE_EXIT, it seems off to go through ::NotifyMouseOut when the mouse is still over the element.

The patch changes ::NotifyMouseOver to do nothing (similiar to a NS_MOUSE_MOVE within the element) if this is the first hit, and set the mLastMouseOverElemnt up for subsequence calls, except if there is a change in element. With that change the test case works fine, and is now identical in behavior to FF 1.0.7.

Comment 6

[Holger Meyer]

Firefox 1.5 is out, but the bug is not fixed. :-(

So we need to find out a workarround. If someone has an idea how to get this problem solved somehow please let me know.

I tried to make it with a java applet which works very well under windows, but on Mac OSX the new Java Embedding Plugin Included in Mac Mozilla Firefox has also a bug. If the menu is shown, you can't hide it when clicking next to it...

Comment 7

[Martijn Wargers (dead)]

This reminds me of bug 306426, maybe the patch in that bug also fixes this bug.

Comment 8

[David Maciejewski]

The same bug results, if you build a XHTML-Menue with links an you set a background via background-position and so on on links with a:hover. If you dont set the background-image in a:link, the button flickers.

Comment 9

[Boris Zbarsky [:bzbarsky]]

That has nothing to do with this bug.  If there is an HTML bug of some sort, please file it separately.  cc me, and please attach a testcase to the bug using the attachment link after you have filed it.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

The patch doesn't look right to me. I think we should fire a mouseover the first time.

(In reply to comment #7)
> This reminds me of bug 306426, maybe the patch in that bug also fixes this bug.

I agree ... can someone try this?

Comment 11

[Martijn Wargers (dead)]

This is fixed now with 2005-12-15 trunk build. Most likely fixed by bug 306426.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 204254 [details] [diff] [review]
Patch #1

minusing because I don't like the change and it appears to have been fixed properly in bug 306426.

Comment 13

[Holger Meyer]

Firefox 1.5.0.1 came out. But the BUG is not fixed in that release! When can we expect a version with the bugfix????

Comment 14

[Martijn Wargers (dead)]

Holger, see bug 306426, hopefully the bug will be fixed in Firefox 2.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Clearing flags because this appears to be fixed.  If it is not actually fixed please reopen and renominate.