Adding kenrb@ and lfg@, who can help answer whether this is already possible or what needs to be done if not.

Ken or Daniel, is this something that makes sense?  It looks like a FrameView can only be created for a LocalFrame.  Maybe there's some other way to get the properties needed, like whether it can scroll horizontally.

IIRC, we already replicate some things about the viewport across processes, maybe this would fall into that category of stuff?

The only thing I am aware of is that, when the main frame is remote, the page size is known in the Page's VisualViewport. AFAIK this is only set because if the main frame gets swapped in, it needs that size information. I don't know if this is sufficient for you needs.

The general expectation is that layout of frames is independent from layout of a containing frame, except for determining the size of the iframe.

To that end, I'm not sure I quite understand the problem. Why is it not sufficient to set the width of the media controls to the width of the containing frame? If you set the width to the visible viewport, but the frame is smaller, don't the controls get clipped anyway?

Note also that replicating the page's visual viewport is necessary for some fullscreen bits to work in OOPIFs: see https://codereview.chromium.org/1834913002/.  

kenrb@, the issue is that if the frame has a width of say 500px with a <video> of 500px inside but the top frame has a viewport width of 450px without horizontal scrollbar, it will not possible to interact with 50px of the <video> inside the frame but the frame itself can't know that unless it's aware it is embedded inside a 450px top frame without horizontal scrolling.

Why would we special case this? In general, if an author puts content into a frame that's too small to display all of it and makes the frame unscrollable we respect their intent. Why is video special?

In any case, what you're referring to isn't the visual viewport. The visual viewport differs from the main FrameView in size only for transient events like pinch-zoom (most commonly) and (soon) on-screen keyboards. We shouldn't change layout/painting of a page in response to these. 

mlamouri: I have a CL in progress that implements IntersectionObserver for OOPIFs, allowing the frame to know how much of it intersects with the top-level viewport. It sounds like that might give you what you want.

https://codereview.chromium.org/2431473003/