Re: [w3c/ServiceWorker] should an window.open() about:blank document be controlled by opener's controller? (#1163)

asutherland left a comment (w3c/ServiceWorker#1163)

Okay, so I think in Gecko it's untenable for us to inherit the controller into auxiliary browsing contexts via window.open().  It turns out we have **not** been inheriting in this auxiliary browsing context case, but in https://bugzilla.mozilla.org/show_bug.cgi?id=543435 on beta we tried to start doing it because it was our reading of the spec text that we should (and honestly I thought we'd been inheriting it), but it's effectively incompatible with our storage partitioning implementation which thinks that such a window should not be partitioned[1].  We are planning to remove the inheriting again before it reaches release.

Our anti-tracking team has indicated that they think there are potentially significant webcompat problems with attempting to partition in the auxiliary browsing context case, so it is unlikely for this to change any time soon.

So I guess Gecko's answer to the question "should an window.open() about:blank document be controlled by opener's controller" is now no and I think we'd like to get consensus where other browsers are on this, especially those that implement partitioning.

cc @annevk @youennf

1: That said, we could do a ton of carve-outs so that the about:blank in fact does inherit, but it would be very contradictory since then a navigation to a same-origin (non-about:blank) URL would go from being partitioned to being unpartitioned and we would potentially be fighting a ton of invariant assertions, which is our current problem because a bunch of safety checks can get very upset.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1163#issuecomment-3779656101
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1163/3779656101@github.com>