Could you also file a webkit-dev signals request, and a "FYI" TAG issue?
On Thu, Nov 18, 2021 at 12:16 PM Chris Harrelson <[email protected]> wrote: > LGTM3 > > On Mon, Nov 15, 2021 at 1:15 PM Yoav Weiss <[email protected]> wrote: > >> LGTM2 >> >> On Mon, Nov 15, 2021 at 8:18 PM Mason Freed <[email protected]> wrote: >> >>> Thanks for the comments! >>> >>> On Mon, Nov 15, 2021 at 1:17 AM Yoav Weiss <[email protected]> >>> 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 >>> <https://github.com/whatwg/html/issues/5872#issuecomment-883729502>) >>> 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. >>> >> >> Yeah, that makes sense! >> >> >>> >>> >>>> >>>> On Fri, Nov 12, 2021 at 5:22 PM Rick Byers <[email protected]> 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! I definitely agree that this is an area that can cause >>> compat trouble. We'll definitely monitor for feedback, and there is a >>> blink::Feature (kWindowOpenNewPopupBehavior) that can be used as a >>> killswitch if necessary. >>> >>> Thanks, >>> Mason >>> >>> >>> >>>> Thanks, >>>>> Rick >>>>> >>>>> On Thu, Nov 11, 2021 at 12:16 PM Mason Freed <[email protected]> >>>>> wrote: >>>>> >>>>>> Thanks Tooru for the explanation. (Tooru made/landed the spec changes >>>>>> for this feature.) >>>>>> >>>>>> I've also updated the chromestatus entry >>>>>> <https://chromestatus.com/feature/5663031909416960> with a bit more >>>>>> detail, and I copied the new text below. Hopefully between the two of >>>>>> these, your questions have been answered. But let me know if not! >>>>>> >>>>>> Motivation >>>>>> >>>>>> The window.open() API is currently confusing to use, in terms of >>>>>> trying to get it to open a popup vs. a tab/window. This change simplifies >>>>>> the usage by adding a single boolean argument called 'popup' that works >>>>>> as >>>>>> you'd expect: popup=1 gets you a popup, and popup=0 gets a tab/window: >>>>>> const popup = window.open('_blank','','popup=1'); const tab = >>>>>> window.open('_blank','','popup=0'); Also there were previously >>>>>> confusingly-behaved getters for the BarProp visible properties (e.g. >>>>>> window.statusbar.visible) which didn't correctly represent what was >>>>>> actually visible. Now, those all return true if you got a new window/tab, >>>>>> and false if you got a popup. This is an interop-driven change, to align >>>>>> Chromium with the newly-landed spec for window.open. It does not change >>>>>> existing behavior around whether a popup or tab/window is opened, to >>>>>> avoid >>>>>> compat issues. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Nov 10, 2021 at 12:10 PM Tooru Fujisawa <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hello :) >>>>>>> >>>>>>> > 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 condition to open minimal popup >>>>>>> - whether to open popup or not isn't normative. browsers can: >>>>>>> - provide options to override the behavior >>>>>>> - simply ignore, for example, in case it lacks the concept >>>>>>> of window, like mobile browsers >>>>>>> - BarProp.visible value >>>>>>> - this is normative change, for improving privacy >>>>>>> - It stops reflecting actual UI visibility or features >>>>>>> parameter of window.open >>>>>>> - if the window/tab is opened by requesting a popup by >>>>>>> window.open, all BarProp.visible returns false. otherwise true >>>>>>> >>>>>>> the developer impact would be: >>>>>>> >>>>>>> - popup condition >>>>>>> - in general >>>>>>> - the old UI-related features (locationbar, toolbar, >>>>>>> menubar, resizable, scrollbars, status) are now mildly >>>>>>> deprecated >>>>>>> - if they want positioned/sized a popup, just specifying >>>>>>> left/top and/or width/height works >>>>>>> - if they don't want a popup, they shouldn't specify any >>>>>>> features except noopener or noreferer >>>>>>> - on Chromium >>>>>>> - the basic condition isn't changed. no impact >>>>>>> - on Firefox >>>>>>> - width feature is removed from the condition for opening >>>>>>> popup window, but having non-empty feature requests popup, so >>>>>>> not much >>>>>>> impact unless the feature has >>>>>>> location,menubar,scrollbars,status that requests non-popup >>>>>>> - on Safari >>>>>>> - Safari uses different behavior, it uses minimal popup, >>>>>>> normal window, and normal tab, and the condition is different, >>>>>>> so there can >>>>>>> be some impact that different thing (window/popup/tab) is >>>>>>> opened >>>>>>> - new "popup" feature >>>>>>> - in general >>>>>>> - if website hits a compatibility issue about whether to >>>>>>> open popup or not, they can use the newly added "popup" >>>>>>> feature for the quick fix >>>>>>> - popup=1 if they want a popup >>>>>>> - popup=0 if they don't want a popup >>>>>>> - for basic usage, this feature isn't much necessary, >>>>>>> given: >>>>>>> - to request popup, having non-empty features (except >>>>>>> noopener or noreferer) works, and in most case the >>>>>>> popup will have width (if the website wants to request >>>>>>> popup without specifying position/size, they can use " >>>>>>> popup" feature) >>>>>>> - to request non-popup, just having empty features (except >>>>>>> noopener or noreferer) works >>>>>>> - BarProp.visible: >>>>>>> - in general >>>>>>> - there was already inconsistency between browsers, so I'd >>>>>>> expect not much meaningful usage for it, except for finger >>>>>>> printing >>>>>>> - there's no alternative for getting actual UI visibility >>>>>>> - on Chromium >>>>>>> - this was returning each features in window.open call >>>>>>> - on Firefox and Safari >>>>>>> - this is/was mostly returning the actual visibility >>>>>>> >>>>>>> > Have they implemented? Have they shipped? >>>>>>> >>>>>>> Firefox implemented and shipped the change in version 96, that will >>>>>>> be released on 2022-01-11: >>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1701001 >>>>>>> >>>>>>> The option to override the behavior is in WIP: >>>>>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1714939 >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> 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 >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAM%3DNeDh8Oi%2Bi37s0WVUFzYPMxGTx-TOwBaETdk6WgT5P_8FPuw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> >>>>> -- >> 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 [email protected]. >> 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 >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfUJ%2Bpc3iM7N-f_v6HkGaFRFQbWnbhp_2jTEEH%3DJ91WqOQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_0mnJnJi_Rzo5gJxOfrfFU2rAyPdyEBBNQ9NEqzY6MxQ%40mail.gmail.com.
