noopener window.open feature seems pretty broken as implemented in browsers

[bzbarsky]

Trying to use it gives a very broken window because it turns off all the other window features, in both Firefox and Chrome.

Furthermore, it forces the new window into a separate window, not a tab, because it's turning off all the other features.

I don't see how it could possibly be usable in the state it's in right now, unfortunately. Of course it doesn't help that per spec the only supported features are left/right/width/height, which doesn't match browser behavior....

@mikewest

[bzbarsky]

This didn't really get fixed, because per spec this is not really a problem, in theory.

The key part is "per spec the only supported features are left/right/width/height, which doesn't match browser behavior". Though the spec has changed even on this and doesn't really support anything at all now.

In particular, per spec as currently written, the open steps tokenize the features (modulo #3107) and then ignore all the tokens except "noopener" (thus raising the question of what the point of https://html.spec.whatwg.org/multipage/window-object.html#normalizing-the-feature-name is for, of course). That's not what browsers actually do though; they pay attention to other things in that feature string and will turn off various features if they are not present in a nonempty feature string. So simply specifying "noopener" will turn off large chunks of the browser UI.

[annevk]

Hmm, the point was that we'd defer to CSSOM for the remaining features. Ah, #2464 is still open and about that. Seems @zcorpan wasn't able to drive that to a conclusion yet.

[bzbarsky]

OK. We do need to actually pass the tokenized features to somewhere where CSSOM will see it...

But fwiw, on the HTML spec front just removing "noopener" from the tokenized features before passing on to the lower layer would presumably fix this problem, in that it would make it clear that noopener has no effect on the appearance.... Then we could at least file bugs on implementations to fix their broken stuff.

[annevk]

Wouldn't CSSOM ignore unknown tokens anyway?

It seems not passing it to CSSOM regressed somewhere after b649435. Sigh.

[bzbarsky]

Wouldn't CSSOM ignore unknown tokens anyway?

That doesn't match actual browser behavior (again in at least Firefox and Chrome). If I do:

window.open("", "", "yousaywhat?");

I get a browser window missing UI pieces in both.

[zcorpan]

I was aware that unknown features are different from empty string, that was reported in https://www.w3.org/Bugs/Public/show_bug.cgi?id=25685#c3 and not yet fixed.

#2464 is indeed also about this. But a good first step would be to specify special treatment to the empty string (or maybe empty set of features) in cssom.

@bzbarsky

But fwiw, on the HTML spec front just removing "noopener" from the tokenized features before passing on to the lower layer would presumably fix this problem, in that it would make it clear that noopener has no effect on the appearance....

That's a good idea.

(Edit: fixed 2474 -> 2464 above.)

[annevk]

Okay, I created #3297 to remove noopener before passing it on to CSSOM.

[annevk]

Okay, so now HTML removes noopener/noreferrer before invoking https://drafts.csswg.org/cssom-view/#set-up-browsing-context-features.

#2464 tracks additional features, though normalizing of most of these is defined in HTML too.

https://drafts.csswg.org/cssom-view/#set-up-browsing-context-features seems to be lacking still as it doesn't address certain features, e.g., toolbar, and it doesn't do something special if the passed map is non-empty (regardless of whether any of the features are recognized).

@zcorpan @emilio do you know if there is a tracking issue on the CSSOM side for those?

[zcorpan]

There are the old bugs in Bugzilla (linked above); I can't find anything in GitHub.

[annevk]

Closing this now I put all the relevant remaining information in #2464. That also links a corresponding CSSOM issue.