This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16502 - Define multiple monitor support and per-subdomain
Summary: Define multiple monitor support and per-subdomain
Status: RESOLVED MOVED
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: Fullscreen (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-03-24 01:55 UTC by Sirisian
Modified: 2015-07-28 07:31 UTC (History)
8 users (show)

See Also:


Attachments

Description Sirisian 2012-03-24 01:55:08 UTC
Currently the specification doesn't explain how browsers should attempt to handle fullscreen across multiple monitors. This has led to implementations simply releasing fullscreen or hiding a toggleable feature in their configuration files to allow a webpage to preserve fullscreen.

A common use case is someone watching a video on one screen while working on another screen. The expected scenario would be the user clicks on the other screen removing focus. Now since the program has lost focus a security box - in Firefox and Chrome, a yellow box - should display which asks the user if they want to allow the page to stay in fullscreen.

I'd recommend putting a non-normative recommendations regarding this behavior. The pointer lock handles this cleanly in their spec with the comment:
"Preferences per sub-domain can be used to allow or block pointer lock, similar to pop-up, geolocation, and fullscreen."
- http://dvcs.w3.org/hg/pointerlock/raw-file/default/index.html

So this would be a per subdomain preference that most browsers would be expected to implement for convenience. Currently for a normal user having to go into the configuration to change a fullscreen preference just for watching a video in another window is foreign to them. This change would greatly simplify this for the common user without introducing any security problems.
Comment 1 Anne 2012-04-05 14:04:08 UTC
Anyone any opinions here? Sirisian, what exactly are you suggesting the standard should say?
Comment 2 Edward O'Connor 2012-04-05 16:59:58 UTC
This strikes me as something platform-dependent.
Comment 3 Sirisian 2012-04-05 18:32:30 UTC
(In reply to comment #1)
> Anyone any opinions here? Sirisian, what exactly are you suggesting the
> standard should say?

Below the section:
"7 Security and Privacy Considerations"
Put:
------
8 Multiple Monitor Non-Normative Recommendations
When using multiple monitors a user agent will often lose focus. When in fullscreen this means exiting fullscreen. User agents are encouraged to implement a global preference that would allow the user agent to persist in fullscreen. The user agent would prompt the user with a confirmation dialog about staying in fullscreen when losing focus, with options to permit, dismiss, or block all repeated attempts.
------
That's it. I basically took all the wording from the pointer lock specification. Also I removed the per-subdomain since for fullscreen it's unnecessary. Most people will understand if their user agent loses focus and their prompted to stay in fullscreen what is happening.

(In reply to comment #2)
> This strikes me as something platform-dependent.

Very much so. Most operating systems though don't allow more than one window to be in focus at a time. It's a non-normative recommendation so that implementers do something for this case instead of dropping out of fullscreen with no way of staying in fullscreen. This is a problem in most browsers currently that implement fullscreen. It's much easier to say "why don't you implement this in the spec" for people using multiple monitors than it is to try to argue each case.
Comment 4 Robert O'Callahan (Mozilla) 2012-04-05 20:33:32 UTC
I don't think this needs to be covered in the spec. It shouldn't affect Web compatibility. It's a quality-of-implementation issue.
Comment 5 Florian Bender [fbender] 2013-04-02 20:04:58 UTC
I think there are several use cases where multi-monitor support for web apps is desirable. The following use cases require one or more fullscreen views on separate monitors, either due to presentational reasons or UI focus / maximizing available screen real estate. 


1) A presentation system: Slides on one screen (e. g. DVI-attached projector), controls/notes/time etc. on another (presenter-facing) monitor (e. g. internal notebook monitor). See e. g. Keynote's multi-monitor mode. Any chrome is distracting in this case. 

2) Streaming video from a web app (e. g. on a phone/tablet) to a TV (secondary screen) while displaying a remote on the primary internal screen. Compare with e. g. YouTube app with AirPlay. 

3) Many professional or industrial applications can benefit from a multi-monitor setup to extend the number of things you can display at once, have multiple concurrent views with different characteristics (e. g. a data view on one monitor and controls on a touch screen), or have multi-user setups (e. g. a controller, a supervisor and a visitor view, see also #1). Chromeless windows are not required, however having a fullscreen view will clearly benefit the app's UX. 

4) A multi-monitor broadcasting system (with network-attached screens), e. g. company- or department-wide announcement screens. It may sound strange, but I'm sure there are applications where this is very useful. This may also work for TV studio setups though the web is certainly not the right platform to use here (at least yet). 


I cannot think of non-fullscreen use cases, those can actually be accomplished with popups (but probably not mixed fullscreen and popups, at least with current implementations). Thus extending the current requestFullscreen API would be a straightforward approach to solve that problem (IMO). 

So this is just a rough sketch (certainly not a syntax proposal) but it could work like that (somehow related to use case #4): 

```
navigator.getAvailableVideoStreams(function(streams){
  let destinations = [];
  for dest of streams {
    if (dest.isRemote) 
      destinations.push(dest);
  }
  videoElement.requestFullscreen({destination: destinations});
});
```

The available video output streams (each stream is an independently accessible video out stream, as defined by h/w and OS) may indicate if they are local (e. g. attached via DVI) or remote (e. g. via network). The streams should indicate their native resolution (`dest.resolution = [width,height,depth?]`). 

The streams may also provide interfaces for ambient light, brightness, integrated speakers etc., but their use cases are rather academic and certainly out of scope for a v1 (plus, no hardware may support any of this; I'm just exploring possibilites). 


Either way, I think this is a useful and much needed addition to current functionality. This may also be an important feature for B2G-like phones/tablets for tethered or wireless video/interface output (where the current requestFullscreen itself does not make immediate sense). Additionally, having a totally different API for this feature does not seem to be a practical approach here (IMO).
Comment 6 Anne 2015-07-27 07:11:49 UTC
Florian, I filed https://github.com/w3c/presentation-api/issues/150 to check, but I have the feeling there's little overlap between presentation and using fullscreen, although presentation was once of the use cases for fullscreen...
Comment 7 Anne 2015-07-28 07:31:39 UTC
Closing this in favor of that. Perhaps once there are primitives for other monitors we can solve this better, but I don't plan on pioneering that. If you have the resources and want to solve this, do let me know and I'll help you out.