Closed Bug 2019482 Opened 6 months ago Closed 4 months ago

Failure in /css/css-scroll-snap/snap-after-relayout/multiple-aligned-targets/prefer-focused-nested-containers.html

Categories

(Core :: Layout: Scrolling and Overflow, defect, P2)

defect

Tracking

()

RESOLVED FIXED
152 Branch
Tracking Status
firefox152 --- fixed

People

(Reporter: hiro, Assigned: hiro)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

Honestly I don't quite understand what the test wants to check.

From https://searchfox.org/firefox-main/rev/2d123ef3d530f3ae52f03978fbb9fe51af44bb5e/testing/web-platform/tests/css/css-scroll-snap/snap-after-relayout/multiple-aligned-targets/prefer-focused-nested-containers.html#83-87

// This test verifies that a snap container (outer) which contains another
// snap container (inner) snaps with awareness of focus on children of the
// inner container, i.e. outer should prefer to select the snap area whose
// child has focus even if there is an intermediate snap container between
// the child and outer.

This is opposed to the model of scroll snap that I do understand. From the spec;

Snap positions only affect the nearest ancestor scroll container on the element’s containing block chain.

I don't think there is a conflict between this test and quoted line of the spec.

The quoted line of the spec is saying that an element E can be a candidate snap target of a scroll container S only if S is the nearest ancestor scroll container of E. So, in this test, for S=outercontainer, leftcontainer and rightcontainer can be candidate snap targets, but e.g. lefttarget1 cannot.

But this line of the spec is not placing any constraints on the rules to tie-break between leftcontainer and rightcontainer. So e.g. a rule could be "leftcontainer is preferred if any descendant of it is focused", and this is what the test seems to be checking.

(In reply to Botond Ballo [:botond] from comment #1)

So e.g. a rule could be "leftcontainer is preferred if any descendant of it is focused"

That said, while I don't think such a rule would conflict with anything in the scroll snap model, I think it's also true that the current Selecting between multiple aligned snap areas section does not seem to spell out such a rule.

What the section says about focused content is:

If list contains the focused box, remove all other boxes from list.

If the intent is to prefer boxes if any descendant of them is focused, I think it should rather say:

If list contains a box which is focused or has a focused descendant, remove all other boxes from list.

So I think this also needs a spec issue filed to clarify the spec text.

Add a new WPT (prefer-element-having-focused-element.html) since no
existing test covered this case. It verifies that a snap target
containing a focused non-snap element takes priority over other
aligned snap targets.

Assignee: nobody → hikezoe.birchill
Status: NEW → ASSIGNED

Per spec, snap positions only affect the nearest ancestor scroll
container, so re-snapping is normally only triggered on that container.
However, if a snap target contains the focused element, ancestor scroll
containers of that snap target may also need to re-snap.

Though the spec issue hasn't yet been resolved, I've uploaded two patches to make prefer-focused-nested-containers.html pass.

The patches in this bug have a code dependency on bug 1880436; adding a bug dependency to reflect it.

Depends on: 1880436
Pushed by hikezoe.birchill@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/378d410be40f https://hg.mozilla.org/integration/autoland/rev/148a8757aad1 Prefer snap target that contains the focused element when multiple targets are aligned. r=botond https://github.com/mozilla-firefox/firefox/commit/709b884469eb https://hg.mozilla.org/integration/autoland/rev/06751e224307 Post pending re-snap on ancestor scroll containers when focused content is inside a nested scroll container snap target. r=botond

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/59881 for changes under testing/web-platform/tests

Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED
Target Milestone: --- → 152 Branch

Upstream PR merged by moz-wptsync-bot

QA Whiteboard: [qa-triage-done-c153/b152]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: