Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#10339 closed defect (fixed)

Menu: dijitMenuItemHover & dijitMenuItemSelected not removed

Reported by: bill Owned by: bill
Priority: high Milestone: 1.4
Component: Dijit Version: 1.4.0b
Keywords: Cc: becky
Blocked by: Blocking:

Description

(From Joscha Falc Feth, IBM)

When using a popupMenu within a dijit.Menu nad using onClick to for example open a dialog, the

  • dijitMenuItemHover does not get removed on IE > 6
  • dijitMenuItemHover and dijitMenuItemSelected does not get removed on FF3

I attached an example file with a workaround. Please disable the workarounds to check the issue on FF3 and IE7 & 8.

Attachments (2)

exampleMenu.html (3.1 KB) - added by bill 4 years ago.
exampleMenu14.html (2.8 KB) - added by bill 4 years ago.
working example (without workarounds) against 1.4

Download all attachments as: .zip

Change History (8)

Changed 4 years ago by bill

comment:1 Changed 4 years ago by joscha

Please note: The Fix for FF3 already got disabled in the example attachment. To test it, it needs to be *enabled*.

comment:2 Changed 4 years ago by bill

  • Milestone changed from tbd to 1.5

comment:3 Changed 4 years ago by bill

(In [20927]) Move focus to parent menu *before* closing child menu, fixes #10437 !strict.

Also fixed a problem with lingering highlighted items (dijitMenuItemSelected) in closed menus, refs #10339.

comment:4 Changed 4 years ago by bill

(In [20951]) Test case for left arrow closing menus (refs #10437) plus that dijitMenuItemSelected is correctly removed in that case (refs #10339).

comment:5 Changed 4 years ago by bill

  • Cc becky added
  • Milestone changed from 1.5 to 1.4
  • Resolution set to fixed
  • Status changed from new to closed

Actually [20951] also fixed the dijitMenuItemHover problem on IE, so IE is working perfectly for 1.4.

dijitMenuItemSelected is still lingering on FF. Actually, the class disappears when the dialog is shown but *reappears* when the Dialog is closed, because the Dialog is trying to refocus the MenuItem that spawned it. That's not good, since the Menu itself is hidden.

Would be nice if Dialog could automatically detect if one of the ancestors of the refocus node was hidden... apparently you can check the node's offsetWidth and offsetHeight, and if they are 0 it means that the node is hidden. But that apparently doesn't work for tr/td in some cases (which is what Menu uses), so it doesn't sound like a workable solution. And also, for a11y reasons there should be code somewhere to reset focus somewhere sensible after dialogs launched from context menus are closed.

Anyway, by using 1.4 and then setting refocus: false on your dialogs, this works on all browsers. Attaching new test case showing it working, and closing this ticket.

Changed 4 years ago by bill

working example (without workarounds) against 1.4

comment:6 Changed 4 years ago by bill

PS: there's a TODO in MenuItem.js to fix the focus manager to track focus/blur events on MenuItems, and then cleanup the MenuItem code to take advantage of that. When that TODO is fixed there probably won't be a lingering dijitMenuItemSelected class, even if Dialog does try to refocus the hidden context menu.

Regardless, Dialog trying to focus a hidden context menu is worrisome. We've had lots of problems on IE with hiding the node that has focus, although maybe there's no issue with trying to focus a node that's already hidden.

Note: See TracTickets for help on using tickets.