Hadley: We've discussed in the past that this is similar to other features, like kiosk mode. But this is for launching a pop-up in fullscreen on a separate screen.

...My privacy/spoofing concerns were that someone could use to spoof, on a second screen, a different site, including the URL bar. But they have put this behind a permission prompt, and have thought through a similar scenario (that a site is spoofing part of the user's operating system desktop instead).

...This functionality already exists through several steps, and they're using this to collapse it down to one. Reduces developer complexity, which is a win.

Hadley: specific to a separate display... behind a perimssiom prompt is helpful. Overall functionality exists through several steps already - they're colapsing down to one step. Helps with developer complexity. Builds on APIs from second screen wg ...

Rossen: We talked about this .. at the time we discussed simplification of existing functionaltiy - we asked why not just extend window.open. On spoofing my main concern is opening transparent windows and doing bad things... user consent is fine ... i'm worried that prompt exhaustion leads to always-open behaviour...

Hadley: it is building on window.open - they are adding a boolean "fullscreen".

Dan: multi-stakeholder?

Hadley: it's in a working group - so multistakeholder as a working group - work done by google and intel. We can ask...

Mozilla standards position

Webkit standards position

Dan: leaves comment

Amy: last comment from Hadley was that we can close it. It's been proposed close since last week

Yves: needs accessibility review... it's resolution no comment because we don't know if it's ther ight solution - we want the wg to do its work and come back when they have the right solution. We can close at plenary.

Hadley: we were unclear whether this reflected consensus of the 2nd screen wg... that nudged the poster to seek that consensus -- they planned to discuss at tpac. we haven't heard any update. i left a nudge to clarify - it would be good to understand whether this was the wg's consensus...

Hadley: I was concerned we not spend too much time if this is one proposal among many in the WG, which seems to be the case

Dan: it seems like some of the feedback we've raised could benefit from hearing what happens with the origin trial. Should we just say that?

Hadley: never a bad thing to have more information, but how much do we want to invest in something that the WG hasn't selected?

Amy: it'd benefit everyone if there are multiple proposals for them to explain to us what the sticking points for consenus are and see if we have architectural advice, rather than us just looking at one proposal at a time with nothing to compare it to

Dan: do we have this because it's part of the Blink process?

Peter: OT information should feed into the TAG

Matthew: +1 to the idea of seeing what the lay of the land is if there are multiple proposals, so we're looking at them together (or the differences). Expecting some non-zero likelihood that focus management is going to come into this. There isn't specific mention of focus management or accessibility int he explainer. Not sure if it's because it's the same as the normal fullscreen api. Seems like it's worth them being more explicit about any accessibility concerns in the explainers.

Peter: small concern about their api, but not sure if we should give them feedback without looking at other options. Their example, you have to pass in the four coordinates of the other screen.. seems redundant. A window in fullscreen mode vs a window taking up the entire screen? pass identifier screen not coordinates - not sure if there is an identifier.

Matthew: sounds like the coordinates are optional?

Peter: coordinates to target a different screen... if they have a label why can't I just say fullscreen on screen with this label

Matthew: Agree. Says they could also include window bounds features. Implies its optional but not explicit

Peter: their example shows using all the coordinates to target screen. Not thrilled with feature detection.

Thanks for the reply, @Anssiko. Are there alternative proposals for similar functionality that the WG is also considering? Is there is a particular architectural question we can help with, or are you having trouble achieving consensus in a way that we can help with?

At this stage, we would recommend that, as a working group, you all work towards consensus and come back to us when you have a single proposal for us to review.

Having said all that, we have looked at what you are proposing here and are recording a couple of thoughts as well.

We noticed that there isn't specific mention of focus management or accessibility in the explainer. Can you make accessibility considerations explicit in the explainer / spec?

Another specific question that came up in our discussion: do you require passing in 4 coordinates of the other screen when targeting a different screen? Passing a screen's label may have better developer ergonomics.

Considering the early stage here, we don't think it's appropriate to give a final review at this time. You can re-open the issue if you have any specific questions, or feel free to open a new issue if the proposal changes significantly.

proposed close