Opened 15 years ago

Closed 15 years ago

#3517 closed task (fixed)

dijit.util.popup: don't automatically save/restore focus

Reported by: bill Owned by: bill
Priority: high Milestone: 0.9beta
Component: Dijit Version: 0.9
Keywords: Cc:
Blocked By: Blocking:


dijit.util.popup() automatically saves/restores the focus. This is interfering with #3516, and is also strange for Combobox (where the focus never leaves the <input> in the first place).

  1. Remove that code from dijit.util.popup
  2. Modify DropdownButton? to restore focus to Button manually
  3. call dijit.util.focus manually when needed (like for Dialog)
  4. interface to tell when a popup has closed is strange. There should be an onClose callback to*() rather than calling onClose() on the popped-up widget

Change History (9)

comment:1 Changed 15 years ago by bill

Status: newassigned

comment:2 Changed 15 years ago by bill

(In [9296]) Remove code from dijit.util.popup() to automatically save/restore focus. This is now the responsibility of each widget, which can call dijit.util.focus(), or manually reset the focus when the dropdown closes, etc. (Other widgets still need to be updated to do this.)

Updated dijit.util.focus to send events when the focus changes; these should be used sparingly since they occur late on IE (up to 100ms).

Updated dijit.util.popup so that it automatically closes the popup when focus moves away from the popup or the widget that triggered it (DropDownButton? etc.) This makes the popup disappear when you tab away from a DateTextBox?. (This is in addition to old behavior of closing the popup when user clicks the mouse away from those two widgets.)

Refs #3517 (fixes first issue in that bug)

comment:3 Changed 15 years ago by bill

(In [9298]) - support onClose parameter to to detect when popup was closed by an explicit call to close() or by the user clicking on an empty area of the page

  • switch take named parameters instead of positional parameters
  • open by default closes other opened popups, submenu param controls this

Refs #3517

Also fixed missing call to superclass postMixInProperties (thanks Mark). Refs #3522

comment:4 Changed 15 years ago by bill

(In [9300]) Make menu restore focus and selection before executing selected menu choice, but don't restore focus if the menu is closed just because the user clicked somewhere random on the screen.

Refs #3517.

comment:5 Changed 15 years ago by bill

(In [9301]) If you hit the close button on a TooltipDialog? restore focus to the button/link that spawned the dialog in the first place. Refs #3517.

comment:6 Changed 15 years ago by bill

OK, I think everything is resolved but drop down and combo buttons, which are complicated. Need someway to detect when the menu has been closed *because* someone picked a menu item (rather than clicking on another area of the screen), and in that case only restore focus to the button / arrow.

comment:7 Changed 15 years ago by bill

Closing this bug; remaining issue filed in #3537.

comment:8 Changed 15 years ago by bill

(In [9330]) Move rest of onClose handling to callback from, so as not to even assume that Menu has an onClose method. Refs #3517.

comment:9 Changed 15 years ago by bill

Resolution: fixed
Status: assignedclosed
Note: See TracTickets for help on using tickets.