Update autofocus processing algorithm #4763

tkent-google · 2019-07-11T05:32:10Z

Run focusing steps after an animation frame
Don't autofocus if the top-level document has focused area
Don't autofocus if one of ancestor document has non-empty URI fragments.

This fixes #3551 and #4645

At least two implementers are interested (and none opposed):
- Chrome: Yes
- Firefox: Yes HTML: autofocus="" overhaul mozilla/standards-positions#195
- Safari: @rniwa ?
Tests are written and can be reviewed and commented upon at:
- html: Update tests for an autofocus algorithm update web-platform-tests/wpt#17929
Implementation bugs are filed:
- Chrome: crbug.com/985636 and crbug.com/382901
- Firefox:https://bugzilla.mozilla.org/show_bug.cgi?id=1574435
- Safari: https://bugs.webkit.org/show_bug.cgi?id=129743 https://bugs.webkit.org/show_bug.cgi?id=140963

(See WHATWG Working Mode: Changes for more details.)

/interaction.html ( diff )
/webappapis.html ( diff )

domenic

Looking great; this seems to meet all the requirements from linked threads, and generally be a more sensible and user-friendly model.

Most of my suggestions are nits, but some are about clarifications where I'm not 100% sure I understood the intent.

source

domenic · 2019-07-11T20:46:10Z

source

+        </p></li>
+      </ol>
+
+     <li><p>If <var>element</var> is a <span>focusable area</span>, then set


Better to break the three things down into 1. 2. 3.

It may also be good to add a note about when something might reach this step while not being a focusable area. (E.g. it became hidden.)

Done: Added a sub-<ol>.

Added a note <p>. Actually, we add any element with autofocus attribute to candidates list without checking focusable area or not.

source

domenic

LGTM. Let's get some tests written so we can see how this compares to Gecko/WebKit behavior, i.e. how much of a change this would be for them. I still remain hopeful that even without that, they'll chime in to let us know if the algorithm makes sense.

tkent-google · 2019-07-18T08:08:04Z

source

+
+   <li>
+    <p>If <var>topDocument</var>'s <span data-x="focused area of the document">focused area</span>
+    is not <var>topDocument</var> itself, or <var>topDocument</var>'s <span>target element</span> is


I found checking 'target element' of a document was not helpful because it is set asynchronously and an autofocus element can get focus before setting 'target element'. I'd like to change "document's target element is not null" to " document's URL's fragment is not empty".

url's fragment may change too during page load. But I guess that isn't really an issue.

It's possible that URL fragment is empty, a user indicated a specific scroll position, and the user doesn't want to change focused element by autofocus attribute.
However I have never heard complain about it. I think we can address it later if web developers complain.

whatwg/html#4763

tkent-google · 2019-07-19T10:04:31Z

Test PR: web-platform-tests/wpt#17929

domenic · 2019-07-22T20:53:32Z

source

@@ -91156,6 +91241,11 @@ dictionary <dfn>PromiseRejectionEventInit</dfn> : <span>EventInit</span> {
     <li><p>For each <span>fully active</span> <code>Document</code> in <var>docs</var>, update the
     rendering or user interface of that <code>Document</code> and its <span
     data-x="concept-document-bc">browsing context</span> to reflect the current state.</p></li>
+
+     <li><p>For each <span>fully active</span> <code>Document</code> in <var>docs</var>, <span>flush


What is the reasoning behind this position? So far it seems most things go before rAF callbacks, except intersection observer. So I would normally put this before...

Because 'focusable area' check needs style computation, and 'focusing steps' needs layout result. I'd like to put this step after finishing rendering in order to avoid an additional style computation and layout caused by 'flush autofocus candidates' steps.

Thanks, that makes sense. Can you add a source code comment (), or maybe a <p class="note">, explaining this? I'm not sure whether a <p class="note"> makes sense because the spec doesn't talk about style computation/etc., but at least a source code comment would help future spec editors.

Ok, I added a comment.

I'm still a bit concerned about this. We do want to have done style computation, but do we want to have done painting? Focusing things will generally scroll to them and whatnot. Will that just get picked up on the next tick of the rendering loop?

Yeah, "after paint" timing is better for kicking the flush steps.
I couldn't find places better than here in the HTML specification.

bzbarsky

This generally seems reasonable to me. @smaug---, thoughts?

source

bzbarsky · 2019-08-15T20:15:25Z

source

@@ -91156,6 +91241,11 @@ dictionary <dfn>PromiseRejectionEventInit</dfn> : <span>EventInit</span> {
     <li><p>For each <span>fully active</span> <code>Document</code> in <var>docs</var>, update the
     rendering or user interface of that <code>Document</code> and its <span
     data-x="concept-document-bc">browsing context</span> to reflect the current state.</p></li>
+
+     <li><p>For each <span>fully active</span> <code>Document</code> in <var>docs</var>, <span>flush


I'm still a bit concerned about this. We do want to have done style computation, but do we want to have done painting? Focusing things will generally scroll to them and whatnot. Will that just get picked up on the next tick of the rendering loop?

source

domenic · 2019-08-21T18:45:46Z

I feel like we're getting close to merging this. According to the test results, the new behavior doesn't match any browser exactly, but instead is an attempt to take advantage of the fact that browsers are not interoperable, in order to produce a good, reasonable specification that matches some union of their behaviors and meets user expectations.

@bzbarsky, would you like us to hold off for @smaug----'s review?

Also another attempt at pinging @rniwa, as he's been helpful and active reviewing other focus stuff recently.

rniwa · 2019-08-21T23:48:04Z

I'm going to look at this soon. I'm finishing up my work to update WebKit's tabIndex behavior still.

smaug---- · 2019-08-30T20:45:37Z

source

+
+     <li><p>If <span data-x="concept-document-url">URL</span>'s
+     <span data-x="concept-url-fragment">fragment</span> of any <code>Document</code> in
+     <var>inclusiveAncestorDocuments</var> is not empty, then <span>continue</span>.</p></li>


Probably just because of it is hard to see the context here, worth to check 'continue' makes sense?

candidates contains elements from various frames. So inclusiveAncestorDocuemnts for the next element in candidates may be different.

whatwg/html#4763

- Run focusing steps after an animation frame - Don't autofocus if the top-level document has focused area - Don't autofocus if one of ancestor document has :target element. This fixes whatwg#3551 and whatwg#4645

…tofocus candidates'

- Add top-level browsing context identification check

tkent-google · 2019-09-03T05:18:28Z

Rebased on ToT.

whatwg/html#4763

…rithm update, a=testonly Automatic update from web-platform-tests html: Update tests for an autofocus algorithm update (#17929) whatwg/html#4763 -- wpt-commits: 08e6411a9cb36e4e7987d24ddb31e1d62690e1cb wpt-pr: 17929

…rithm update, a=testonly Automatic update from web-platform-tests html: Update tests for an autofocus algorithm update (#17929) whatwg/html#4763 -- wpt-commits: 08e6411a9cb36e4e7987d24ddb31e1d62690e1cb wpt-pr: 17929 UltraBlame original commit: 99752f25f5f5ed857cc819607882fdb49e2d0509

rniwa · 2019-10-09T04:26:27Z

source

+     autofocus candidates</span> for that <code>Document</code> if its
+     <span data-x="concept-document-bc">browsing context</span> is a
+     <span>top-level browsing context</span>.</p></li>
+     <!-- The above step is placed just after 'update the rendering' step in order to avoid


This doesn't seem right. We've already marked the painting time. Why are we focusing an element and potentially arbitrary author scripts for arbitrary amount of time?

Also, "update the rendering or user interface of that Document and its browsing context to reflect the current state." updates the painting of the document. If we had focused an element, there is a good chance, the focus ring may should be drawn around the newly focused element. Yet autofocusing step being after this rendering update would mean that it would necessarily be one frame / rAF later.

Tracking this in #4992.

This was referenced Jul 11, 2019

Autofocus spec should probably allow browsers to delay running the focusing steps, maybe? #3551

Closed

Update autofocus algorithm #4645

Closed

domenic reviewed Jul 11, 2019

View reviewed changes

domenic added normative change topic: focus labels Jul 11, 2019

domenic approved these changes Jul 12, 2019

View reviewed changes

domenic added the needs tests Moving the issue forward requires someone to write tests label Jul 12, 2019

tkent-google commented Jul 18, 2019

View reviewed changes

tkent-google added a commit to web-platform-tests/wpt that referenced this pull request Jul 19, 2019

html: Update tests for an autofocus algorithm update

4a4be61

whatwg/html#4763

tkent-google mentioned this pull request Jul 19, 2019

html: Update tests for an autofocus algorithm update web-platform-tests/wpt#17929

Merged

domenic mentioned this pull request Jul 19, 2019

Autofocus element in a <dialog> tries to get focus twice #4788

Closed

domenic reviewed Jul 22, 2019

View reviewed changes

domenic mentioned this pull request Jul 29, 2019

HTML: autofocus="" overhaul mozilla/standards-positions#195

Closed

domenic removed the needs tests Moving the issue forward requires someone to write tests label Jul 30, 2019

domenic mentioned this pull request Aug 1, 2019

Move autofocus content attribute to HTMLElement #4563

Closed

bzbarsky reviewed Aug 15, 2019

View reviewed changes

tkent-google mentioned this pull request Aug 22, 2019

html: Add a test for 'autofocus' as a global attribute web-platform-tests/wpt#18558

Merged

annevk requested a review from smaug---- August 26, 2019 14:16

smaug---- reviewed Aug 30, 2019

View reviewed changes

smaug---- approved these changes Aug 30, 2019

View reviewed changes

tkent-google added a commit to web-platform-tests/wpt that referenced this pull request Sep 3, 2019

html: Update tests for an autofocus algorithm update

ed93cc5

whatwg/html#4763

tkent-google and others added 6 commits September 3, 2019 13:45

Update autofocus processing algorithm

cfb309c

- Run focusing steps after an animation frame - Don't autofocus if the top-level document has focused area - Don't autofocus if one of ancestor document has :target element. This fixes whatwg#3551 and whatwg#4645

Check script-blocking style sheet counter

8631893

apply review comments

5c10cec

Editorial/note tweaks

345c444

target element is not null -> URL's fragment is not empty

b1bb69e

Add a comment about the order o 'update the rendering', and 'flush au…

328c865

…tofocus candidates'

tkent-google added 2 commits September 3, 2019 14:03

- remove element from candidates before adding it.

1893cf1

- Add top-level browsing context identification check

Fix merge conflicts, etc.

59ef44d

tkent-google force-pushed the tkent-autofocus-refresh branch from 81b2976 to 59ef44d Compare September 3, 2019 05:17

domenic merged commit 2d783db into whatwg:master Sep 3, 2019

foolip pushed a commit to web-platform-tests/wpt that referenced this pull request Sep 3, 2019

html: Update tests for an autofocus algorithm update (#17929)

08e6411

whatwg/html#4763

rniwa reviewed Oct 9, 2019

View reviewed changes

rniwa mentioned this pull request Oct 9, 2019

Flushing of autofocus candidates should happen before updating the rendering of documents #4992

Closed

domenic mentioned this pull request Mar 25, 2020

Editorial: make implicit autofocus algorithm flag explicit #3498

Closed

tkent-google deleted the tkent-autofocus-refresh branch April 10, 2020 09:20

siusin mentioned this pull request Apr 13, 2020

HTML Standard (Jan 2020): review tracker w3c/htmlwg#8

Open

8 tasks

This was referenced Oct 25, 2021

HTML: remove autofocused element before its task runs web-platform-tests/wpt#11193

Closed

Autofocus test port web-platform-tests/wpt#16780

Closed

domenic mentioned this pull request Mar 8, 2022

Dialog focusing steps same origin check #5105

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Update autofocus processing algorithm #4763

Update autofocus processing algorithm #4763

tkent-google commented Jul 11, 2019 •

edited by pr-preview bot

Loading

domenic left a comment

domenic Jul 11, 2019

tkent-google Jul 12, 2019

domenic left a comment

tkent-google Jul 18, 2019

smaug---- Aug 30, 2019 •

edited

Loading

tkent-google Sep 2, 2019

tkent-google commented Jul 19, 2019

domenic Jul 22, 2019

tkent-google Jul 25, 2019

domenic Jul 29, 2019

tkent-google Aug 1, 2019

bzbarsky Aug 15, 2019

tkent-google Aug 16, 2019

bzbarsky left a comment

bzbarsky Aug 15, 2019

domenic commented Aug 21, 2019

rniwa commented Aug 21, 2019

smaug---- Aug 30, 2019

tkent-google Sep 2, 2019

tkent-google commented Sep 3, 2019

rniwa Oct 9, 2019

rniwa Oct 9, 2019

Update autofocus processing algorithm #4763

Update autofocus processing algorithm #4763

Conversation

tkent-google commented Jul 11, 2019 • edited by pr-preview bot Loading

domenic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

smaug---- Aug 30, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tkent-google commented Jul 19, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

bzbarsky left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

domenic commented Aug 21, 2019

rniwa commented Aug 21, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tkent-google commented Sep 3, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tkent-google commented Jul 11, 2019 •

edited by pr-preview bot

Loading

smaug---- Aug 30, 2019 •

edited

Loading