Search tagswindow.open, popup
TAG reviewVery small change, landed as part of the HTML spec, so no TAG review should be needed.
TAG review statusNot applicable
> Could you maybe write a few lines that explain what this does and how developers are expected to use it?
The change standardize the following 2 things:
the developer impact would be:
> Have they implemented? Have they shipped?
Firefox implemented and shipped the change in version 96, that will be released on 2022-01-11:
The option to override the behavior is in WIP:
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDh8Oi%2Bi37s0WVUFzYPMxGTx-TOwBaETdk6WgT5P_8FPuw%40mail.gmail.com.
Thanks Mason and Tooru!This does indeed sound like an improvement towards interop on the popup front.Does this change the current Chromium behavior by default? (i.e. when a "popup" argument is not passed)
On Fri, Nov 12, 2021 at 5:22 PM Rick Byers <rby...@chromium.org> wrote:I'm thrilled to see window.open behavior getting more predictable and understandable. Thank you Tooru and Mason! The precise details of window.open behavior has long been an ugly wart on the web platform IMHO.I agree that the risk seems likely to be small, LGTM1.But as always, please keep an eye out for feedback during canary/dev/beta and be prepared to pause the roll-out of this feature if we see non-trivial evidence of compat impact. window.open seems like exactly the sort of feature that sites have taken hard dependencies on the precise behavior of in different browsers for many years. These are the sort of features which often surprise us with compat impact due to very subtle changes, but we can't let that stop us from trying to improve them.
Thanks for the comments!On Mon, Nov 15, 2021 at 1:17 AM Yoav Weiss <yoav...@chromium.org> wrote:Thanks Mason and Tooru!This does indeed sound like an improvement towards interop on the popup front.Does this change the current Chromium behavior by default? (i.e. when a "popup" argument is not passed)No, this should not change the "opening" behavior of Chromium. We originally planned to slightly change the "triggers" for a popup, but a use counter study (results discussed around here) showed too high a percentage of potentially changed behavior. So we fell back to the current proposal which does not change behavior (assuming "popup" isn't passed). This proposal will change the return values from the BarProp properties, but these should have lower compat risk, we think.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUJ%2Bpc3iM7N-f_v6HkGaFRFQbWnbhp_2jTEEH%3DJ91WqOQ%40mail.gmail.com.
Could you also file a webkit-dev signals request, and a "FYI" TAG issue?