Open Bug 1272328 Opened 6 years ago Updated 2 years ago

Autofocus doesn't work in iframe after navigation


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

46 Branch





(Reporter: f2424880, Unassigned)


(Depends on 1 open bug)



(1 file)

When an iframe is first loaded together with its enclosing page, the "autofocus" attribute on inputs inside the iframe works as expected.  However if the iframe is navigated to a new page, "autofocus" on an element in this new page is ignored.

I am attaching a .zip containing three html files, which need to be placed in the same location (local or server folder):

test1.html - the enclosing page containing the iframe
test2.html - the initial iframe contents, containing an autofocus field and a navigation button leading to test3.html
test3.html - another page containing an autofocus input field 

Navigate to test2.html:  Observe the auto-focussed input field.
Now click the button.  Observer that the new page also has an auto-focussed input field.  This is the expected behaviour.

Now do the same thing, but by opening test1.html.  This just displays test2.html inside a red-bordered iframe.  Note that the initial autofocus field works, but after the button is clicked, no element is auto-focussed on the new page that loads inside the iframe.

This clearly seems like a bug.  It's as if autofocus is only applied when the top-level browsing context is navigated, even though the attribute occurs in an iframe; it should be applied to pages inside iframes whenever those iframes are navigated, surely?
Component: Untriaged → DOM: Core & HTML
Priority: -- → P5

3 years and nothing happening?

I'd just like to add, it seems as if the logic here is that:

  • autofocus gets applied (wherever it is in the document tree) when the top-level window navigates/loads

  • But on navigating or reloading an iframe within an existing document, autofocus is disabled because otherwise it might steal focus from somewhere else in the document.

The latter is certainly a valid concern; you don't want the focus to shift while the user is typing in a input field, for example. However, disabling autofocus altogether for navigating/reloading iframes is too extreme a solution, and can break some essential functionality. For example, consider a website that has a nav-bar and a content area implemented as two separate iframes, and is using autofocus to scroll a serverside-detected user-input error in a form field into view and focus it when the user tries to submit a form containing invalid data, from inside the content iframe: This common use-case no longer works at all.

I propose the following changes to the behaviour of autofocus inside iframes:

  • Even when there's a parent document that already has focus elsewhere (that therefore can't be shifted to the iframe), an autofocus element within an iframe should be SCROLLED INTO VIEW within that iframe, despite not being able to be given the focus.

  • If an element within an iframe has focus, and then that iframe navigates or reloads, and if focus is not captured by any element in the parent document (or document tree) during that process, then autofocus should be honoured within the iframe. In particular, if you simply click a link or a submit button inside an iframe and don't interact further with the browser, then (assuming no scripts change the focus element) when the iframe finishes (re-)loading, if it's document contains an autofocus element, focus SHOULD be given to that element.

  • Additionally, there should probably be an attribute you can set on the iframe to control whether autofocus within the iframe works (i) always, (ii) never, (iii) only on the initial top-level load, or (iv) as just described above (which should be the default).

So... what are the chances someone will take some action on this within the next three years...?

It's as if autofocus is only applied when the top-level browsing context is navigated

That is precisely correct, yes. Autofocus is not applied after the toplevel document is done loading right now, to avoid focus-stealing behaviors.

Depends on: 662496
You need to log in before you can comment on or make changes to this bug.