IntersectionObserver does not work in out-of-process iframes
Categories
(Core :: Layout, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox75 | --- | fixed |
People
(Reporter: mconley, Assigned: hiro)
References
(Blocks 1 open bug)
Details
Attachments
(4 files, 1 obsolete file)
STR:
- Visit https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API#Thresholds
- Scroll down to the iframe hosting the thresholds demo (orange boxes with numbers in them)
- Scroll that subframe.
ER:
The numbers should change as the intersection amount changes while scrolling.
AR:
The numbers stay at 0%.
Note that IntersectionObserver works properly in the top-most frame - see https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API#Thresholds
|
||
Updated•5 years ago
|
|
||
Comment 3•5 years ago
|
||
That works for me now with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:74.0) Gecko/20100101 Firefox/74.0 ID:20200123115437.
Maybe bug 1608931 helped here which was also about crossing boundaries between the framescript and web content?
Mike, can you still reproduce?
|
Assignee | |
Comment 4•5 years ago
|
||
I believe this is still an issue in fission world.
|
||
Comment 5•5 years ago
|
||
Hiro — As part of the work on this, do you believe it might help resolve bug 1602987? That is, if we need to pass the offset to the top of the OOP iframe down to the content process in order for IntersectionObserver to work correctly, I wonder if we can also use the same data to solve the a11y problem of getting abs coordinates in the content process.
Emilio — Correct me if I'm wrong here :) But I believe this was generally what was discussed at the All Hands.
|
|
Assignee | |
Comment 7•5 years ago
|
||
If bug 1602987 needs positions in browser window coordinate system, BrowserChild::GetChildToParentConversionMatix is the way. If we need positions in the top level content document coordinate system, we need to subtract browser toolbar height, it's probably BrowserChild::mChromeOffset, that's said as far as I know in OOP iframe the mChromeOffset is zero, so we probably need to propagate it into OOP.
Anyways, it seems to me we already have enough information for bug 1602987.
CCing Jamie, for references.
|
|
Assignee | |
Comment 8•5 years ago
|
||
The ChildToParentConversionMatrix and the RemoteDocumentRect came from APZ
contain transformation of the offset from the embedder iframe, i.e, CSS padding
and border values for the iframe element. We need to offset the remote document
rect by this position to get correct intersection region for
IntersectionObserver in out-of-process iframes.
|
|
Assignee | |
Comment 9•5 years ago
|
||
In out-of-process iframes, the refresh driver for the iframe process doesn't
trigger the UpdateIntersectionObservation function in cases where ancestor
document's viewports change because there is no way to know it happens inside
the iframe process. So instead, we trigger the function in
BrowserChild::RecvChildToParentMatrix which is called in response to APZ.
Depends on D61936
|
|
Assignee | |
Comment 10•5 years ago
|
||
Depends on D61937
|
||
Updated•5 years ago
|
|
|
Assignee | |
Comment 11•5 years ago
|
||
|
|
Assignee | |
Comment 12•5 years ago
|
||
What we really needed in the first place was the size not the rect.
|
|
||
Updated•5 years ago
|
|
||
Comment 13•5 years ago
|
||
|
||
Comment 16•5 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/9a08329f60d4
https://hg.mozilla.org/mozilla-central/rev/ed241344c391
https://hg.mozilla.org/mozilla-central/rev/3985a60a75b3
https://hg.mozilla.org/mozilla-central/rev/b8ad0267e88a
|
||
Comment 18•5 years ago
|
||
== Change summary for alert #24911 (as of Wed, 12 Feb 2020 00:02:20 GMT) ==
Improvements:
9% perf_reftest_singletons link-style-cache-1.html windows7-32-shippable opt e10s stylo 682.83 -> 622.56
3% tp5o_scroll linux64-shippable opt e10s stylo 1.18 -> 1.15
For up to date results, see: https://treeherder.mozilla.org/perf.html#/alerts?id=24911
Description
•