Closed Garbee closed 4 years ago
Talked with Mike about this at the meetup yesterday. He confirmed Chrome will force windows into view internally so this API shouldn't need to be exposed. However, we should verify through the design process that any APIs that expose movement (such as moveTo
and moveBy
) do this clamping check so a developer can't pragmatically move a window out of view on purpose.
You raise some valid points, but given the re-framing of the issue with respect to the placement of windows, such discussion is better posed as an issue on the proposed Window Placement API. I'll make sure to call out some thoughts around programmatic placement of windows extending outside the bounds of a single display; there may be valid use cases for placing a window such that it e.g. occupies the full bounds of 2+ displays, but there's less reason and greatly more risk for allowing placement of windows partly outside the union of display bounds. Further consideration is warranted in this space. Regarding the original request for a helper function, my initial reaction is that it's reasonable to leave the behavioral question of "what display is best for showing a window given this screen space point/rect" to the developer - given the right tools. Thanks for your thoughts here!
Chromium has this handy little function internally already. It would be cool to expose this up to the web. So apps can prevent spawning windows off a visible area and move it to the closest available one using the algorithm internally.
I'd need to experiment with this live to see if it's even possible to spawn a window off-screen. (Yes, it is a case some clients specifically requested our software support.) So that kind of thing needs a bit of discussion if it is something the web would even want to support.