1505471 - (intersection-observer) intersectionRect not mapped to the document containing the target in iFrames

Status: RESOLVED FIXED

(Core :: Layout, defect, P3)

Description

[Dennis Schubert [:denschub]]

In the example at [0], an IntersectionObserver is used inside an iFrame (the jsFiddle iframe, in this case). You can observe that the intersectionRect reports something like left=846,top=517. According to the spec[1], this shouldn't be the case:

> 6. Map intersectionRect to the coordinate space of the viewport of the Document containing the target.

So I'd expect the intersectionRect to be relative to the document inside the iframe, thus reporting left=8,top=8. This works fine in Chrome, Safari, and Edge.

[0]: https://jsfiddle.net/8f9whxbk/11/
[1]: https://w3c.github.io/IntersectionObserver/#calculate-intersection-rect-algo

Comment 1

[Dennis Schubert [:denschub]]

I feel like this could have been done in bug 1359318, but I couldn't confirm this patch actually changed anything in older versions with mozregression. Since :tobytailor isn't working with us anymore, I figured it might be best just to open a new bug.

Comment 2

[Firefox Bug Husbandry Bot]

See bug 1547409. Moving webcompat whiteboard tags to project flags.

Comment 3

[wonderwhy.er]

Is there any progress or interest in fixing this? May be I can provide some additional information?
Was reported half a year ago and I have no idea if it was even noticed.
We sadly at Infogram are forced to rely on polyfill instead of using IntersectionObserver in Firefox, but it does not work for case of application embeded to 3rd party website inside iframe without a friendly script in parent page. This causes issues for our clients when they use iframe to embed our charts and expect animation to trigger when users scroll to the embed.

Just checked the fiddle example, and it still works correctly in Chrome while failing in Firefox version 66.0.5

Comment 4

[Emilio Cobos Álvarez (:emilio)]

This was never prioritized looks like, and fell off the backlog looks like.

I'll take a look, this looks like a pretty easy bug to fix.

Comment 5

[wonderwhy.er]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #4)

This was never prioritized looks like, and fell off the backlog looks like.

I'll take a look, this looks like a pretty easy bug to fix.

Ouh, ok good thing that I wrote then :)

Comment 6

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1505471 - Map intersection observer rects to the right viewport. r=mstange

targetFrame is modified during the intersection computation loop, so it's not
the viewport you want if there are scrollframes around.

The test is the same as iframe-no-root.html but with a wrapping scroller which
triggers this bug.

This code is quite subtle, so will refactor and clean it up in a followup.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Sent the simple fix here (in order to hopefully land it in 68), and a proper cleanup in bug 1551716.

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5f88dc67d75b
Map intersection observer rects to the right viewport. r=mstange

Comment 9

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/5f88dc67d75b

Comment 10

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

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

Comment 11

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged