-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Add details of multi-screen origin support to relevant features #21123
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'd take more testing (and better WPTs!) to be really thorough here, but in general: Firefox seems to support relative-multi-screen coordinates fairly well, while Safari has some inconsistencies around window.open(). Hopefully my comments are helpful.
"chrome": { | ||
"version_added": "1" | ||
}, | ||
"chrome_android": "mirror", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm uncertain about any Chrome behavior on Android's multi-screen freeform windowing mode. Ditto for anything else mobile... sorry.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A part of me thinks that this is perhaps not so important, as surely not many people are going to be using mobiles with multiple screens...but I'm really not sure. When I tried my demo app on Chome Android, it didn't seem to work (the windows wouldn't open), although the feature detection returned true
(i.e. it is supported).
I wonder if the BCD collector app can give us anything interesting with regards to mobile support?
api/Screen.json
Outdated
"firefox": { | ||
"version_added": "1", | ||
"partial_implementation": true, | ||
"notes": "Behavior is inconsistent/unreliable." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say Firefox has full implementation support here, and for most API surfaces representing coordinates relative to the multi-screen origin. In general, I have observed inconsistent/unreliable behavior at times in the past, but never fully cataloged them, and Firefox 115 ESR on Linux X11 and Firefox 118 on Mac seems coherent in a few minutes of basic testing: screen.left|top, window.moveTo(), window.open(), and window.screenX|Y use multi-screen origin coordinates. moveTo|By clamps windows to their current display, but window.open can open a popup with coordinates on any display.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, thanks. I've updated the data points to represent this information.
api/Window.json
Outdated
"firefox": { | ||
"version_added": "1", | ||
"partial_implementation": true, | ||
"notes": "Behavior is inconsistent/unreliable." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ditto, I'd say Firefox has full implementation support for specifying moveTo and open coordinates relative to the multi-screen origin, even if requests are clamped to the current screen sometimes (but not others).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I've put that for moveTo/By, multi-screen coordinates are used, but windows are clamped to their existing displays. For open(), I've just put no note, i.e. it works perfectly for multi-screen origin. That seemed to be what you were saying above?
api/Window.json
Outdated
"opera_android": "mirror", | ||
"safari": { | ||
"version_added": false, | ||
"notes": "Opened relative to the origin of the primary screen." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't figure out Safari's behavior here... in one test, top was relative to the current screen, but left from an opener on a secondary screen was completely disregarded, then I rearranged displays and left was relative to the primary screen, while top from an opener on a secondary screen was completely disregarded. That's getting into territory where I'd use terms like inconsistent and unreliable....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Crikey, the Safari comments are not very encouraging.
I'm not certain it is really worth trying to understand and document the exact behavior of Safari, as it is so buggy and weird. For the moment I've just put the "Behavior is inconsistent/unreliable" note on the Window
features for Safari, and left it as support false
on the Screen
features (because the original data said false
for Safari, before I started working on this API).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks again for all your time and effort spent helping me to understand this stuff.
api/Window.json
Outdated
"opera_android": "mirror", | ||
"safari": { | ||
"version_added": false, | ||
"notes": "Opened relative to the origin of the primary screen." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Safari 17's behavior here is closer to 'inconsistent' or 'unreliable'; it seems to depend on the relative arrangement of displays. For example:
- Screens arranged primary to the left/right of secondary - left|top are relative to primary
- Screens arranged primary above/below secondary - left|top are relative to the opener's current screen
It gets even weirder if the displays don't share a top or left edge, e.g.:
- Screens arranged primary diagonal below+left of secondary - left is relative to primary, but top is (erroneously clamped?) to the top of the primary screen.
- Screens arranged primary diagonal above+left of secondary - left is relative to primary, but top is (erroneously clamped?) to the bottom of the primary screen.
"oculus": "mirror", | ||
"opera": "mirror", | ||
"opera_android": "mirror", | ||
"safari": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like Safari's screen.top and window.screenY is always relative to itself, but screen.left and window.screenX are relative to the multi-screen origin... it's hard to understand...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm with some minor comments, thanks for sorting through the unfortunate complexity here.
"standard_track": false, | ||
"deprecated": false | ||
} | ||
} | ||
} | ||
}, | ||
"availWidth": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should edge be mirror here? (line 224)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The trouble here is that if we mirror it, it will show the equivalent to Chrome 1, which is wrong, as Edge wasn't based on Chromium at that time. I also tried adding in an extra piece of support data to show that later on, Edge 100 (equivalent to Chrome 100) supports this without the note, but then it wants me to call the earlier support a partial implementation. But that's not really right either, as the old Edge implementation was correct that the time.
So I've opted to just leave it alone.
api/Window.json
Outdated
@@ -2789,6 +2789,42 @@ | |||
"standard_track": true, | |||
"deprecated": false | |||
} | |||
}, | |||
"relative-multi-screen": { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can drop this section, moveBy's parameters are relative offsets from the window's current position, not absolute coordinates in a single- or multi-screen space.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, makes sense. Removed.
"opera": "mirror", | ||
"opera_android": "mirror", | ||
"safari": { | ||
"version_added": "1", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to leave this marked false with the note? Otherwise, this is probably okay.
Ditto for all other Safari entries.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your suggestion doesn't sound correct to me — if it isn't supported at all, how can it exhibit inconsistent/unreliable behavior?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Understood, this framing is reasonable.
"edge": "mirror", | ||
"firefox": { | ||
"version_added": "1", | ||
"notes": "Multi-screen coordinates are used, but windows are clamped to their existing displays." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might either omit this, or note similar clamping in Chrome without window-management permission, and ditto for Chrome's window.open().
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Notes added as requested:
Without the
window-management
permission, multi-screen coordinates are used, but windows are clamped to their existing displays.
api/Window.json
Outdated
"version_added": "1" | ||
"version_added": "1", | ||
"partial_implementation": true, | ||
"notes": "Behavior is inconsistent/unreliable." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should screenX have a similar note?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ooop, the issue here is that I've got the note on the screenY
main feature as well as the relative-multi-screen
subfeature, whereas it should just be on the subfeature. I've fixed that now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm, ty!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One suggestion otherwise I think this is good!
api/Screen.json
Outdated
"safari": { | ||
"version_added": "1", | ||
"partial_implementation": true, | ||
"notes": "Behavior is inconsistent/unreliable." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is "behavior" a good word here? Sounds very generic to me. Could we instead say "Origin relation" to be a bit more precise what exactly is off here? (if you agree, please update throughout).
"notes": "Behavior is inconsistent/unreliable." | |
"notes": "Origin relation is inconsistent/unreliable." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Elchi3 I think you've got a point, but it feels to me like "Origin relation" is a bit difficult to comprehend. How about "Coordinate origin used is inconsistent/unreliable"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure, that works, too! :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Cool, notes updated!
…21123) * Add details of multi-screen origin support to relevant features * Making some changes based on michaelwasserman comments * Fixes for 2nd round of michaelwasserman comments * Update Safari notes as discussed
Summary
The Window Management API was implemented in Chrome 100 (see ChromeStatus entry). I originally submitted BCD updates for this in #20600.
However, during the tech review of my docs additions for this API, I added some details of how the multi-screen origin concept introduced with this API affects the behavior of some existing related features. This was done on the instruction of the tech reviewer, @michaelwasserman.
In his editorial review, @wbamberg then rightly pointed out that this information belongs in the BCD. This PR adds the relevant information to BCD. The general pattern is:
Window
properties (e.g.screenX
) relative to a multi-screen origin.Does this sound accurate, @michaelwasserman?
It would be nice to have more accurate, detailed information on the exact behavior in Firefox, but I'm not sure how to get this without spending a lot of time doing detailed testing. At least this way, readers are warned about the buggy behavior.
Test results and supporting details
Related issues