1800868 - wpt failure in css/css-contain/content-visibility/content-visibility-064.html due to elem.focus() undershooting scroll position for an element in a skipped subtree

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Martin Robinson (email:[e-mail])]

Focus determines content relevancy for content-visibility, but this can be affected by whether or not the window is active. When running WPT a test [1] because the window is not considered active when the scrollIntoView() part of the focus() call happens. This bug tracks deciding what to do about this failing test.

1. css/css-contain/content-visibility/content-visibility-064.html

Comment 1

[Daniel Holbert [:dholbert]]

Note: https://wpt.fyi/results/css/css-contain/content-visibility/content-visibility-064.html currently shows us passing this test, but I think that's just because content-visibility isn't enabled by default yet, and the test spuriously passes when content-visibility isn't supported. So the wpt.fyi test infrastructure is just reporting that spurious pass.

I do see that we have it annotated as expected-fail for our own CI testing (where we enable it during testing):
https://searchfox.org/mozilla-central/source/testing/web-platform/meta/css/css-contain/content-visibility/content-visibility-064.html.ini

So this is presumably still an issue.

--> Marking as blocking interop-2023-contain since this WPT is tracked there.

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #1)

Note: https://wpt.fyi/results/css/css-contain/content-visibility/content-visibility-064.html currently shows us passing this test, but I think that's just because content-visibility isn't enabled by default yet, and the test spuriously passes when content-visibility isn't supported.

Update: now we've got content-visibility enabled on Nightly, and this test does indeed fail now (and is reported as such on wpt.fyi for Nightly).

I think the diagnosis in comment 0 here may be off, though; this doesn't seem related to whether the window is active or not. The test failure screenshot (and the behavior I see locally) is that we scroll nearly enough but not quite far enough to see the focused element.

This is almost the same issue as in bug 1797467 -- the focused (i.e. scrolled-to) element is at the bottom of a container-div that skips its contents; and when we focus it & try to scroll to get it onscreen, we undershoot our calculation of the required scroll-distance, due to the fact that the container's contain-intrinsic-size is substantially smaller than its actual content-shrinkwrapping size.

In this case, though, the spec text makes it clear that the test is correct & our implementation is wrong:

6. If an element with content-visibility: auto that is skipping its contents is focused (or its contents are), it becomes relevant to the user (and thus stops skipping its contents) before it is scrolled into view due to the focusing.

https://drafts.csswg.org/css-contain-2/#cv-notes

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #2)

I think the diagnosis in comment 0 here may be off, though; this doesn't seem related to whether the window is active or not. The test failure screenshot (and the behavior I see locally) is that we scroll nearly enough but not quite far enough to see the focused element.

I should say: it's possible that there's also a window-active-status issue that prevents the test from passing in Firefox's CI. If that's the case, we should just flag the test as needs-focus, whatever the right way to do that is for WPT tests. (I don't know offhand, but we do have needs-focus in reftest.list for this sort of thing. I'm not immediately seeing an equivalent in WPT .ini files; maybe WPTs just always run in a focused mode and the focus issue here was an inadvertent side issue from a local test run that happened to lack focus by accident?)

Anyway: if there are indeed window-needs-to-be-explicitly-granted-focus issues that still contribute to our test-failure in CI, that's likely straightforward to address with some sort of annotation. But I think comment 2 describes the sole reason for the failure that's screenshotted on wpt.fyi , which is the more-important real issue that the test failure is revealing here.

--> updating bug summary to focus on comment 2 diagnosis.

Comment 4

[Frédéric Wang]

I would close this for the same reason as stated on bug 1797467 comment 2.

Comment 5

[cathiechen]

Tested locally on Mac, it is passing. Let's close this one.