@jar...@chromium.org - PTAL, do you have an idea who would be a good reviewer?
thanks in advance, and no time pressure from my end, whenver you have a couple of minutes. thanks!
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
// 5) Navigating back to |url_1|, we shouldn't restore the focus to theDo you know why we were testing for the opposite behaviour? Does the HTML spec have an opinion on this?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
already seems to test the same thing (at least by its description). It's also failing on Firefox, so I wonder if there is consensus on the behaviour.
// 5) Navigating back to |url_1|, we shouldn't restore the focus to theDo you know why we were testing for the opposite behaviour? Does the HTML spec have an opinion on this?
The opposite expectation (`blurCount == 1`) was added in 2020 by https://crrev.com/c/2362046, intentionally clearing focus + text-input state on BFCache entry so the IME / text-input plumbing matched a normal cross-document navigation. The test was just locking in that implementation choice; not a spec requirement.
already seems to test the same thing (at least by its description). It's also failing on Firefox, so I wonder if there is consensus on the behaviour.
Acknowledged, dropped `third_party/blink/web_tests/http/tests/back-forward-cache/focus-preserved.html`.
On consensus: Safari already preserves focus across BFCache, so this CL aligns Chromium with WebKit. Firefox is the other outlier then. The HTML spec is silent about it (`reactivate a Document` says nothing about focus).
I'm happy to file a spec issue to make this explicit. Want me to file it as a follow-up to this CL, or block on it?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Helmut Januschkaalready seems to test the same thing (at least by its description). It's also failing on Firefox, so I wonder if there is consensus on the behaviour.
Acknowledged, dropped `third_party/blink/web_tests/http/tests/back-forward-cache/focus-preserved.html`.
On consensus: Safari already preserves focus across BFCache, so this CL aligns Chromium with WebKit. Firefox is the other outlier then. The HTML spec is silent about it (`reactivate a Document` says nothing about focus).
I'm happy to file a spec issue to make this explicit. Want me to file it as a follow-up to this CL, or block on it?
Unfortunately, I think we should block. The focus behaviour was added very intentionally.
and there's a real question as to what the correct behaviour should be. There's a tension with BFCache between making it seem exactly like a normal navigation just faster and the fact that web pages are stateful and we are restoring that state.
I'm also hesistant to change focus stuff. I know we already have a mess because input events are not on the same mojo pipe as RFH and other navigation events, including focus. I feel like this has been a source of flakiness, although it was quite a while ago.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |