Bug 47182 – Focus remains on hidden element

• Component: WebCore Misc.
• Status: NEW

[doum-ti-di-li-doom]

Created attachment 69791 [details]
Demo

Focus remains on element after its parent container is styled with display:none.

Wait a second until element is hidden.
Press any key.

You will receive a message, proving now-hidden element still has focus.

[Alexey Proskuryakov]

This is a difference with Firefox, but I don't see why this is necessarily a bad behavior.

[doum-ti-di-li-doom]

Inconsistency is bad

An element keeps its focus after being hidden
But a hidden element cannot gain focus

In fact, Internet Explorer is like Firefox when you set style.display="none" (I was reporting the bug with that demo)

To recap:
http://xirc.chez.com/ie9-focus-1.html (focus then style.display)
Allowed by Opera / Safari

http://xirc.chez.com/ie9-focus-2.html (focus then className)
Allowed by Opera / Safari / Internet Explorer

http://xirc.chez.com/ie9-focus-3.html (style.display then focus)
Allowed by Opera

http://xirc.chez.com/ie9-focus-4.html (className then focus)
Allowed by Opera

[Alexey Proskuryakov]

Yes, we should be different if IE and Firefox both do the same thing.

[Kaustubh Atrawalkar]

here the issue seems to be cancelFocusAppearenceUpdate() call. Which does remove the focus appearance but does not set the focus back to 0. The current usage of this call is only in focus() & detach() calls in Element.cpp. We can add setFocus(0) in this function definition to avoid retaining of the focus after display:none. Element::blur() does the same thing, which we might able to use here.

[Kaustubh Atrawalkar]

Is this issue to be fixed? Seems to be inconsistent on different platforms.

[Vineet Chaudhary (vineetc)]

I think we have similar issue https://bugs.webkit.org/show_bug.cgi?id=40338 .

[Ryosuke Niwa]

(In reply to comment #5)
> Is this issue to be fixed? Seems to be inconsistent on different platforms.

I think we should fix it. But it'll be nice to bring it up on whatwg to specify this behavior if it hasn't been done so already.

[Ryosuke Niwa]

One tricky part of fixing this bug will be that we must fire blur event before removing the focus. Since we wouldn't know whether an element is visible or not until style recalc, it might have a weird side effects.

For example, we had decided to remove the focus when at the end of style-recalc, we might have a trouble dealing with situations like:

var element = ...

element.focus();
element.style.display = 'none';
element.title = 'hello'; // blur hasn't fired yet here
var x = element.offsetTop; // blur fires here

Because style recalc doesn't happen until offsetTop is obtained in the last line.

[Kaustubh Atrawalkar]

Right, so if we fire the blur event and then call blur instead of cancelFocusApperance() will be right way to do it? Also, i tried with blur replacing cancelFocusApperance, but its causing few layout tests to be failed. Need to look in more detail.

[Alexey Proskuryakov]

We should be very careful when considering changes in this area. Accepting key events on an invisible element is a fairly common technique - my understanding is that even Google Docs does something similar.

[Ryosuke Niwa]

(In reply to comment #9)
> Right, so if we fire the blur event and then call blur instead of cancelFocusApperance() will be right way to do it? Also, i tried with blur replacing cancelFocusApperance, but its causing few layout tests to be failed. Need to look in more detail.

The real question is when to call those functions. Checking the computed value of display property of the focused node every time style changes is prohibitively inefficient and expensive. On the other hand, if we wait until style recalc happens, then there will be a noticeable delay between the time the element was hidden and blur is fired.

[Kaustubh Atrawalkar]

The whatwg mailing list thread for the issue - 
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-February/034929.html

[Ryosuke Niwa]

To paraphrase Ian's response, the spec requires the focus be dropped in this case.

[Ryosuke Niwa]

Also see https://bugs.webkit.org/show_bug.cgi?id=40338.

[Manuel Rego Casasnovas]

It seems only Chrome behaves like this, and the spec text seems to support that behavior:
https://bugs.chromium.org/p/chromium/issues/detail?id=491828

Issues in other bugtrackers:
* Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=559561
* Edge: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/1308960/

[Radar WebKit Bug Importer]

<rdar://problem/31801261>