Closed Bug 420033 Opened 17 years ago Closed 3 years ago

DOMMenuItemInactive isn't dispatched for menuitems in Mac native menus

Categories

(Core :: Widget: Cocoa, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1703930

People

(Reporter: dev, Unassigned)

References

Details

Attachments

(2 files)

When moving from one item to another in a native menu, or when closing the menu all together, after placing a handler for DOMMenuInactive, DOMMenuInactive isn't fired at all.
Not sure if there's a need for these events for native Mac menus, the OS should be doing the right thing with accessibility itself.
Bug 409748 implements the showing of a menu items URL in the status bar while hovering over it in places like sub-folders on the toolbar, etc. By using the DOMMenuItemActive/Inactive handlers inside the places-popup-base, it also implements the same functionality for the History, and Bookmarks menu bars in Mac (something that already exists in Windows). In order to clear the URL from the status bar when the mouse is no longer hovering over an item, we need a DOMMenuItemInactive event fired when: 1. no longer hovering any item (mouseout) 2. closing a menu.
Which events are you referring to here? DOMMenuInactive, or DOMMenuItemActive and DOMMenuItemInactive? Your original post referred to DOMMenuInactive (the first one) which you should not be using. If you mean DOMMenuItemActive and DOMMenuItemInactive, then perhaps we can implement something.
Ahh yes! You are 100% right. I meant DOMMenuItemActive & DOMMenuItemInactive. I'm so sorry for the confusion.
Summary: DOMMenuInactive isn't dispatched for menuitems in Mac native menus → DOMMenuItemInactive isn't dispatched for menuitems in Mac native menus
For a11y the native Mac menu widget should do the right thing.
Attached file Testcase v1 (deleted) —
Testcase to show the absent DOMMenuItemInactive events on Mac.
Right, privileges problem again. Just save the testcase to your disk, open the Error Console and enter "window.openDialog("file:///path/to/testcase");".
Attached patch Patch v0 (WIP) (deleted) — Splinter Review
POC patch. I would appreciate it if somebody could give some feedback if this is going into the right direction (style probably needs a lot of improvement).
Thanks for the patch, sorry I haven't gotten to it yet but I should be able to soon.
Attachment #308362 - Flags: review?(joshmoz)
Josh, I am not yet entirely happy with my patch. For one, it does not yet behave the same as non-native XUL menus. For example, we can't dispatch DOMMenuItem(In)Active events when a <menu/> is highlighted. Also, it dispatches events for <menuseparator/>s, which non-native menus don't. Furthermore, I think it would be nicer to push the actual firing of the events down to nsMenuItem, which then could also check if it is a separator (bascially, it means that we would move the responsibility of firing events to the actual item). But I would nevertheless like to hear about your ideas about this patch and my suggestions.
Comment on attachment 308362 [details] [diff] [review] Patch v0 (WIP) One of this first things I'm doing for Mozilla 2 is making a lot of changes to our menu code. Let's revisit this after that is done. We aren't going to get this for Gecko 1.9.
Attachment #308362 - Flags: review?(joshmoz)
Assignee: joshmoz → nobody
(In reply to comment #11) > Comment on attachment 308362 [details] [diff] [review] > Patch v0 (WIP) > > One of this first things I'm doing for Mozilla 2 is making a lot of changes to > our menu code. Let's revisit this after that is done. We aren't going to get > this for Gecko 1.9. I'm assuming this is still broken?

I fixed this in bug 1703930.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: