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. > > 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/CAM%3DNeDh%3D2Vt%3Dg_Ms%3DPohm8NfWXVGNAXotugWnbEA2E2o%3DSjZrw%40mail.gmail.com.
