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)
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, > 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/CAL5BFfWV7wLbqN5Cv%2BypfzgNxkmrYtVH_rMOPnWBSgAYT2nOGw%40mail.gmail.com.
