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 comment:1
Changed February 19, 2013 11:44AM UTC by comment:2
Tested in Firefox 18.0.2 linux version
Changed February 19, 2013 11:57AM UTC by comment:3
status: | new → open |
---|---|
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 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: | bug → feature |
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 16, 2013 10:49AM UTC by 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 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 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 September 30, 2013 09:24AM UTC by comment:10
Replying to [comment:4 scott.gonzalez]:
Proposed solution: * Create a property to store which element currently has focus. * Set this tonull
on create. * When determining which element to focus, first check if we have a stored element. * On close, reset the property tonull
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 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 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 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 comment:14
resolution: | → fixed |
---|---|
status: | open → closed |
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 comment:15
milestone: | none → 1.11.0 |
---|
http://www.youtube.com/watch?v=KnnTDfzjeAU&