User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0 Build ID: 20180516032328 Steps to reproduce: 1) Go to www.youtube.com 2) Try to search something immediately after the site has finished loading by typing on the keyboard Actual results: The typed letters don't appear in the search-box at the top of the site, since it is not selected I first noticed this behaviour of not selecting the searchbox after upgrading Firefox from version 59 to 60. It does not work in 62.0a1 (2018-05-22) either. Expected results: The typed letters should appear in the search-box, so that you don't have to click into it before. Works in Chrome and Edge

regression window: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=ebc312ac3d390133cafbb1c5538055ed2a6c0d0e&tochange=dc9ba6649af7290170dc76be598ea669a169c6a2 regressed by: Bug 712130

I've only looked at this briefly, but it appears the HTML sent by youtube contains an autofocus input element which is later replaced by a Polymer template instantiation. My guess is that the initial input element is properly getting autofocused, after which we ignore further autofocus attributes as per step 8 of the autofocusing steps (see https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofocusing-a-form-control:-the-autofocus-attribute). The other browsers appear to be skirting the spec here by processing autofocus multiple times. The relevant behavior is controlled by mAutoFocusFired in nsDocument.

(In reply to :decltype from comment #2) > I've only looked at this briefly, but it appears the HTML sent by youtube > contains an autofocus input element which is later replaced by a Polymer > template instantiation. My guess is that the initial input element is > properly getting autofocused, after which we ignore further autofocus > attributes as per step 8 of the autofocusing steps (see > https://html.spec.whatwg.org/multipage/form-control-infrastructure. > html#autofocusing-a-form-control:-the-autofocus-attribute). > > The other browsers appear to be skirting the spec here by processing > autofocus multiple times. The relevant behavior is controlled by > mAutoFocusFired in nsDocument. Anne, are you aware of any bugs already opened on HTML for this?

(oops, see ni? for Comment #3)

Heya, I don't think there's a bug for that. However, html/semantics/forms/autofocus/first-when-later.html only fails in Safari, so something more might be going on here?

(In reply to Anne (:annevk) from comment #5) > html/semantics/forms/autofocus/first-when-later.html only fails in Safari, > so something more might be going on here? Removing the first input element before inserting the second one exposes the difference. Chrome will happily give the second input focus, while Firefox remembers that it has already autofocused another element.

Related to https://github.com/whatwg/html/issues/3498.

I created https://github.com/web-platform-tests/wpt/pull/11193. It seems that Chrome/Safari won't set the per-document flag if the element was removed by the time the task runs. Safari doesn't seem to have a per-document flag at all, but I'm not sure if that's desirable.

I have a hard time reproducing the bug (I have the same bug in Chrome 72 actually), so I am not setting our pre-release channels as affected.