Restrict openWindow() to http(s) schemes?

[jakearchibald]

We currently reject on about:blank (due to #696), but is there any benefit in allowing schemes other than http and https?

What would it mean to openWindow('mailto:hello@example.com')? etc

I propose we reject on schemes other than http/https. Any objections?

[annevk]

What happens if you hit a redirect to a custom scheme? Or execute some JavaScript to navigate to one?

[mfalken]

Hey, I just noticed the about:blank spec change.

Chrome currently treats all about:* URLs as "about:blank" in openWindow(). Apparently this mimics the behavior of window.open(). cc @mounirlamouri who implemented this in https://codereview.chromium.org/980383004

By the logic of issue #696, it would seem we should instead reject all about:* instead of opening about:blank. Should the spec codify that?

[jakearchibald]

Apologies for flip-flopping, but I'm no longer convinced the changes in #696 were a good idea.

Sure, clients.openWindow('about:blank') creates a window that cannot be used by the SW, and is arguably useless, but as @annevk points out, a developer would open a page on their origin that navigates to about:blank with JS, or a redirect. Or, they could do clients.openWindow('/whatever').then(c => c.navigate('about:blank')) once #681 lands.

Making openWindow accept a different set of URLs to window.open seems needlessly complicated.

[annevk]

It seems better if they follow the same code path as much as possible, agreed. This requires some special casing though for about:blank as bz pointed out in that bug. You want it to inherit the origin of the service worker (and likely the CSP policy, and maybe some other stuff, we should have something for that).

[jakearchibald]

F2F: Allowing about:blank means figuring out what origin it is, and if it's service-worker controlled. It's more complicated than it seems, and it's a real edge case. Moving to v2, since we can add it later.