662496 - autofocus not work when the element is added to the DOM after the document is done loading (e.g. in window.onload)

Status: NEW

(Core :: DOM: Core & HTML, defect)

Description

[Philip Tzou]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 FirePHP/0.5
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1 FirePHP/0.5

I'm trying to implement a HTML5 attribute "autofocus" to my site. But I found the element won't be focused under FF4 if I append the element to body during window.onload. It works under webkit/Chrome, so I thought it could be a bug need to be fixed.

Reproducible: Always

Steps to Reproduce:
Save these two page to html files then open them and you'll see the difference.

work: http://p.defau.lt/?eUOAGVSSq0ZUyNzJV7cZ_w
not work: http://p.defau.lt/?_39KOq8OIYy_RYwS7F1NxA

Comment 1

[Boris Zbarsky [:bzbarsky]]

Hmm.  Mounir, the spec seems to call for autofocus to always take effect on insertion, but our implementation only does so if the readystate is not complete.  What's up with that?  Did the spec change?

Comment 2

[Mounir Lamouri (:mounir)]

In Gecko's implementation, autofocus will only work before the load event, basically. In other words, you can autofocus an element in your initial HTML page. If you add an element dynamically, we encourage you to use .focus().

(In reply to comment #1)
> Hmm.  Mounir, the spec seems to call for autofocus to always take effect on
> insertion, but our implementation only does so if the readystate is not
> complete.  What's up with that?  Did the spec change?

IIRC, we asked for a few changes in the specs and a few of them have been rejected like this one. Though, I don't see any reason to allow the autofocus attribute instead of the .focus() attribute on dynamic insertions. As I understand it, the autofocus attribute should be used to say "when you load this page, please focus this element", it should not be a way to steal the user focus.

IMO, we should WONTFIX this bug.

Comment 3

[Ojan Vafai]

What is the advantage of making autofocus only work before load? The page can already use .focus() to steal user focus anyways, so it's not exposing a new capability. It's just making it easier to do.

Stated differently, I don't see how before page load is any different than after page load time as far as the user is concerned. If the page is blocked on slow loading images, the user very well might still have focus stolen.

Comment 4

[Ojan Vafai]

Equivalent WebKit bug: https://bugs.webkit.org/show_bug.cgi?id=68876

Comment 5

[Mounir Lamouri (:mounir)]

(In reply to Ojan Vafai from comment #3)
> What is the advantage of making autofocus only work before load? The page
> can already use .focus() to steal user focus anyways, so it's not exposing a
> new capability. It's just making it easier to do.

The autofocus attribute should be a declarative way to set the focus. It should not be used to set the focus instead of using .focus(). For example, autofocus should not be used to move the focus when a user is blocking scripts.

> Stated differently, I don't see how before page load is any different than
> after page load time as far as the user is concerned. If the page is blocked
> on slow loading images, the user very well might still have focus stolen.

That is an unfortunate edge case.

Comment 6

[Ojan Vafai]

(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #5)
> (In reply to Ojan Vafai from comment #3)
> > What is the advantage of making autofocus only work before load? The page
> > can already use .focus() to steal user focus anyways, so it's not exposing a
> > new capability. It's just making it easier to do.
> 
> The autofocus attribute should be a declarative way to set the focus. It
> should not be used to set the focus instead of using .focus(). For example,
> autofocus should not be used to move the focus when a user is blocking
> scripts.

I'm OK with there being cases where autofocus is ignored. The spec allows that for cases where the user has indicated in some way they want focus elsewhere. Personally, I don't think these cases are worth addressing either, but that's a whole different argument from whether it should be tied to the load event.

Consider long-lived pages like gmail. It seems perfectly natural and correct to me for them to use a declarative interface for focusing the subject line of an email when you go to compose a new email. It's essentially no different from a fresh page load from the user-perspective, but it all happens after the load event.

Comment 7

[Ojan Vafai]

The load is a completely arbitrary proxy for whether the user might have focused something else. Why not use DOMContentLoaded?

Why not actually track whether the user has focused/typed something recently? That seems like it would work best. Then you're reacting to the actual user-experience.

Comment 8

[Mounir Lamouri (:mounir)]

(In reply to Ojan Vafai from comment #7)
> The load is a completely arbitrary proxy for whether the user might have
> focused something else. Why not use DOMContentLoaded?

load event or DOMContentLoaded isn't that much of a difference. I guess you don't care given that wouldn't solve the use cases you pointed.

> Why not actually track whether the user has focused/typed something
> recently? That seems like it would work best. Then you're reacting to the
> actual user-experience.

Actually, if the user has focused something on the page, the autofocus attribute will be ignored. The, load event or not, after the user did interact with the page, we will ignore the autofocus attribute.

Comment 9

[Joe Walker [:jwalker]]

I've just stumbled over this bug, and it made Firefox look broken to me.

The page has dynamically generated content, which includes an <input autofocus> element.
Something changed on page load causing page load to happen differently and now Chrome still autofocuses, but Firefox doesn't. I just added a .focus() to fix the firefox case, but concerned that I'm annoying users who might be getting on with something else when the focus happens.

Do we have a reason to keep it the way it is?

Comment 12

[Luke Matthews]

This bug does indeed make Firefox look broken. After encountering it in a use case with a certain website, I looked into the matter further and found something downright sad:

http://jsfiddle.net/NobodyNowhere/3tzoo6ky/

This fiddle will automatically focus the input element with Chrome (and other browsers) when the page is loaded, as well as when the Run button is clicked etc. On Firefox 31, it does not focus. Ever.

It's really a drag to have popups/new elements with inputs focus themselves correctly on Chrome, and not Firefox. For example, on the aforementioned website the page creates an iframe (for an inline popup) with an autocomplete input at the top. The input has the autofocus attribute, but Firefox ignores it while Chrome focuses it. Please fix this implementation and bring this basic functionality up to where it should be.

Comment 13

[wstanzl]

There is another case which exposes this bug. 

Using Firefox 37.0.2

Code an input element with style="visbility: hidden" and autofocus then (e.g. onload) use a script which sets element.style.visibility = 'visible'; 

The element will not receive focus, even if it is the only input element on the page. 

I use this to wait for css to fully load to avoid unformatted flicker.

This is explained by Comment 1 - and can be circumvented by element.focus() - but it really feels flawed.

Comment 14

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.

Comment 15

[Igor]

Still an issue. In Firefox 65 Dev edition on Desktop autofocus is not making any focus to an input

Comment 16

[Chris Peterson [:cpeterson]]

Here is a real-world example of this bug:

Description: "Enter a movie title" search input box is not auto-focused in Firefox

Steps to Reproduce:

1. Load https://www.taste.io/search

EXPECTED RESULT:
The "Enter a movie title" search input box should be auto-focused like it is in Chrome, Edge, and IE11 on Windows and in Chrome and Safari on macOS.

ACTUAL RESULT:
The search input box is NOT auto-focused in Firefox on Windows or macOS.

Comment 17

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 18

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 19

[Firefox Bug Husbandry Bot]

Reverting spam.

Comment 20

[Boris Zbarsky [:bzbarsky]]

Olli, do you know who might want to look at aligning autofocus stuff with other browsers?

Comment 21

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Boris Zbarsky [:bzbarsky] from comment #20)

Olli, do you know who might want to look at aligning autofocus stuff with other browsers?

I will follow this up.

Comment 23

[Dean]

I just want to point out that autofocus has two separate effects: It focuses an element, AND SCROLLS IT INTO VIEW.

It seems to me that even if (for whatever reason) you can't honor the first of these, the second should still take place. (e.g. if it's in an iframe, and the parent page has the focus).

For an example of why this can be important, I have a (private) website with some quite long forms on it. When there's an error on one of the fields after submit, the form is re-displayed to the user with the error field highlighted and autofocus'ed. The scroll behaviour of autofocus is expected to make the errant field visible on load, if it's initially below the visible viewport area, even in the absence of javascript.

(As it doesn't work in iframes, I use the obvious workaround of using a fragment identifier as well, but this has the undesirable consequence of leaving the fragment identifier in the window history: autofocus would be better. Using a fragment identifier also involves checking the element for an ID that can be used, and insterting one if there isn't already one... it's not necessarily trivial).