New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 660999 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Dec 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Making the focused element un-focusable doesn't change document.activeElement to body synchronously

Reported by rodneyr...@googlemail.com, Oct 31 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/56.0.2905.0 Safari/537.36

Example URL:
https://jsbin.com/fesexin/edit

Steps to reproduce the problem:
1. create an <input>
2. focus the input
3. disable the input

What is the expected behavior?
document.activeElement keeps pointing to the <input>

What went wrong?
document.activeElement points at <body>

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 56.0.2905.0  Channel: canary
OS Version: OS X 10.10.5
Flash Version: 

see https://allyjs.io/tutorials/mutating-active-element.html#the-results for a matrix of browser behavior.

When the currently focused element is changed so that it wouldn't receive focus anymore (by hiding it, disabling it, or removing the tabindex attribute) Chrome shifts focus back to <body> while all other browsers retain focus on the active element.

While this behavior is not specified (to the best of my knowledge), Chrome is the only browser behaving differently. Also see https://github.com/whatwg/html/issues/1972

A relevant use case for disabling buttons upon invocation is to prevent duplicate execution due to double clicks and "impatient users".
 
Cc: rbyers@chromium.org
Components: -Blink Blink>Focus
Labels: Hotlist-Interop

Comment 2 by kochi@chromium.org, Nov 1 2016

Cc: kochi@chromium.org
Status: Available (was: Unconfirmed)
Status: WontFix (was: Available)
Chrome's behavior is correct per spec; see https://github.com/whatwg/html/issues/1972. Let me close this as wontfix for now, but rbyers@ and kochi@, if you think we should change the spec, please let me know.

Chrome is in the minority in some cases in the link the OP posted, but Chrome also has the most sensible and uniform behavior. So my plan is to write web platform tests and file bugs on other browsers instead.

Comment 4 by kochi@chromium.org, Nov 2 2016

domenic@ sounds a great plan!
Status: Available (was: WontFix)
Summary: Making the focused element un-focusable doesn't change document.activeElement to body synchronously (was: mutating document.activeElement resets focus to document.body)
I have discovered that Chrome doesn't reset the activeElement "fast enough". I wrote some web platform tests that Chrome fails: https://github.com/w3c/web-platform-tests/pull/4160

If you modify the tests by adding a setTimeout and waiting for a bit before checking activeElement, it gets correctly updated to the body. But it doesn't happen immediately, like it should, which is sad. (And it's inconsistent; Chrome figures it out when you remove the element, but not in the other three cases.)

So I will reopen and rename this issue.

Comment 6 by tkent@chromium.org, Dec 19 2016

Owner: tkent@chromium.org
Status: Started (was: Available)
We postpone blur processing until next layout because we thought dispatching events at a deeper place of setAttribute(...) was dangerous.  Now I have an idea of a safer way.

Project Member

Comment 8 by bugdroid1@chromium.org, Dec 21 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/40ccb2581137efc2fc7d2a1041073fa00caed75a

commit 40ccb2581137efc2fc7d2a1041073fa00caed75a
Author: tkent <tkent@chromium.org>
Date: Wed Dec 21 09:45:45 2016

Blur immediately if an attribute change made an element unfocusable.

tabindex, hidden, contenteditable, disabled, href attributes affect element
focusability, however we didn't remove focus from the element immediately after
an attribute change made the element unfocusable because dispatching events in
parseAttribute() looks dangerous. Actually, dispatching events for update of
some specific attributes in parseAttribute() can cause bugs.

With this CL, we remove focus in Element::attributeChanged().

* Element::AttributeModificationReason
  Add kByParser, and update existing item names.
  We don't check focusability for kByParser and kByCloning because the element
  can't be focused in these cases.

* Element::attributeChanged()
  Stop using a default argument.
  Move focus check for tabindex change from parseAttribute().

* HTMLAnchorElement
  Move focus check for href change from parseAttribute() to attributeChanged().

* HTMLElement
  Move focus check for hidden and contenteditable change from parseAttribute()
  to attributeChanged().

* HTMLFormControlElement
  Move focus check for disabled change from parseAttribute() to
  attributeChanged().

* HTMLFieldSetElement
  Check focusability of descendant form controls when the fieldset element is
  disabled, or a legend element is inserted.

BUG= 660999 

Review-Url: https://codereview.chromium.org/2586143004
Cr-Commit-Position: refs/heads/master@{#440063}

[modify] https://crrev.com/40ccb2581137efc2fc7d2a1041073fa00caed75a/third_party/WebKit/LayoutTests/fast/dom/HTMLAnchorElement/remove-href-from-focused-anchor-expected.txt
[modify] https://crrev.com/40ccb2581137efc2fc7d2a1041073fa00caed75a/third_party/WebKit/LayoutTests/fast/dom/HTMLAnchorElement/remove-href-from-focused-anchor.html
[delete] https://crrev.com/a4fad38f7761ee4193d30b80416d26c6412b991c/third_party/WebKit/LayoutTests/imported/wpt/html/editing/focus/processing-model/focus-fixup-rule-one-no-dialogs-expected.txt
[modify] https://crrev.com/40ccb2581137efc2fc7d2a1041073fa00caed75a/third_party/WebKit/Source/core/dom/Document.cpp
[modify] https://crrev.com/40ccb2581137efc2fc7d2a1041073fa00caed75a/third_party/WebKit/Source/core/dom/Document.h
[modify] https://crrev.com/40ccb2581137efc2fc7d2a1041073fa00caed75a/third_party/WebKit/Source/core/dom/Element.cpp
[modify] https://crrev.com/40ccb2581137efc2fc7d2a1041073fa00caed75a/third_party/WebKit/Source/core/dom/Element.h
[modify] https://crrev.com/40ccb2581137efc2fc7d2a1041073fa00caed75a/third_party/WebKit/Source/core/html/HTMLAnchorElement.cpp
[modify] https://crrev.com/40ccb2581137efc2fc7d2a1041073fa00caed75a/third_party/WebKit/Source/core/html/HTMLAnchorElement.h
[modify] https://crrev.com/40ccb2581137efc2fc7d2a1041073fa00caed75a/third_party/WebKit/Source/core/html/HTMLElement.cpp
[modify] https://crrev.com/40ccb2581137efc2fc7d2a1041073fa00caed75a/third_party/WebKit/Source/core/html/HTMLElement.h
[modify] https://crrev.com/40ccb2581137efc2fc7d2a1041073fa00caed75a/third_party/WebKit/Source/core/html/HTMLFieldSetElement.cpp
[modify] https://crrev.com/40ccb2581137efc2fc7d2a1041073fa00caed75a/third_party/WebKit/Source/core/html/HTMLFieldSetElement.h
[modify] https://crrev.com/40ccb2581137efc2fc7d2a1041073fa00caed75a/third_party/WebKit/Source/core/html/HTMLFormControlElement.cpp
[modify] https://crrev.com/40ccb2581137efc2fc7d2a1041073fa00caed75a/third_party/WebKit/Source/core/html/HTMLFormControlElement.h
[modify] https://crrev.com/40ccb2581137efc2fc7d2a1041073fa00caed75a/third_party/WebKit/Source/core/html/HTMLInputElement.cpp
[modify] https://crrev.com/40ccb2581137efc2fc7d2a1041073fa00caed75a/third_party/WebKit/Source/core/html/HTMLSlotElement.h
[modify] https://crrev.com/40ccb2581137efc2fc7d2a1041073fa00caed75a/third_party/WebKit/Source/core/svg/SVGElement.cpp
[modify] https://crrev.com/40ccb2581137efc2fc7d2a1041073fa00caed75a/third_party/WebKit/Source/core/svg/SVGElement.h

Comment 9 by tkent@chromium.org, Dec 26 2016

Labels: M-57 OS-Android OS-Chrome OS-Linux OS-Windows
Status: Fixed (was: Started)
Components: Blink>HTML>Focus
Components: -Blink>Focus

Sign in to add a comment