Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#17348 closed defect (wontfix)

dijit.MenuBar reverts selected look and feel after window/tab regains focus

Reported by: Justin Birch Owned by:
Priority: undecided Milestone: tbd
Component: Dijit Version: 1.9.1
Keywords: Cc: Kitson Kelly
Blocked By: Blocking:


In your 1.8 and 1.9 online demos (and consequently in my app) the MenuBarItems? become selected/focused again after the user selects a sub item, goes to a different tab/window/app and then returns to the tab/window containing the MenuBar?.

In your 1.9 demo for MenuBar? either programmatic or declarative and using a mouse or keyboard shortcuts:

  1. Run the demo
  2. Open a menu bar item such as File or Edit
  3. Select a sub menu
    1. popup menu closes, MenuBarItem? appears unselected and unfocused as expected
  4. Select another tab in browser (Chrome28 and IE8 tested)
  5. Return to the demo tab
    1. last popup menu appears selected/focused (dijitMenuBarSelected/dijitMenuBarFocused)

I would expect the appearance to be unselected as I have not re-clicked the menu bar items or used any keyboard shortcuts.

In my own app which uses the menu bar sub items to open other tabs; when I return to the tab I launched from, any MenuBarItems? from which I have selected sub items will appear selected until I reuse the menu bar and hover or select the offending items.

I have attached no files as your demo adequately confirms the issue.

Change History (14)

comment:1 Changed 9 years ago by Justin Birch

PopupMenuItem? appears to have the same issue:

  1. Open context menu
  2. Select item (navigates to other page)
  3. Return to original page and re-open context menu
    1. popup menu first item and item used to navigate are showing selected CSS

comment:2 Changed 9 years ago by bill

Resolution: wontfix
Status: newclosed

I see, so it reproduces on test_Menu.html, and the issue is that when you return back to that test_Menu.html tab the "File" MenuBarItem? shows as selected/focus.

Well, it turns out that it is focused, and by design. Apparently what's happening is that:

  1. user clicks "New" MenuItem?
  2. focus is moved to the "File" MenuBarItem?
  3. user switches to another browser tab, then back to this tab
  4. the "File" MenuBarItem? gets the focus event again, and marks itself as selected

I think generally this isn't an issue. The idea is that when the user clicks the "New" item in the "File" menu, it triggers a application callback (aka the onClick handler) which shifts focus somewhere (for example to an Editor for a new message). However, in the case of test_Menu.html and presumably your app too, focus isn't being shifted anywhere, so it ends up back on the "File" MenuBarItem?.

It actually seems like the "File" MenuBarItem? should be shown as selected after step 2, but I think we added code to Menu to not do that.

Why does focus by default go to the "File" MenuBarItem?? Because it needs to go somewhere. Otherwise it really pulls out the rug from people that need to use the keyboard because they can't use the mouse.

So, it seems like the current behavior is more-or-less correct. I think you just need to shift focus somewhere in your onClick handler. That will make your app better anyway because it will make it accessible.

comment:3 Changed 9 years ago by Justin Birch

OK I can accept the argument that leaving the menu bar item selected in the original screen makes sense from an accessibility perspective.

Unfortunately there is still an issue:

  1. Open menu bar item A
  2. Select menu item a
    1. opens another tab/window
  3. Go back to original tab/window
  4. Open menu bar item B
  5. Select menu item b
    1. opens yet another tab/window
  6. Go back to original tab/window
    1. see that both menu bar items used to navigate are showing selected

I expect the last menu bar item used has focus, but two are visually showing focus/selection which is confusing. Didn't notice that was happening when I posted the ticket, sorry.

comment:4 Changed 9 years ago by bill

Hmm, OK, well if you attach a test case for that I can take a look. I tried to reproduce it with test_Menu.html but was unsuccessful.

comment:5 Changed 9 years ago by Justin Birch

I reproduced it on the demo by holding ctrl while selecting the menu items (step 2 and 5 above)

This consistently simulates the issue in the dijit Menu and MenuBar? demo environment. Hope that helps.

comment:6 Changed 9 years ago by bill

I tried holding down the control key while selecting options in the drop down menus in test_Menu.html. As I suspected, it didn't do anything special (compared to not holding down the control key). Perhaps it's different depending on the browser/OS, although I doubt it. I tried on Chrome/mac.

comment:7 Changed 9 years ago by Justin Birch

Yeah, couldn't reproduce it on Chrome, just IE8 on windows 7...working for banking clients that's all we support :(

comment:8 Changed 9 years ago by bill

OK, well I don't have that environment but I tried it on IE8/WinXP and IE10 in IE8 mode on Win7, and as expected the control key doesn't do anything. I can't imagine how it would do anything.

comment:9 Changed 9 years ago by Justin Birch

OK, was able to reproduce it on MenuBar? demo in both chrome and IE8 without ctrl key

Open two tabs in the browser, one the menu bar demo, one empty

  1. Open menu bar item File and select an item
    1. Go to other tab and back again
  2. Open menu bar item Edit and select an item
    1. Go to other tab and back again

Both items are highlighted in IE8 & Chrome 28

n.b. same in FireFox? 15 (never use FF usually)

comment:10 Changed 9 years ago by bill

I already tried that. It doesn't happen for me. Does it really reproduces for you on

comment:11 Changed 9 years ago by Justin Birch

My original tests are from the reference guide for 1.8 and 1.9 - issue is not reproducible in Chrome 28 but it is in IE 8 - issue is reproducible under Chrome 28 and IE 8 - issue is not reproducible in Chrome 28 or IE 8 - issue is reproducible in Chrome 28 and IE 8

FYI I'm using 1.8 in production because we started under 1.6 and haven't got the resources to rewrite all our dojo usage as AMD at the moment.

comment:12 Changed 9 years ago by bill

Cc: Kitson Kelly added

OK, sounds like the menu problem was fixed in 1.9, but you are hitting the problem explained in #17346 where the reference guide is still using dojo 1.8 for IE.

comment:13 Changed 9 years ago by Justin Birch

ok, any plans to fix the issue in 1.8?

If not is there a workaround?

Last edited 9 years ago by Justin Birch (previous) (diff)

comment:14 Changed 9 years ago by bill

No plans to backport the fix. Looks like it was fixed inadvertently from the cdc0bf035182851a0437bd8cda71805477a2edbb refactor.

As for a workaround, I guess you could try something like clearing that focusedChild info from a Menu when it gets blurred, or if MenuItem? B is focused/selected then clear any other focused/selected items. But you are on your own with that.

Note: See TracTickets for help on using tickets.