Skip to main content

Search and Top Navigation

#9101 closed feature (fixed)

Opened February 19, 2013 11:12AM UTC

Closed November 15, 2013 07:20AM UTC

Last modified November 15, 2013 07:22AM UTC

Dialog: Track last focused element instead of always focusing the first tabbable element

Reported by: KopiasCsaba Owned by:
Priority: minor Milestone: 1.11.0
Component: ui.dialog Version: 1.10.0
Keywords: Cc:
Blocked by: Blocking:
Description

Hello!

This problem for some reason is only comes up in Firefox.

Here is an example:

http://jsbin.com/irovuj/1/edit

Steps to reproduce:

  • Click on the second text input in the dialog
  • Ctrl+TAB (switch to the next tab, open one before if you don't have)
  • Ctrl+SHIFT+TAB (switch back to the previous tab)
  • The result: the first text input will be selected.

If you turn off the "modal" parameter, then this behaviour stops.

The problem is with the _focusTabbable call:

_createOverlay: function() { 
[...]
$(".ui-dialog:visible:last .ui-dialog-content").data("ui-dialog")._focusTabbable();
[...]
}

Without that the bug disappears. I don't know why thats there, it might have a reason, but please check this out.

Thank you!

Attachments (0)
Change History (15)

Changed February 19, 2013 11:30AM UTC by KopiasCsaba comment:1

Changed February 19, 2013 11:44AM UTC by KopiasCsaba comment:2

Tested in Firefox 18.0.2 linux version

Changed February 19, 2013 11:57AM UTC by tj.vantoll comment:3

status: newopen
summary: Dialog focuses to the first input element when changing tabs (in Firefox)Dialog: focus moved to first focusable element when changing tabs in modal (Firefox)

Confirmed on Firefox 18 on OS X. Reduced - http://jsbin.com/irovuj/4/edit. The issue does not occur in Chrome. Haven't gotten around to testing the other browsers yet.

Changed February 19, 2013 01:05PM UTC by scottgonzalez comment:4

summary: Dialog: focus moved to first focusable element when changing tabs in modal (Firefox)Dialog: Track last focused element instead of always focusing the first tabbable element
type: bugfeature

This happens because Firefox focuses the document when showing the page. We need to shift focus back to the dialog, so the only option is either put focus back on the first element or the element that had focus when the page was hidden. We can probably track which element had focus to make this better, but this is working as intended based on what Firefox is doing.


Proposed solution:

  • Create a property to store which element currently has focus.
  • Set this to null on create.
  • When determining which element to focus, first check if we have a stored element.
  • On close, reset the property to null

This should give us consistent behavior whenever the dialog loses focus (regardless of how that happens).

Changed May 15, 2013 08:53PM UTC by scottgonzalez comment:5

#9302 is a duplicate of this ticket.

Changed May 16, 2013 10:49AM UTC by incutonez2 comment:6

_comment0: Happens with anchor tags as well ([http://jsbin.com/icuguz/1/edit JS Bin]). Is there a quick fix for this? Like, can we unbind the focusing event somehow?1368701569245032

Happens with anchor tags as well (JS Bin), because I believe they're considered "tabbable." Is there a quick fix for this? Like, can we unbind the focusing event somehow?

Changed May 17, 2013 02:05AM UTC by tj.vantoll comment:7

Replying to [comment:6 incutonez2]:

Happens with anchor tags as well (JS Bin), because I believe they're considered "tabbable." Is there a quick fix for this? Like, can we unbind the focusing event somehow?

If you *must*, you can override _focusTabbable.

Just make sure if you go down this route you do move focus to something for a11y purposes. This example gives it to the close icon, which will avoid scrolling the dialog: http://jsbin.com/icuguz/2/edit.

Changed May 17, 2013 11:12AM UTC by incutonez2 comment:8

_comment0: Replying to [comment:7 tj.vantoll]: \ > If you *must*, you can override [https://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui.dialog.js#L233 _focusTabbable]. \ > \ > Just make sure if you go down this route you do move focus to something for a11y purposes. This example gives it to the close icon, which will avoid scrolling the dialog: http://jsbin.com/icuguz/2/edit. \ \ Interesting... that locks up FF 10, but works in FF 3.6. Wonder why that is. Either way, I'm going to use your fix. I was setting _focusTabbable to $.noop, but I guess that causes accessibility issues. Thanks for the help!1368886446217185

Replying to [comment:7 tj.vantoll]:

If you *must*, you can override _focusTabbable. Just make sure if you go down this route you do move focus to something for a11y purposes. This example gives it to the close icon, which will avoid scrolling the dialog: http://jsbin.com/icuguz/2/edit.

Interesting... I'm going to use your fix. I was setting _focusTabbable to $.noop, but I guess that causes accessibility issues. Thanks for the help!

Changed August 25, 2013 03:31AM UTC by tj.vantoll comment:9

#9513 is a duplicate of this ticket.

Changed September 30, 2013 09:24AM UTC by jzaefferer comment:10

Replying to [comment:4 scott.gonzalez]:

Proposed solution: * Create a property to store which element currently has focus. * Set this to null on create. * When determining which element to focus, first check if we have a stored element. * On close, reset the property to null This should give us consistent behavior whenever the dialog loses focus (regardless of how that happens).

Is this still correct? I can work on putting that together.

Changed September 30, 2013 11:55AM UTC by scottgonzalez comment:11

Replying to [comment:10 joern.zaefferer]:

Is this still correct? I can work on putting that together.

Yes.

Changed October 02, 2013 03:24PM UTC by jzaefferer comment:12

At which point do we set that property to something other then null? The obvious one is "at the end of _focusTabbable", but what we probably really need is to bind a focusin event and store the event.target to that property.

Changed October 02, 2013 03:28PM UTC by scottgonzalez comment:13

Yes, a focusin event handler which stores the target is what we need. We just set that up on create and we don't need to do anything special in _focusTabbable().

Changed November 15, 2013 07:20AM UTC by Jörn Zaefferer comment:14

resolution: → fixed
status: openclosed

Dialog: Restore focus to the previously focused element when window regains focus. Fixes #9101 - Dialog: Track last focused element instead of always focusing the first tabbable element

Changeset: 0e5a2e126ab4179f1ec83e1e4e773058b49e336d

Changed November 15, 2013 07:22AM UTC by jzaefferer comment:15

milestone: none1.11.0