search

w3c / window-management

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

Feature detection support? #9

Open michaelwasserman opened 4 years ago

michaelwasserman commented 4 years ago

Q: How can we let developers detect support for various new Window Placement features?

  1. window.[open/moveTo/moveBy]() supporting cross-screen coordinates
  2. requestFullscreen(fullscreenOptions)'s options dictionary supporting a screen member
  3. 'fullscreen=yes' support being re-enabled for window.open() (in limited cases?)

Suggestions are welcome; this may be difficult to achieve without adding new API surfaces.

Garbee commented 4 years ago

As far as 1 goes, I'm not sure there is a feasible way to do that. However, since the default is to clamp the windows onto the monitor the app executing is currently within, would we really need to detect it for any reason? It won't error if it fails, it'll just not show up in the right place.

On point 2 for the fullscreenOptions dictionary... I don't believe the web currently supports detection of dictionary contents. However, if we were to develop a new API subset (this is where things will get funky and hard due to BC) we could expose a way to get the list of known dictionaries and use hasOwnProperty or an API akin to it from that data. This would let developers be able to check the support of any dictionary known to a browser. I think this level of works is out of scope of this particular API and more a new thing that should be investigated in its own merit if no one else knows of a good solution currently possible.

For point 3, feature detecting a string key/value pair in an option string... No way comes to mind. I'll think about it. Not even sure of a way to propose something for this. Aside from making a new method somewhere which "checks validity" of the string and whether the browser can execute that. Before going through that effort though, I'd love to know the use-case for needing to feature detect that.

Looks like all of this would need new API surfaces to be reliable and open to expansion for future changes in other specs too. The idea of exposing known dictionaries as for point 2 is extremely promising IMO.

michaelwasserman commented 2 years ago

There's still some validity to this question, but I think the API generally adds a sufficient level of feature-detection support, given the preexisting landscape.

Beyond that, sites can estimate supported coordinates from the multi-screen available bounds exposed by the API. Browsers will generally clamp bounds to be within the work area of a specific display, but this implementer-specific behavior. It should be noted that some Window Managers may not support coordinate-based placements, see #68; we might want to consider ways to notify sites whether coordinate-based placement is possible.

We may wish to improve documentation about these topics.

michaelwasserman commented 1 year ago

This came up in https://github.com/w3ctag/design-reviews/issues/767

For practical purposes, sites can feature-detect the capability to place content on specific screens via access to those screens in the ScreenDetails interface, but must consider other factors.

Sites face uncertainty about popup blocking and feature detection. Window.open()’s steps invoke the rules for choosing a navigable, wherein step 8 requires (but does not consume?) transient activation iff the user agent has been configured to not show popups (i.e., the user agent has a "popup blocker" enabled). Also, windowFeatures bounds are often [clamped in user-agent-defined manners](https://w3c.github.io/csswg-drafts/cssom-view/#the-features-argument-to-the-open()-method) by a loosely defined web-exposed screen area. See the Spec’s Concepts, which attempt to expand web-exposed screen areas for multi-screen devices.

So sites can check a some popup prerequisites (navigator.userActivation.isActive, screen bounds, etc.), but not whether the user agent is configured to show popups, nor how windowFeatures will be interpreted or adjusted (e.g. when a popup request will instead open as a tab, whether bounds will be clamped to the opener’s display, etc.). Instead, sites ask users to unblock popups, and deal with second-class window management support.

Relatedly, sites can check a subset of Element.requestFullscreen() prerequisites (e.g. transient activation, target screen validity), but additional feature-detection support might be warranted.

Perhaps most confusing are the nuances of how window management requests might be constrained or have ancillary effects, given platform, user-agent, and circumstantial conditions that factor into each request. For example, Element.requestFullscreen() might make other displays blank on macOS when “Displays have separate spaces” is explicitly disabled, or using window.open() to show a popup might cause the opener or a related window to exit fullscreen, or the popup request might open as a tab if the opener’s window was made fullscreen without use of HTML APIs.

I support adding feature-detection for window.open() (or even replacing window.open with a more modern interface), but it seems fairly complex given the legacy of this API. Here are some strawperson ideas that might support transient activation requirements, potential delegated capabilities, and more condition-specific capabilities like being able to open a popup without a transient user activation after requesting fullscreen on a target screen of a multi-screen device): Add a new API surface solely for window.open() feature detection Promise<adjusted arguments> window.canOpen(<arguments>), which might reject if conditions aren’t met, or otherwise signal whether transient user activation signals would be required or consumed? Add a new API surface to check window capabilities, given the current activation, user agent configuration, capability delegation, and other signals. For example: Promise window.hasCapability({‘open’, ‘popup,left=12,top=34,width=567,height=890’}) Strengthen standards algorithms for interpretation of windowFeatures, etc.