New 'onmove' event handler for the Window object

[javifernandez]

Request for Mozilla Position on an Emerging Web Specification

• Specification title: New 'onmove' event handler for the Window object
• Specification or proposal URL (if available): https://github.com/w3c/csswg-drafts/pull/9664
• Explainer URL (if available): https://github.com/Igalia/explainers/blob/main/onmove-event-handler/README.md
• Proposal author(s) (@-mention GitHub accounts):
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional): @emilio

Other information

The main goal of this feature is to provide web authors a mechanism to track and control the position of the Window object.

The feature would probably involve both, the HTML spec and the CSSOM View Module which defines the Window's attributes exposed to describe its size and position.

There is an ongoing discussion in the CSS issue 7693 about potential approaches for its implementation and the most appropriated standard venue.

[emilio]

So I don't think this is terribly problematic in the sense that screenX/Y already expose this information. However:

• @smfr / @othermaciej's comments are true, that in general the less information we expose about this the better. Maybe we should consider nerfing those attributes altogether by default...

• There are window protocols (like Wayland) where that information is already not exposed / not controllable, and I think it's unfortunate to introduce new APIs that can't work everywhere... Also it's unclear what this should do on android tbh.

@martinthomson / @zcorpan / @smaug---- / @tantek: thoughts on this?

[emilio]

cc @tomrittervg since Tor does spoof these already.

[zcorpan]

CSSOM View allows hiding window positioning. If browsers were to start doing so (as there seems to be interest from WebKit), then adding the event would be pointless.

[zcorpan]

For the use case mentioned in https://github.com/Igalia/explainers/blob/main/onmove-event-handler/README.md#motivation

One potential use case for a feature like this would be to allow a popup dialog opened by a window to keep its relative position with its parent.

It seems to me that the synced window position would be jarring as you move the main window because of the latency of an event. If popup position syncing is important, maybe the browser should do that instead and authors can request position syncing in window.open()'s features argument?

[smaug----]

yeah, I don't think event is a good for synced windows, and what other use cases are there?

[martinthomson]

To @emilio's point, I'd be supportive of moves to cut back screenX/screenY. I can't see any real value in it, other than managing window.open() placement features (which should also be cut at the same time). Pairing that with improved placement features might be better, but I wouldn't hold back on that basis. As our friends at Apple say, sites need to get more comfortable with the space they have been given.

[sonkkeli]

Hey, Wondering if you have noticed our Additional Windowing Controls proposal: https://github.com/mozilla/standards-positions/issues/712 ? :) Sounds like you're thinking of similar API as one of the ones suggested there.

[javifernandez]

Thank you all for the feedback. I can understand the low interest on the proposal when it's analyzed in the context of the privacy issue of exposing information about the Window's position.

However, I'd like know whether there are enough arguments to be against it, considering the new API doesn't makes the situation worse. Es @emilio pointed out, the information is already exposed to web content. The API may become useless engines that decide to silent those attributes, but it definitively won't cause any problem in those cases, neither performance or privacy related.

The point about the lack of capabilities to control the position attributes in some window protocols, like Wayland, is valid, but it's the same than the one about engines choosing to avoid updating the position attributes. Hence, this new API will be useful for the engines and window systems willing or capable of exposing the positional information, and I think this is still an interesting use case for web authors.

On the other hand, an event based solution has clear advantages against polling, especially when it comes to battery life.

[smaug----]

What are the use cases for the move event, other than "keep its relative position with its parent"? The explainer could perhaps be a bit more detailed in its motivation part.

[javifernandez]

Hey, Wondering if you have noticed our Additional Windowing Controls proposal: #712 ? :) Sounds like you're thinking of similar API as one of the ones suggested there.

Indeed, in that proposal it's suggested the need of a new event to control changes in the Window's position.

[javifernandez]

What are the use cases for the move event, other than "keep its relative position with its parent"? The explainer could perhaps be a bit more detailed in its motivation part.

I admit the explainer needs more work on that regard; I`ll try to provide more use cases there. It seems there are some examples in the proposal commented by @sonkkeli, that perhaps could help to clarify the need of this new API.

[smaug----]

Based on the last comment we're still waiting for more information here.