Should Device Posture API be exposed to iframes (JS or CSS)

[darktears]

One question I have is the value of exposing the posture to iframes. I'll be happy to hear use cases where it could be useful.

In Chromium right now, Device Posture CSS MQs and JS API are exposed to iframes. Viewport Segments are exposed to iframe through CSS MQs (and working), but the JS APIs (visual viewport segments property) is defined but returns null.

In most cases the embedder will react to the posture/viewport segments changes and move the iframe around (for example to avoid the iframe being in the fold).

I'm not sure the iframe itself needs all the information. For example, in Chromium, the viewport segments are not recalculated relatively to the iframe coordinate space, so the values make little sense. The only use case I can think of is if the iframe is basically the size of the viewport and then all of the data make sense.

Thoughts?

[reillyeon]

It seems like it would only make sense if we could translate the viewport segment coordinates into the iframe's coordinate space. The use cases would essentially be so that an iframe which straddled a viewport boundary could observe that boundary and lay its content out around it.

I would be concerned however if this ends up exposing more information about the position of an iframe in its parent document than is currently available.

[kenchris]

I think this could be useful for iframes embedding games and emulators. Can such iframes, in collab with embedder go fullscreen? In fullscreen there shouldn't be any additional data from enabling this

[darktears]

It seems like it would only make sense if we could translate the viewport segment coordinates into the iframe's coordinate space. The use cases would essentially be so that an iframe which straddled a viewport boundary could observe that boundary and lay its content out around it.

Right but we're going to increase the implementation complexity by a lot. Viewport Segments are basically updated when the posture changes or when the viewport configuration changes (resize, orientation change etc) that's it. Now we would have to recompute the iframe relative segments for anything that happens to the iframe itself like position change, geometry changes, etc. Is it worth it? Not sure, I'd like developers to come up with use cases. I'm planning a Chrome Origin Trial for these APIs so it's a good moment to ask the needs.

I would be concerned however if this ends up exposing more information about the position of an iframe in its parent document than is currently available.

Can an iframe figure out its position relative to the embedder, in viewport coordinates? If so, we're not adding much, segments given to the page are basically a logical division of the main frame viewport.

[Psychpsyo]

I think this could be useful for iframes embedding games and emulators.

I agree since I have a game that I'm developing where the main game is inside an iframe that covers the whole page while the embedding document is the main menu/lobby system that players use to connect.
So I'd appreciate it if these APIs worked at least in the case where the iframe is the size of the whole page.

[tomayac]

+1 for the games use case. Google's own Gamesnacks uses iframes:

[anssiko]

@Psychpsyo @tomayac thanks for sharing this use case input. @Psychpsyo could you share a snippet of your relevant code (e.g. in a gist) to help figure out a design that'd address your requirements?

@darktears, is there a workaround with CSS primitives for the use cases presented based on what you see?

I wouldn't block the planned initial spec CR publication #146 on this issue given the implied implementation complexity, but use the first OT as an opportunity to gather more similar feedback. Once we have that feedback from real users, we can iterate on the spec also while at CR.

[darktears]

@anssiko I'm not sure what you mean. CSS and JS APIs are already accessible in iframes today in Chromium. When I opened the bug I was asking if they should be and if they were would they need to be behind some permission policy (which would at the moment apply only to JS APIs since they're isn't prior art on CSS features behind gated in iframes). The use cases here are already covered today.

[anssiko]

Thanks for the clarification. The use cases shared here are reasonable and it does not help to restrict the JS API if the same information is exposed through CSS.

Btw. I think we can drop this inline spec reference: #162

[Psychpsyo]

@Psychpsyo @tomayac thanks for sharing this use case input. @Psychpsyo could you share a snippet of your relevant code (e.g. in a gist) to help figure out a design that'd address your requirements?

I don't currently use this API inside the iframe (yet) so I can't give any exact code for that, but my iframe is embedded like this:

<style>
body {
  overflow: hidden;
}
#gameFrame {
  display: block;
  border: none;
  width: 100vw;
  height: 100vh;
}
</style>
<body>
  <iframe id="gameFrame" scrolling="no" src="about:blank"></iframe>
</body>

So it just permanently covers the entirety of a non-scrolling page. (until I set it to visibility: hidden)

The page is put into the iframe via
gameFrame.contentWindow.location.replace(location.href.substring(0, location.href.lastIndexOf("/")) + "/game/index.html");
so it is also always on the same origin, if that matters.

Overall, I expect it to largely work as if it were the top level page. (with regards to css and js)

[anssiko]

Thank you @Psychpsyo for the code example. @darktears should be able to confirm that your use case is addressed.

If you're planning to make your project public and you're interested in integrating with this API, we'd like to help you sign up for the upcoming Origin Trial so that your project can be one of the first to try the API out with real users. @darktears, let's set a reminder to drop the OT instructions also here when launched.

[darktears]

@Psychpsyo your use case will work today. There are no restrictions in place in Chromium to expose the device posture to iframes. We do not have restrictions in the spec as well.

@anssiko the OT has been launched for months. https://developer.chrome.com/blog/foldable-apis-ot

[Psychpsyo]

If you're planning to make your project public and you're interested in integrating with this API, we'd like to help you sign up for the upcoming Origin Trial so that your project can be one of the first to try the API out with real users. @darktears, let's set a reminder to drop the OT instructions also here when launched.

My project is already public and I am interested in integrating with this API but I'm not interested in the origin trial much, sorry.
(too much effort given that I'm mainly integrating the API out of curiosity and my user base is tiny)

[anssiko]

@Psychpsyo actually the most helpful feedback often comes from indie developers, enthusiasts like yourself, not big names. So thanks for sharing your project with us!

You’re probably happy to hear that we’re now in fact looking to launch the API turned on by default, without going through another trial.