I noticed several differences between the polyfill and native impl:

IntersectionObserverEntry.time in the spec is the elapsed time in ms since page load. Our polyfill uses Date.time()
Our polyfill triggers whenever the intersection has a change, and throttled to 10/s. The native impl only triggers when the intersection ratio cross some predefined thresholds.
As shown in the README, our polyfill also provides the initial intersection (on page load). However, the native impl only triggers when it has intersection. So it doesn't trigger if the iframe is BTF on page load.

When a listener is registered, it will be called 2x in short order. Once with the position of the ad when its iframe was created and then again with the current position.

The value window.context.initialIntersection contains the initial intersection record at the time the iframe was created.

For 1), shall we change the polyfill? Or shall we compensate to the native impl? I prefer the latter, but not sure if anyone is relying on it.
For 2), I suggest we specify a fine grained threshold array as [0. 0.05, 0.10, ..., 0.95, 1]. To make sure it gets triggered on every 5%.
For 3), we can install the IntersectionObserver on page load (no matter a listener will be registered or not. assume this is cheap), and approximate the initial intersection to the 1st intersection record if it's received within 500ms. Otherwise, the initial intersection is considered as 0. Once a listener get registered, we will send the initial record and also the previous record to mimic the "2x in short order" behavior.

Stop using IntersectionObserver polyfill in ads if native support is present #5603

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions