Should we really be extending window.open()?

[mkruisselbrink]

If clients.openWindow would be made available in all contexts (w3c/ServiceWorker#955), does it really make sense to bolt on this new functionality to window.open(), and its awkward synchronous and string parsing based API, or would it make more sense to stick to only adding the new functionality to clients.openWindow?

I see you've listed this as an "Alternative or Supplemental" proposal, but it's not clear to me why the leading proposal is the leading proposal (i.e. why is it the better option)?

[michaelwasserman]

Thanks for bringing this up. I think the existing APIs should behave sane in a multi-screen environment, as a bare minimum. This means window.open/moveTo/moveBy should aim to respect reasonable coordinates, and not clamp window creation and movement to the screen currently hosting the content (in some implementations, like Chrome). That should suffice for some use cases and requires less overall change to the current web platform and usage patterns.

If clients.openWindow were made available in all contexts, that makes the alternate/supplemental proposal even more appealing, but I still see fixing the existing behavior, with a sufficient (albeit awkward) API surface, as "step one".

Please share more thoughts on this, so we can set an appropriate direction early on, thanks!

[mkruisselbrink]

Making the existing functionality of window.open do reasonable things sounds reasonable to me, yes (although from the explainer it sounds like that is really more an implementation detail currently, and some implementation already do that? I.e. that's more a "we should fix our implementation" rather than a "we should fix the standard" situation? I guess unless you think we should constrain what user agents are allowed to do in the "user-agent-defined manner" bits of https://drafts.csswg.org/cssom-view/#set-up-browsing-context-features (which I guess is what you're suggesting in the "leading proposal" bit).

I also wonder how feature detection would work with the window.open() approach? While feature detection isn't great for new options to clients.openWindow() either, at least it would be possible (calling it with an invalid URL and a dictionary with custom getters should let you detect which optional options are or are not supported).

So it seems like we can fix our implementation for window.open() without having to mess with the spec (and leave it all user agent defined, and impossible for websites to really rely on), and if websites want to actually have specific window placement behavior they can use a "nicer" openWindow(url, optionsDictionary) API with more rigorously specified behavior.

(Also you've almost certainly spent a lot more time thinking about this than I have, so I'm sure there are things I'm missing as well).

[michaelwasserman]

Yes, ideally I'd like to change Chromium's user-agent-defined manner of clamping x and y for window.open/moveTo/moveBy() (which should yield more compatibility around Firefox's current behavior), encourage other implementations to similarly support cross-screen coordinates, and clarify those clamping instructions in the spec. I don't know how we could offer cross-screen feature detection in window.open() without new parameters. I'd like to ascertain whether a best-effort + reasonable fallback approach to fulfill requests there might be sufficient for our users' needs.

If openWindow() is extended with options, starting with more rigorously specified behavior does seem nice. Feature detection for cross-screen (vs current-screen) placement in openWindow() could work with options for coordinates and a screen object/id (access signifies cross-screen support). That might make coordinates relative to the primary screen redundant, so the coordinates could be local to the specified (or current) screen. I wonder what other tradeoffs there are between using that pattern or just taking cross-screen coordinates like window.open().

I'll aim to clarify my proposal and explore these openWindow ideas more in the explainer. Thanks!

[Garbee]

I've been thinking about this a bit lately as well. Thinking about all the possible things we'll want in this kind of system later (like grouping windows together possibly) it becomes problematic to be using window.open without modifying that string parameter (poorly) or introducing an object as a type to it so we can get the good benefits from that style of option handling.

Personally I settled myself on, for now modifying window.open (and friends) for the screen placement is acceptable. However once we start looking into additional features, that's when we want to assess how to handle the options. Path of least resistance now, in exchange for stalling what will probably be a grinding debate with an even more heated debate on the standards track until later.

Simply put, I don't see enough justification given our current scope to go modifying old API parameters or restricting where the new things can be used.

[nadavsinai]

I completely agree, having a new API such as openWindow will help in progressive enhancement

if (openWindow in self) {
//use openWindow API
}else {
// //fallback to window.open, knowing we can't go out of monitor bounds
}

a modern API would mean we get Promise based async return values & extendable object dictionary for options rather than the ugly DOMString options.

[michaelwasserman]

Thanks for contributing insight here! I have modified the proposal to make it clear that there are multiple aspects worth pursuing upfront, and have attempted to convey a similar prioritization of extending openWindow in addition to fixing existing window API impls/specs.

Also, please note that nothing in the spec (nor in some implementations, like Firefox) is stopping you from using window.open/moveTo/MoveBy to go out of monitor bounds, it's just current user-agent-defined behavior; I hope to explore and document (and fix!) the variation among implementations here soon.

Please reopen this issue if there's more to address in the explainer, otherwise feel free to continue commenting here with additional thoughts, context, and use cases that don't require explainer changes.