Early design review of the **updated** Multi-Screen Window Placement API

[michaelwasserman]

HIQaH! QaH! TAG!

I'm requesting a TAG review of the updated Multi-Screen Window Placement API.

This proposal introduces incremental improvements to existing screen information and window placement APIs, allowing web applications to be intentional about the experiences they offer to users of multi-screen devices. The API shape has been updated since our last TAG review with feedback from partners and web platform API experts (example).

• Explainer: https://github.com/webscreens/window-placement/blob/master/EXPLAINER.md
• Changes since the last TAG review: https://github.com/webscreens/window-placement/blob/master/CHANGES.md
• Security and Privacy self-review: https://github.com/webscreens/window-placement/blob/master/security_and_privacy.md
• GitHub repo: https://github.com/webscreens/window-placement
• Primary contacts:
  • @michaelwasserman: Google, Chromium implementer, editor
  • @webscreens: W3C Second Screen Community Group (incubation group)
• Organization/project driving the design: Google/Chromium & W3C Second Screen Community Group
• External status/issue trackers for this feature: Chrome Status and Chrome Feature Issue

Further details:

• I have reviewed the TAG's API Design Principles
• The group where the incubation/design work on this is being done: W3C Second Screen Community Group
• The group where standardization of this work is intended to be done: W3C Second Screen Work Group (maybe?)
• Existing major pieces of multi-stakeholder review or discussion of this design: Prior TAG review, (API design discussion), W3C Second Screen CG's Form Factors Explained report.
• Major unresolved issues with or opposition to this design: None
• This work is being funded by: Google

We'd prefer the TAG provide feedback as (please delete all but the desired option):
💬 leave review feedback as a comment in this issue and @-notify @michaelwasserman

Thank you!

[tomayac]

• Explainer: https://github.com/webscreens/window-placement/blob/master/EXPLAINER.md
• Changes since the last TAG review: https://github.com/webscreens/window-placement/blob/master/EXPLAINER.md

This looks like a copy & paste glitch. The changes are mentioned in CHANGES.md.

[michaelwasserman]

Thanks for catching that, @tomayac! I updated the initial comment above.

[kenchris]

I find Promise<Screens> getScreens(); a bit confusing due to .screens property. It can lead devs to write code like

screens.screens.length and even the examples use screensInterface.screens.length in order to avoid saying screens twice. Maybe we should just call it ScreenInfo or similar, like Promise<ScreenInfo> getScreens() - naming is hard.

I was also thinking about something like "ScreenDevices", but I still hope we can find a better name

[plinss]

I'm wondering if it would help developer ergonomics to also allow an optional screen argument to the Window.moveTo() method, which if passed, makes the x, y coordinates relative to the passed screen. If added, a similar mechanism should be added to Window.open() (perhaps changing the features argument from a string to an object).

[quisquous]

I find Promise<Screens> getScreens(); a bit confusing due to .screens property.

We have that filed on w3c/window-management#50 as a place to discuss. As you say, naming is really hard. I don't think anybody has come up with a better name yet and so we've been punting on that so far.

I'm wondering if it would help developer ergonomics to also allow an optional screen argument to the Window.moveTo() method, which if passed, makes the x, y coordinates relative to the passed screen. If added, a similar mechanism should be added to Window.open() (perhaps changing the features argument from a string to an object).

I worry that it might be confusing to have the coordinates change their semantics if an optional third parameter is present. I wonder if it might be better to pick one of (a) x and y are relative with optional screen or (b) x and y are absolute, no screen parameter.

[torgo]

@michaelwasserman Just reviewing this in the context of our virtual f2f. Appreciate what you've written here about fingerprinting mitigation.

[michaelwasserman]

Thanks for the comments and feedback, @kenchris, @plinss, and @torgo. Thanks for the reply, @quisquous.

@kenchris: we're open to naming feedback on w3c/window-management#50 and I added a comment there, but we haven't necessarily found a more compelling pattern than our current proposal.

@plinss: I hope we'll continue improving the state of window placement on the web with future proposals, perhaps with something akin to your suggestion, and nothing in this proposal precludes such future work. Perhaps developer ergonomics would be served best by moving away from disparate moveTo(), resizeTo(), etc. functions, and adding a new function that can set a bounds rectangle, and potentially related window placement state (e.g. maximized/zoomed, left-/right-snapped, etc.) in a single request. That could support either global cross-screen coordinates and/or screen-relative coordinates (with an optional screen parameter, or a default assumption of relative placement within the current screen). There's a lot to consider, and this proposal aims to start small, but I have some thoughts in the repo's additional_explorations.md and aim to continue exploring.

Is there any other feedback from TAG members that we can consider during this early design review? Thanks again!

[atanassov]

@kenchris and I did another pass at this review during our Gethen vf2f. Thank you for addressing our earlier feedback about API naming and developer ergonomics. In particular we prefer the getScreenDetails name over getScreens especially in combination of getScreenDetails().screens. Further, the detailed exploration document you linked to goes into great details on how to make the API better and since this is an early design review we hope this will be taken into consideration for the final API shape.

At this point we are happy to close the review as satisfied and look forward to the progress you'll make. Thank you and good luck.

[torgo]

@michaelwasserman when we closed this issue last year we indicated a concern related to multi-stakeholder. I note that the API is still being developed in the Second Screen Community group and Chrome Status does not list any other engine that has expressed interest. Has this moved in any way towards the Second Screen working group and has there been any interest expressed by other implementers?

[atanassov]

One more question is about security and privacy - I can't find a relevant write up about it and was wondering if you're assumption is that the current questionnaire answers cover the newly added functionality too?

[michaelwasserman]

Thanks for these inquiries!

@torgo: The API was adopted as a Second Screen Working Group deliverable, see the latest charter and CfC to publish a FPWD. We are getting valuable feedback from Mozilla, which just continued at a recent SS WG vF2F, but have no explicit positive signals from another implementer.

@atanassov: The proposal includes mitigations to limit the potential for accidental misuse or abuse. The spec was recently updated per Mozilla's enhancement feedback, to clarify Security Considerations around deceptive cross-screen placement. The API's questionnaire generally covers this minor enhancement, but the Spec and Explainer more directly address the pertinent considerations of this change.

[atanassov]

Hi @michaelwasserman – @torgo and I are just reviewing this at our f2f. It looks like the issue raised by @annevk hasn't been adequately addressed. That seems to be a pretty common use case (where a malicious site might seek to take over a display and mimic the user's OS (or similar) in order to steal credentials. Also as we've been reviewing it seems to us like this is more than a small enhancement. This proposal extends several technologies that are not part of multiscreen: user activation, Element.requestFullScreen and window.open. Since the scope is a bit wider than a small enhancement on an existing API. Can we ask that you to fork the topic and file a new design review request for this?

[torgo]

Just marking this as pending editor update for now - we will close when additional issues have been filed.

[michaelwasserman]

Thank you, @atanassov and @torgo! Please see the newly opened TAG review request and the Explainer's new Security Considerations, which documents and attempts to address the concerns raisied by @annevk; I also replied directly to that Mozilla standards-position thread. Thank you for your time and patience!

[torgo]

We're closing this as the review has moved to #767.