#602: Early design review of the **updated** Multi-Screen Window Placement API
Discussions
2021-03-08
Ken: has encorporated feedback from me and Jake Archibald. so that's good. Seems sensible. One thing now is that when youc call getscreens
you get a screens
object ... could be a naming issue... screens.screens
... An earlier version of this implementedis what is in the spec today. They are incorporating this into a new explainer - it's not spec'ed.
Dan: should we try to close this?
Ken: I'm concerned it might ship if we don't provide our feedback...
Ken: I think this is pretty good - they are going through and origin trial to get more feedback.
Dan: security and privacy? I can review.
Rossen: where does end up? what spec?
Dan: second screen working group ... is what's indicated. Is there multi stakeholder support?
Ken: will leave naming feedback.
Peter: somee thoughts - aware of work on foldable screens... Intending to harmonize. My concern is that someone ships part of this before rest is baked and we end up with multiple multi-screen APIs...
Ken: I think we're pretty aware... they want to make sure this fits together...
Peter: it's a meta-concern.
Peter: my other concern - takes all the screens and puts them into one virtual coodinate space - does that have the best developer ergonomics? Should we be able to target a specific screen object?
Ken: 3 TVs as a big canvas... [as a use case]
Peter: in some cases a developer will want to taget a window a specific screen - and with this approach you have to do the math to figure that out.
Rossen: in the other case where we consider screen-local coordinates - you still have to do the math... however you look at it you have to do math.
Ken: unless you want to do something on a specific screen full screen, which could be a common use case.
Rossen: requestfullscreen
...
Peter: but you're not always gonna want full screen. Just a question of convenience for developers.
Rossen: i'd like to see how other platforms are handling this...
Dan: worth asking the question on the issue...
Peter: will do.
Peter: changing behaviour of how it works today.. breaking exisitng implementation
Peter: my proposal is to add an optional parameter - move to x,y (& this screen). And also wondering how moveto
works today in a multi-screen setup.
Rossen: pretty sure you have a canvas (across) both windows... could be platform specific.
Rossen: in windows we draw the distinction between displays and screens... multiple displays that you can enumerate...
Dan: point on developer ergonomics is good. Web doesn't necessarily want to map platform features into identical js apis. Wants to make sense for web devs.
2021-05-Arakeen
Ken: ... some changes with this....
[reviewing]
Dan: there's lots of fingerprinting info exposed as document in their answers to the s&p questionnaire. Is any of this mitigated against e.g. via a permission request? this would seem to indicate that access to this kind of data is limited behind a permission.
2021-08-30
Dan: I think this is ready for closure based on the feedback we got on the 10th, unless there's additional feedback we want to give. I did put the multi stakeholder thing in here. We could say it remains an issue/question.
Rossen: added some docs to issues around naming and use cases... there's quite a bit of content... looks like the issue they link to - https://github.com/webscreens/window-placement/issues/50 trying to figure out if they're ok with our proposed renaming. The current name is window.getscreens.screens
... we flagged. I don't see that they are ready to change it....
Peter: new explainer says getscreens
is directly on window.
Dan: have they taken our feedback on board and are debating it, or have not really understood our feedback?
Peter's cat: MAAAAW
Rossen: it seems like they are sympathetic to the proposal.
Dan: could be an argument for closing
Rossen: let me touch base with Ken first. I remember a long discussion about this one with Peter and we went through all of the apis
Dan: plenary, proposed closed
2022-06-13
Peter: ..
Dan: popping up multiple windows can be a way that bad actors try to confuse the user by ocluding bits of browser ui, making it hard for them to get back to what they were doing... but is this only in a multi screen scenario..?
Peter: when you have window placement permission already. And you've got an activation so you can place fullscreen content. And what youc an now do is let you place popups on other screens. So you won't get 100 popoups all of a sudden, but you could go to fullscreen mode and get popups on other screens. That may be what you want in some scenarios, but share the concern.. can it be abused by.. not always fullscreen on the most ethical sites.
Dan: I'd like to unerstand if they';ve really thought about the abuse scenarios
Peter: they list mitgations in the explainer
Dan: are they considering browsers on keyboardless devices? They talk about esc key for instance. Not available to everybody. Are we clutching at straws? Minor change.
Dan: minor change.. should we just close?
Peter: I'm ok to close it I guess. I do have concerns about how badly it can be abused...
Dan: Proposed comment on multi-stakeholder:
@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?
Rossen: Looks different from the initial ... Now... The way I see this is that this is generally reducing friction.. not enabling something that is not possible. Question is: is that friction really that bad?
Peter: how can it be abused? To me the abuse could be "i am on e.g. instagram, i press full screen, i get ads popping up on all my other screens full-screen".
Rossen: If I have an app that is a fullscreen app and I launch another app that is also full screen the first app may or may not exit full screen. With multi-screen.. with modern window management capability - i can separate by sections... launch one of those apps and my screen layout will not change on the 2ndary screen unintentionally... I don't see where they address privacy & tracking... Taking over screens, especially multiple screens, could...
Dan: I don't think they specifically address that in mitigations. They're not talking about privacy and tracking
Rossen: trying to see if they cover it somewhere else
Dan: indicated they're interested in moving it to the second screen wg, so want to ask about that. Would make sense for someone else to ask about the abuse scenarios?
Rossen: I want to expand the comment about privacy and abuse. Does it need to be part of this review or fork off to a different review? it's very related but it's an extension.. why are they reopining the same issue
Peter: could have been a new review request
Rossen: if we ask them to open a separate issue they'll have to go through multistakeholder etc again
Peter: we dont' need to religitate everything we already reviewed. Fair to push them on multistakeholder because that's left over.
Dan: I can also post about abuse.. but I think Rossen had it more in his head
2022-07-London
Dan: reviewing response on our concerns it seems to address our issues
Rossen: reviewing Mozilla's standards position... The issue with taking over a monitor that users doesn't pay attention to is not as fringe as it's being presented. Often, people use laptops with a large screen monitor (at the office for example) and aren't paying any attention to the main, laptop's screen.
Rossen: leaves comment
2022-08-29
Tess: prefer to close it when they actually file the follow-up.
Dan: added note to clarify status but left open
2022-11-28
Dan: can this be closed? They've pointed us to a new review, #767
Peter: looking at the difference between the two... is 767 looking at only a specific part of this spec? They have a separate explainer.
Dan: last feedback from Rossen about specific issues. New review request was in response - attempts to address concerns. Either this is a replacement, or ..
Peter: we had closed it in 2021 and they reopened it to ask us to look at multi screen part. 602 changed.. I believe we can close 602 now and move on with 767
OpenedJan 26, 2021
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).
Further details:
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!