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.
