Ticket #3768 (closed bug: fixed)

Opened 6 years ago

Last modified 2 years ago

Dialog: contain focus within dialog

Reported by: scott.gonzalez Owned by: southerd
Priority: major Milestone: 1.10.0
Component: ui.dialog Version: 1.6rc4
Keywords: redesign Cc:
Blocking: Blocked by:

Description

When tabbing through dialogs, focus should stay within the dialog, even for non-modal dialogs.

See  jquery-ui-dev thread.

Change History

comment:1 Changed 4 years ago by scott.gonzalez

  • Milestone changed from 1.next to 1.9

Related tickets: #4025 #5763 #5764 #6101

comment:2 Changed 4 years ago by scott.gonzalez

#6647 is a duplicate of this ticket.

comment:3 Changed 4 years ago by tibi7000

This should also work for dialogs containing iframes.

comment:4 Changed 3 years ago by fofanafi

  • Status changed from new to open

comment:5 Changed 3 years ago by fofanafi

Focus still goes out of dialog with jQuery UI 1.8.11:

 http://jsbin.com/adika3/3

comment:6 Changed 3 years ago by scott.gonzalez

#3350 is a duplicate of this ticket.

comment:7 Changed 3 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 3 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 3 years ago by scott.gonzalez

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

comment:10 follow-up: ↓ 11 Changed 3 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 3 years ago by scott.gonzalez

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 3 years ago by scott.gonzalez (previous) (diff)

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

  • Keywords redesign added

comment:15 Changed 3 years ago by julienw

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

comment:16 Changed 2 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 2 years ago by scott.gonzalez

  • Milestone changed from 1.9.0 to 1.10.0

comment:18 Changed 2 years ago by southerd

  • Owner set to southerd
  • Status changed from open to 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.

comment:19 Changed 2 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 2 years ago by southerd

  • Status changed from assigned to closed
  • Resolution set to fixed

comment:22 Changed 2 years ago by scott.gonzalez

  • Status changed from closed to reopened
  • Resolution fixed deleted

Tickets need to stay open until merged into master.

comment:23 Changed 2 years ago by David Souther

  • Status changed from reopened to closed
  • Resolution set to fixed

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

Changeset: 3a09a4a0de1f485a63091ffe8188b080a561b592

Note: See TracTickets for help on using tickets.