-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Further BarProp cleanup #4431
Comments
Also describe what happens when the browsing context is discarded. Tests: web-platform-tests/wpt#15815. Follow-up: #4431. Fixes #2579.
yes, I checked the properties as well. and yes, there's inconsistency between browsers, about which property becomes the following is tested on macOS (that may affect "menubar") Normal window (tab)
Popup (with
|
Firefox | Safari | Chrome | Edge | |
---|---|---|---|---|
locationbar.visible |
true |
false |
false |
false |
menubar.visible |
false |
true |
false |
false |
personalbar.visible |
false |
false |
false |
false |
scrollbars.visible |
true |
true |
false |
false |
statusbar.visible |
true |
true |
false |
false |
toolbar.visible |
false |
false |
false |
false |
So, the values returned by Firefox and Safari almost matches the visual.
personalbar
: always hiddenscrollbars
: becomes visible if necessarystatusbar
: on Firefox, statusbar is shown as overlay if necessary. (I'm not sure if statusbar exists on Safari)toolbar
: always hidden
Differences are:
locationbar
: shown for Firefox, hidden for Safari (so this is reasonable difference)menubar
: in both Firefox and Safari, a popup doesn't have menu, but there's global menu at the top of screen anyway
And Chrome and Edge returns same value for all properties, just depending on whether it's popup or not.
(EDIT: this was not true. Chrome reflects the UI-related feature values, and width=500
makes them false
)
Also, personalbar
value doesn't reflect the actual visibility, in normal window.
Regardless of showing it or not, it returns true
on normal window, and false
on popup.
Then, so far, I don't think any window.open
feature affects each BarProp
independently.
Thanks, I have to say I rather like the model Chrome has, just return false for popups. Not sure we should really tell websites about what UI elements are visible or not. |
Fixes whatwg#4431 Standardize the value of BarProp attributes, while hiding the actual visibility from the web content for privacy reasons.
…alues for each case For whatwg/html#5872 and whatwg/html#4431
Fixes whatwg#4431 Standardize the value of BarProp attributes, while hiding the actual visibility from the web content for privacy reasons.
…alues for each case For whatwg/html#5872 and whatwg/html#4431
Fixes whatwg#4431 Standardize the value of BarProp attributes, while hiding the actual visibility from the web content for privacy reasons.
Fixes whatwg#4431 Standardize the value of BarProp attributes, while hiding the actual visibility from the web content for privacy reasons.
Fixes whatwg#4431 Standardize the value of BarProp attributes, while hiding the actual visibility from the web content for privacy reasons.
…alues for each case For whatwg/html#5872 and whatwg/html#4431
Fixes whatwg#4431 Standardize the value of BarProp attributes, while hiding the actual visibility from the web content for privacy reasons.
…alues for each case For whatwg/html#5872 and whatwg/html#4431
Fixes whatwg#4431 Standardize the value of BarProp attributes, while hiding the actual visibility from the web content for privacy reasons.
The Chromium behavior wasn't correct. |
on Chromium,
|
Thanks! I suspect that changing the BarProp values to just follow "is popup" is not a major compat risk, but @mfreed7 is the right person to make the call. |
…by window.open, and BarProp values for each case, a=testonly Automatic update from web-platform-tests HTML: test BarProp and window.open() feature interactions For whatwg/html#5872, whatwg/html#4431, and whatwg/html#6530. -- wpt-commits: 29faceaa68f5cb31798cc17fe6868eaf5fa5fb7f wpt-pr: 28243
…by window.open, and BarProp values for each case, a=testonly Automatic update from web-platform-tests HTML: test BarProp and window.open() feature interactions For whatwg/html#5872, whatwg/html#4431, and whatwg/html#6530. -- wpt-commits: 29faceaa68f5cb31798cc17fe6868eaf5fa5fb7f wpt-pr: 28243
Fixes whatwg#5872 by standardizing an internal "is popup" boolean, and how it is impacted by various window.open() features. Implementations can use this boolean (in addition to other signals) to determine whether an opened window is a popup or not. Fixes whatwg#4431 by changing the various BarProp visible properties to only reflect this "is popup" boolean, instead of reflecting the actual state of user interface elements, or the passed-in window features. Adds a "popup" window.open() feature to provide a simpler method of requesting a popup.
Fixes whatwg#5872 by standardizing an internal "is popup" boolean, and how it is impacted by various window.open() features. Implementations can use this boolean (in addition to other signals) to determine whether an opened window is a popup or not. Fixes whatwg#4431 by changing the various BarProp visible properties to only reflect this "is popup" boolean, instead of reflecting the actual state of user interface elements, or the passed-in window features. Adds a "popup" window.open() feature to provide a simpler method of requesting a popup.
My assumption is that the user interface elements the
BarProp
talks about can be controlled viawindow.open()
. It would be good to test if they can actually be flipped from true to false somehow and define the underlying model more clearly.This would be a follow-up to #4430.
The text was updated successfully, but these errors were encountered: