Search and Top Navigation
#3768 closed bug (fixed)
Opened January 05, 2009 08:18PM UTC
Closed October 24, 2012 09:05PM UTC
Dialog: contain focus within dialog
Reported by: | scottgonzalez | Owned by: | southerd |
---|---|---|---|
Priority: | major | Milestone: | 1.10.0 |
Component: | ui.dialog | Version: | 1.6rc4 |
Keywords: | redesign | Cc: | |
Blocked by: | Blocking: |
Description
When tabbing through dialogs, focus should stay within the dialog, even for non-modal dialogs.
See jquery-ui-dev thread.
Attachments (0)
Change History (23)
Changed October 01, 2010 07:14PM UTC by comment:1
milestone: | 1.next → 1.9 |
---|
Changed December 06, 2010 04:00PM UTC by comment:3
This should also work for dialogs containing iframes.
Changed March 29, 2011 05:26PM UTC by comment:4
status: | new → open |
---|
Changed March 29, 2011 05:51PM UTC by comment:5
Focus still goes out of dialog with jQuery UI 1.8.11:
Changed May 22, 2011 11:57AM UTC by comment:7
When tabbing through dialogs, focus should stay within the dialog, even for non-modal dialogs.
Even for non-modal dialogs? Really?
If so, how does a keyboard-only user navigate focus from a non-modal dialog to other controls on the page?
Changed May 23, 2011 11:09AM UTC by comment:8
So, http://jsbin.com/opapu3/3 shows that tabbing stays within a modal dialog (jquery-ui 1.8.9).
I say we close this ticket.
Changed May 23, 2011 12:04PM UTC by comment:9
You would move between widgets that contain focus via F6. See http://dev.aol.com/dhtml_style_guide#dialognonmodal
Changed July 13, 2011 12:50AM UTC by comment:10
This is not fixed — it's relying on Firefox's non-standard behaviour of generating a keypress event for the <tab> between elements. Instead the event should be attached to keydown.
Changed July 13, 2011 12:52AM UTC by comment:11
_comment0: | Replying to [comment:10 conradirwin]: \ > This is not fixed — it's relying on Firefox's non-standard behaviour of generating a keypress event for the <tab> between elements. Instead the event should be attached to keydown. \ I'm not sure what you're comment is about; nobody ever said this was fixed. → 1310518358371739 |
---|
Replying to [comment:10 conradirwin]:
This is not fixed — it's relying on Firefox's non-standard behaviour of generating a keypress event for the <tab> between elements. Instead the event should be attached to keydown.
I'm not sure what your comment is about; nobody ever said this was fixed.
Changed July 13, 2011 09:34PM UTC by comment:12
I don't really care much about the way it is described in this particular ticket, but I do care about the details described in #6647, which I think is a much more complete description. I hope that this ticket is not closed until the issue described there is fixed.
Changed July 18, 2011 01:41PM UTC by comment:13
Hi,
I recently wrote this jQuery plugin exactly to resolve this problem : https://github.com/julienw/jquery-trap-input
I thought that it could be either integrated into jQuery UI or externally used if found (like with bgiframe).
I think the main problems are resolved now. I made an example page with a jQuery UI Dialog to be able to compare between the current behaviour and the behaviour I wanted : http://julienw.github.com/jquery-trap-input/examples/dialog.html
As I see it, the only left problem is with images and usemap; I don't know a way to focus a map with Javascript. And it's the keyboard focus is very broken in some browsers too (ie, Chrome), especially when two images share the same map (ie: Firefox).
Comments welcome.
Changed September 07, 2011 12:38PM UTC by comment:14
keywords: | → redesign |
---|
Changed December 29, 2011 12:29PM UTC by comment:15
Bug #3123 was fixed in August 2011, this makes at least the behaviour consistent accross browsers.
Changed May 02, 2012 02:52PM UTC by comment:16
There are 2 problems I have found in the current implementation.
1. Blurring tab focus (by clicking in empty space) resets the tab index to the document and pressing tab again means you are now focussed behind the modal dialog.
I solved this myself by adding a focus event to the first tabbable thing in the page
2. the :tabbable pseudo selector still looks at all parents that are hidden. But this includes elements that take up no space, so if you have a parent element that takes no space it is possible to have something tabbable that is not being picked up by the tabbable class. In my case our designer had an inline div containing a floated block element - though I'm sure its possible to create with floats without it being invalid.
Changed October 11, 2012 02:47PM UTC by comment:17
milestone: | 1.9.0 → 1.10.0 |
---|
Changed October 15, 2012 06:37PM UTC by comment:18
owner: | → southerd |
---|---|
status: | open → assigned |
For non-modal dialogs, focusing outside the dialog is normal behavior, and tabbing should proceed normally. Once focus has gotten back inside the dialog, tabbing should continue only within the dialog. So, 1) is correct behavior for non-modal.
For modal dialogs, focusing outside the dialog followed by tabbing should get the focus back into the dialog; it currently does not.
Changed October 15, 2012 07:27PM UTC by comment:19
The :tabbable bug is an instance of http://bugs.jqueryui.com/ticket/8643 and will be fixed on that.
Changed October 15, 2012 07:42PM UTC by comment:20
Changed October 15, 2012 08:43PM UTC by comment:21
resolution: | → fixed |
---|---|
status: | assigned → closed |
Changed October 15, 2012 09:30PM UTC by comment:22
resolution: | fixed |
---|---|
status: | closed → reopened |
Tickets need to stay open until merged into master.
Changed October 24, 2012 09:05PM UTC by comment:23
resolution: | → fixed |
---|---|
status: | reopened → closed |
Dialog: Prevent tabbing off any dialog. Fixes #3768 - Dialog: contain focus within dialog.
Changeset: 3a09a4a0de1f485a63091ffe8188b080a561b592
Related tickets:
#4025
#5763
#5764
#6101