Forwarding scroll events to amp-iframe

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.

[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]

@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)