w3c / window-management

Window Management API
https://www.w3.org/TR/window-management/
Other
96 stars 25 forks source link

Feature request: Fullscreen support on multiple screens #92

Open shizukanaqun opened 2 years ago

michaelwasserman commented 2 years ago

I've updated the title for clarity. Anyone is welcome to share use cases for such a request.

This is a complex subject, because it's unclear how the Fullscreen API, in particular Element.requestFullscreen() would map a single element to an arbitrary region corresponding to multiple displays.

The only way to accomplish anything like this, currently, is to open multiple windows and make each one fullscreen on a separate display. Unfortunately, that requires ~1-2 user gestures for each screen. I think this request would be best served by a new Fullscreen API entrypoint.

The first step to making that a reality is demonstrating a need for the web platform to support this functionality.

jpambrun commented 2 years ago

I am working for a large PACS vendor. PACS viewers are used by radiologist to review and provide diagnostic based on medical imaging. I imagine you are familiar since it's the 3rd motivating example on the draft spec.

It's not uncommon for radiologist to have "cockpits" with 5 monitors. At the same time, Radiologist are notoriously averse to any unnecessary interactions or "clicks". We currently use an electron wrapper to enable seamless multimonitor and app-like behavior.

I am currently experimenting with desktop pwa, window-overlay and multi-window placement to retire electron, but it currently falls short. We definitely need to way to either 1) make different divs of a single page full screen or 2) be able to position a window across multiple monitors (maybe at least in PWA?) and/or 3) to be able to launch multiple window without with noopener in full screen.

about no3 and noopener, this might be needed because opening 4 heavy fullscreen windows all sharing the same process/main js thread makes it really hard to keep performance up.

As of now, we have reduced the electron footprint to a minimum by using window-placement for no2, but I still have to make browserWindow.setPosition/setSize from the node side available on the web side to avoid the clamping applied to window.moveTo and window.resizeTo. BTW, it's really annoying that moveTo(0,0) leaves a ~10x gap on windows.. I also would like this to go over the taskbar.

I understand that some of these are security consideration, but maybe it could be handled via a permanent/remembered permission, or maybe relaxed for installed PWA?

As it is today, it covers 95% of was is needed for medical applications, but the remaining 5% is really just disqualifying..

shizukanaqun commented 2 years ago

At present, more and more web applications have a resolution of 3840*1080, or even larger. Chrome's Fullscreen Mode (press key F11) only supports a single monitor, which cannot display all the content of the web application, so we urgently need Consider expandable FullscreenMode (perhaps pressing alt+f11 ) to support fullscreen capability on multiple monitors

shizukanaqun commented 2 years ago

QQ截图20220408103420

jpambrun commented 2 years ago

Another data point. I just spoke with an integration specialist for our existing medical viewer and I am told mixed resolution workstation are common where for example one diagnostic monitor would be 3 megapixels and the the other 5. This would make the stretched approach unusable.

An alternative would be 1)the multiple element.requestFullscreen() from one page to multiple monitor approach or 2) some way to get multiple window to go fullscreen with only one user interaction.

Also, going with 2) it would be nice to be able to do that without opener reference. It's really hard to have the worklist plus 2 or 3 full diagnostic viewer window perform well when all sharing the same process and main thread.