New 'onmove' event handler for the Window object

[javifernandez]

WebKittens

@annevk @smfr

Title of the spec

window.onmove

URL to the spec

https://html.spec.whatwg.org/multipage/webappapis.html#event-handlers-on-elements,-document-objects,-and-window-objects

URL to the spec's repository

https://github.com/whatwg/html

Issue Tracker URL

No response

Explainer URL

https://github.com/Igalia/explainers/blob/main/onmove-event-handler/README.md

TAG Design Review URL

No response

Mozilla standards-positions issue URL

https://github.com/mozilla/standards-positions/issues/938

WebKit Bugzilla URL

No response

Radar URL

No response

Description

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.

[smfr]

In general adding more API around window positions is not something WebKit is very interested in. I think we should trend in the other direction: web content has no business knowing about how I arrange my browser windows. We should discourage authors from using popup windows, and instead direct them to use HTML dialogs and popups.

[othermaciej]

I agree with Simon. We should move towards hiding window position entirely, and doing what we can to obscure window size, as there are excessively powerful cross site fingerprinting signals.

[javifernandez]

Thank you for the feedback. I understand the concerns about privacy caused by exposing the Window's position to the web content. I think I´d need to reflect more about them in the explainer and try to make the proposal more robust on this regard.

I admit that the interest on this feature may be low, considering it goes in the opposite direction to what Safari plans for the Window's position and size attributes. However, I wonder if the given arguments are enough to oppose to the proposal.

First of all, since the information is already exposed, the even is not making the privacy breach bigger. Since the CSSOM View Module already allows UA to hide information about the screen, the event might be never triggered but it doesn't have any negative impact in terms of performance or privacy.

On the other hand. for the engines and window systems willing to expose the information, an event based approach has considerable advantages against polling.

[annevk]

What we are saying is that the information exposure is a bug to be fixed, not a feature to be celebrated.

[javifernandez]

The statement in the Security and Privacy considerations has been merged not so long ago, and the issue has been discussed recently in the CSS WG. As far as I know there are no plans to remove or even deprecate the attributes, so the browser's choice of hiding the information still stands as the best fix to such potential bugs.

For the browsers willing to, and OSs capable of, updating the CSSOM View attributes a new event could be seen as a way to warn users and/or web authors about that information exposure and implement features (even privacy related) they want in a more efficient way. In any case, the new event is not making the potential privacy breach bigger.

[marcoscaceres]

We can probably glean a position from the feedback above, which seems to be “opposed”.