Forwarding scroll events to amp-iframe

[ChrisBAshton]

What's the issue?

The amp-iframe component has no way of hooking into scroll information if resizable is set. This is because it is the host page itself which is scrolled, not the iframe.

Not being able to detect scroll position means we are unable to do things in response to scroll position, e.g. animate a component when it is in view.

Whilst we could use something like IntersectionObserver to accomplish this, browser support is flaky (no Safari support on desktop or iOS).

I suggest that the amp-iframe component should forward the user's normalised scroll position to the iframe (via postMessage). By normalised, I mean the offset of the iframe element should be taken into account.

How do we reproduce the issue?

To take an extreme example, try recreating something like the International Space Station story by the BBC, which relies on knowing the user's scroll position so that the 3D model can be mapped to the right part of the story.

For more everyday use-cases, how about the iPhone X product page which animates video only when it comes into view.

Something like this would be possible inside an amp-iframe, but only if the scroll information is available.

What browsers are affected?

All browsers.

Which AMP version is affected?

All versions.

[dreamofabear]

Does amp-iframe's send-intersections feature not work for your use case?

9074 is related but I don't think we'd pass scroll events.

@ericlindley-g What was the plan again for those rich media use cases?

[ericlindley-g]

I don't know that we've gotten everyone together to chat about the next step for page -> iframe interaction yet, but in smaller chats (maybe with @aghassemi ) we were considering allowing passing throttled scroll events from the top level page into the iframe. Does this sound reasonable? I could see a couple risks:

a) scroll being considered a low-trust event, iframes could trigger major changes inside of the iframe based on this event b) I think we'll need to pick some reasonable rate to throttle the scroll events being sent to the iframe. I imagine we could get in a state where any throttling strict enough to maintain page performance would be too strict to provide a smooth interaction

Though (a) I'm not too worried about, since iframes permit so much anyway, and (b) I'm optimistic that we can find a happy medium.

What do you think? Any risks I'm missing? Of course, if it's determined that the feature is a good fit for AMP, there's the question of prioritization after that :)

As @ChrisBAshton points out, this feature in general is something that would be useful for interactive storytelling (that BBC space station article is one of the examples we were actually thinking about to motivate this feature!)

I think that send-intersections wouldn't quite be sufficient, because interactions like this often need fine-grained information about scroll position throughout their scroll-sync'd animation, rather than single messages when they enter or exit the viewport. (Though I may misunderstand the functionality that send-intersections provides, so let me know if there's more to it than that).

[aghassemi]

@zhouyx, at what rate do we send position data to 3Ps?

[aghassemi]

@ChrisBAshton @ericlindley-g My only (and big) concern with this is FPS performance. With scrollbound-animations in AMP, we guarantee that only hardware accelerated animations - which don't cause expensive browser relayouts - can run as result of scrolling. We can't guarantee that in an iframe which means janky scrollbound animations can become a thing in AMP.

[ericlindley-g]

@aghassemi — good point...

Thinking through the additional risk that this feature would introduce: janky animations are already allowed in iframes—is there additional risk introduced because it's more common to use non-hardware-accelerated animations based on scroll, or would the additional layer of listening to scroll events make it more likely to introduce jank to animations that would otherwise be OK?

[aghassemi]

It's use of non-hardware-accelerated animations based on scroll. Passing scroll data through iframes is fine (we already do that for A4A and in-a-box.)

[zhouyx]

We send position data to 3P every 100ms, which I believe is not sufficient for animation.

[ericlindley-g]

Got it—thanks for talking through this. I'm inclined to support this such that it provides the ability to sync with 60fps animations. WDYT about taking this to design review to double-check before going forward?

[aghassemi]

@ericlindley-g design review would be good, I suggest we do it closer to when we actually want to start implementing it. (which has to be after two-way messaging anyway since that's a dependency)

[aghassemi]

WebPlatform's new proposal https://github.com/WICG/scroll-animations/issues/39 is the right solution for this long term

Short term https://github.com/ampproject/amphtml/issues/9074 is closed to being unblocked by Chrome's User Activation v2 and can handle this use-case.

deduping with https://github.com/ampproject/amphtml/issues/9074