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-5TDihhVbFuhAvZvKbXKNfirxPZRa%3DBzHQZDd_PAjSUA%40mail.gmail.com.
