Html: Autofocus element in a <dialog> tries to get focus twice
The following code shows FOCUS log twice.
<!DOCTYPE html>
<pre></pre>
<dialog>
<input autofocus onfocus="log()">
<a href="http://www.google.com/">Help</a>
</dialog>
<script>
function log() {
document.querySelector('pre').textContent += 'FOCUS\n';
}
document.querySelector('dialog').show();
document.activeElement.blur();
</script>
- The HTML parser inserts the
inputto the document tree, and it posts the autofocus task. dialog.show()sets focus on theinputsynchronously.- When the task is executed, the
inputis focused again.
tkent-google
All 7 comments
Should removing autofocus solve the problem??
rahulpurohit29
on 19 Jul 2019
Should removing autofocus solve the problem??
yes. but 1) asking every author who's coded such to fix will not scale and 2) triggering the focus event yet the surrounding dialog hasn't been shown does seem a spec bug. I guess that's why tkent filed the issue.
myakura
on 19 Jul 2019
Is this somehow same as #4356 ? 馃
CYBAI
on 19 Jul 2019
This seems unrelated to #4356, which involves neither dialog nor autofocus.
Some options, all based on #4763's processing model (where this will still be a problem, via a slightly different set of steps):
Leave as-is. This is an emergent combination of behaviors, and in practice may not be too bad of a problem.
Have the parser ignore autofocus in dialog when constructing the autofocus candidates list. This seems pretty reasonable, but I guess there might be slightly-more-complicated cases similar to the OP that this fails to solve?
Set the document's autofocus processed flag whenever anything gets focused. (Probably this means, whenever the focusing steps get run for anything.)
Remove autofocus behavior inside dialogs, as part of a general project to simplify/maybe eventually remove dialog, because dialog is currently a single-vendor feature. This would make the most sense if a non-Blink implementer supported dialogs-without-autofocus more than they supported dialogs-with-autofocus.
I don't have a strong opinion on any particular solution. I'll CC @rniwa since he has been helpful on focus thoughts from WebKit's perspective in the past.
domenic
on 19 Jul 2019
I don't think web developers have problems due to this behavior. This issue does't have high priority.
The second bullet in @domenic's comment sounds a simple solution. We can just add a step like "If there is a dialog which is an ancestor of the element, then return" to the autofocus steps.
tkent-google
on 25 Jul 2019
If we change this we should also try to resolve https://github.com/whatwg/html/issues/2393 while we're in the area. (Although it's unclear to me from reading that thread if there's any actual changes desired; more that we need to give the general dialog + autofocus space some thinking.)
domenic
on 1 Aug 2019
@tkent-google would you be up for trying to resolve this and #2393 now that #4763 is merged?
domenic
on 18 Sep 2019
Related issues
dominiccooney
路
102Comments
stevefaulkner
路
110Comments
annevk
路
93Comments
annevk
路
60Comments
tkent-google
路
72Comments
Most helpful comment
This seems unrelated to #4356, which involves neither dialog nor autofocus.
Some options, all based on #4763's processing model (where this will still be a problem, via a slightly different set of steps):
Leave as-is. This is an emergent combination of behaviors, and in practice may not be too bad of a problem.
Have the parser ignore autofocus in dialog when constructing the autofocus candidates list. This seems pretty reasonable, but I guess there might be slightly-more-complicated cases similar to the OP that this fails to solve?
Set the document's autofocus processed flag whenever anything gets focused. (Probably this means, whenever the focusing steps get run for anything.)
Remove autofocus behavior inside dialogs, as part of a general project to simplify/maybe eventually remove dialog, because dialog is currently a single-vendor feature. This would make the most sense if a non-Blink implementer supported dialogs-without-autofocus more than they supported dialogs-with-autofocus.
I don't have a strong opinion on any particular solution. I'll CC @rniwa since he has been helpful on focus thoughts from WebKit's perspective in the past.