Thanks for the LGTMs! On Thu, Nov 18, 2021 at 12:18 PM Chris Harrelson <[email protected]> wrote:
> Could you also file a webkit-dev signals request, and a "FYI" TAG issue? > Yes, definitely. The webkit-dev request will show up here <https://lists.webkit.org/pipermail/webkit-dev/2021-November/> soon, and here is the TAG Review <https://github.com/w3ctag/design-reviews/issues/691> . > > 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/CAM%3DNeDgGfzVSaSWKRxoxWh90r9b0AwgQ54SdcuPWWSwYB8kMsA%40mail.gmail.com.
