Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(193)

Issue 2428333002: <dialog>: don't focus non-form elements with tabindex < 0 when showModal() is called (Closed)

Created:
4 years, 2 months ago by Dan Beam
Modified:
4 years ago
Reviewers:
falken, tkent
CC:
chromium-reviews, blink-reviews, dglazkov+blink, blink-reviews-html_chromium.org, esprehn, dpapad
Target Ref:
refs/pending/heads/master
Project:
chromium
Visibility:
Public.

Description

<dialog>: don't focus non-form elements with tabindex < 0 when showModal() is called Note: things like <button tabindex="-1"> still jack focus unexpectedly (IMO). R=falken@chromium.org,tkent@chromium.org BUG=656924

Patch Set 1 : asdf #

Total comments: 1
Unified diffs Side-by-side diffs Delta from patch set Stats (+53 lines, -1 line) Patch
A third_party/WebKit/LayoutTests/fast/dom/HTMLDialogElement/dialog-focus.html View 1 chunk +37 lines, -0 lines 1 comment Download
A third_party/WebKit/LayoutTests/fast/dom/HTMLDialogElement/dialog-focus-expected.txt View 1 chunk +12 lines, -0 lines 0 comments Download
M third_party/WebKit/Source/core/html/HTMLDialogElement.cpp View 2 chunks +4 lines, -1 line 0 comments Download

Messages

Total messages: 14 (10 generated)
Dan Beam
falken@ cuz dialog tkent@ cuz owners
4 years, 2 months ago (2016-10-19 05:01:34 UTC) #7
Dan Beam
/cc esprehn@ and dpapad@ as fyi
4 years, 2 months ago (2016-10-19 05:02:00 UTC) #8
tkent
<button tabindex=-1> is excluded from sequential focus navigation, but is still a focusable area. https://html.spec.whatwg.org/multipage/forms.html#dialog-focusing-steps ...
4 years, 2 months ago (2016-10-19 05:23:29 UTC) #11
falken
4 years, 2 months ago (2016-10-19 06:15:30 UTC) #12
On 2016/10/19 05:23:29, tkent wrote:
> <button tabindex=-1> is excluded from sequential focus navigation, but is
still
> a focusable area.
> 
> https://html.spec.whatwg.org/multipage/forms.html#dialog-focusing-steps
> > If there isn't one, then let control be the first non-inert focusable area
in
> subject's control group.
> 
> https://html.spec.whatwg.org/multipage/interaction.html#control-group
> > Focusable areas in control groups are ordered relative to the tree order of
> their DOM anchors. Focusable areas with the same DOM anchor in a control group
> are ordered relative to their CSS box's relative positions in a pre-order,
> depth-first traversal of the box tree. [CSS]
> 
> So, the current behavior looks correct according to the standard.

I spoke with Dan Beam offline and although the current spec mandates focusing
these elements when opening a dialog it sounds like it's not what developers
would expect.

Dan: Could you link to https://github.com/whatwg/html/issues/1929 in the CL
description?

https://codereview.chromium.org/2428333002/diff/40001/third_party/WebKit/Layo...
File third_party/WebKit/LayoutTests/fast/dom/HTMLDialogElement/dialog-focus.html
(right):

https://codereview.chromium.org/2428333002/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/dom/HTMLDialogElement/dialog-focus.html:23:
<!-- TODO(dbeam): add form controls and anchors with negative tabindex.
Can the TODO include information about when it is actionable? And why not add
these now?

Powered by Google App Engine
This is Rietveld 408576698