Opened 14 years ago

Closed 10 years ago

#3768 closed bug (fixed)

Dialog: contain focus within dialog

Reported by: Scott González 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.

Change History (23)

comment:1 Changed 13 years ago by Scott González

Milestone: 1.next1.9

Related tickets: #4025 #5763 #5764 #6101

comment:2 Changed 12 years ago by Scott González

#6647 is a duplicate of this ticket.

comment:3 Changed 12 years ago by tibi7000

This should also work for dialogs containing iframes.

comment:4 Changed 12 years ago by fofanafi

Status: newopen

comment:5 Changed 12 years ago by fofanafi

Focus still goes out of dialog with jQuery UI 1.8.11:

http://jsbin.com/adika3/3

comment:6 Changed 12 years ago by Scott González

#3350 is a duplicate of this ticket.

comment:7 Changed 12 years ago by techtangents

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?

comment:8 Changed 12 years ago by techtangents

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.

comment:9 Changed 12 years ago by Scott González

You would move between widgets that contain focus via F6. See http://dev.aol.com/dhtml_style_guide#dialognonmodal

comment:10 Changed 12 years ago by 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.

comment:11 in reply to:  10 Changed 12 years ago by Scott González

Replying to 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.

Last edited 12 years ago by Scott González (previous) (diff)

comment:12 Changed 12 years ago by CloudStrife

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.

comment:13 Changed 12 years ago by julienw

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.

comment:14 Changed 12 years ago by Scott González

Keywords: redesign added

comment:15 Changed 11 years ago by julienw

Bug #3123 was fixed in August 2011, this makes at least the behaviour consistent accross browsers.

comment:16 Changed 11 years ago by lukepage

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

  1. 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.

comment:17 Changed 10 years ago by Scott González

Milestone: 1.9.01.10.0

comment:18 Changed 10 years ago by southerd

Owner: set to southerd
Status: openassigned

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.

comment:19 Changed 10 years ago by southerd

The :tabbable bug is an instance of http://bugs.jqueryui.com/ticket/8643 and will be fixed on that.

comment:21 Changed 10 years ago by southerd

Resolution: fixed
Status: assignedclosed

comment:22 Changed 10 years ago by Scott González

Resolution: fixed
Status: closedreopened

Tickets need to stay open until merged into master.

comment:23 Changed 10 years ago by David Souther

Resolution: fixed
Status: reopenedclosed

Dialog: Prevent tabbing off any dialog. Fixes #3768 - Dialog: contain focus within dialog.

Changeset: 3a09a4a0de1f485a63091ffe8188b080a561b592

Note: See TracTickets for help on using tickets.