Open frivoal opened 1 year ago
AFAIK the resize
event can easily be awful for perf since it's sync and fires lots of times during the resize.
It seems move
would have the same problem. An async observer may be a better idea?
Resize doesn't fire sync afaik (though it fires very frequently). In any case the other potential issue I see is that the window resize event fires everywhere (like iframes) but we probably don't want that here. Resize reflects inner size, but it seems here you are interested in outer window position (not inner one).
An async observer would be equaly fine for the usecase, and preferable if that enables better performance.
The point about iframes is interesting. I suppose tracking the inner position would be a security issue as it would leak information about the parent content, but I don't think tracking the outer window position would be an issue, would it? If it is, I suppose it's an acceptable restriction for this to just not work from within iframes.
I guess in iframes it should just track changes to the screenLeft
or screenTop
of the iframe's contentWindow? Which seem to be the same values as for the top window.
A use case for doing this is when a parent page pops up an child window, and wants to keep it positioned to a particular spot relative to the parent window.
I had a play with doing something like this, and discovered that not being able to make an always-on-top popup window (is there a way to do this that I've missed?) makes the tracking popup case pretty limited in usefulness. (It might be useful if you have a popup that doesn't overlap its parent, I guess?)
https://people.igalia.com/alice/test/popup/
Also, writing the logic to position the popup relative to the window was extremely involved, and it still only sort of works, and seems to be subtly different between browsers and operating systems.
How realistic is a tracking popup window as a use case?
(It might be useful if you have a popup that doesn't overlap its parent, I guess?)
The case I had heard of was that indeed. It kept windows docked next to each other, and had the "side panel" windows follow the main one.
I do agree that this is a little convoluted, and fraught with cross-platform challenges. At the same time, we do expose that information already, so it's not really a question of whether to have the ability at all. Given that we do have it, and that people occasionally do use, if it wouldn't be terribly difficult to expose an observer, that could be a cheap boost to performance / battery life.
Sure, that makes sense. I could see it being something that's specced with reference to the web-exposed screen area, so user agents may make the same choices with regard to what precisely is exposed as they do in that case.
I spent some time looking in to this lately, particularly the observer/event question.
The TAG design principles do include guidance on this specific issue (and there was an earlier discussion thread):
In general, use EventTarget and notification Events, rather than an Observer pattern, unless an EventTarget can’t work well for your feature.
...
If using events causes problems, such as unavoidable recursion, consider using an Observer pattern instead.
This seems to me to indicate that an event is probably what we want here. I'm not sure what we'd gain from having this be an Observer instead.
I see that in Blink, resize
fires at most once per animation frame, and that seems like a good design particularly for this use case, since the point is to have a secondary window "follow" the main window around.
I'm not sure exactly where this discussion landed on iframes - would iframes not have window.move events fired at all, or would they fire when the top window moves?
I'm planning to start writing some tentative WPT tests to cover my exploratory implementation; should I also have a go at writing some spec language, or would someone else like to take that?
I'm not sure what we'd gain from having this be an Observer instead.
The suggestion was that it would have better performance characteristics. If an Event can be performant, that's just as well in my book.
I'm not sure exactly where this discussion landed on iframes - would iframes not have window.move events fired at all, or would they fire when the top window moves?
I am not sure we concluded with certainty. I think firing when the top window moves gives a bit more power if it doesn't bring excess complexity. As long as we don't fire when the iframe itself gets resized / moved by within parent document, I think we avoid cross site security problems.
should I also have a go at writing some spec language, or would someone else like to take that?
It's probably fresh in your mind, so I think it would make sense if you wrote it, in which case I'd be happy to review. But if you'd prefer the other way around, I'm happy to oblige.
I finally managed to have a go at writing some spec text for this. I more or less copied the strategy used by the resize event: hooking directly into the event loop such that the event fires at most once per frame.
The CSS side is here, and the HTML side is here.
@frivoal If you could take a first look at those and let me know if you have any feedback on the text, I can make any edits you think might be needed and then make some more formal PRs, if we feel like this is a good direction.
@alice I just reviewed your proposed text, and this does look good to me. Simple and to the point.
Given the WHATWG's policies, I don't know if HTML would land this prior to having 2 implementations, which might make it a little tricky temporarily from a spec dependency point of view: assuming the CSSWG supports your edits, our approach would be to land your PR into a draft prior to implementations existing, so that the spec can guide those implementations. But only landing the CSS half without the HTML half doesn't make much sense here.
If we accept this, I wonder if we should temporarily monkey-patch HTML, describing the change we would make to HTML in the CSS spec, until HTML itself lands it, at which point we could remove that from the CSS side. Luckily the change to HTML is minimal. We should probably ask the WHATWG how they prefer to deal with this.
Hi @frivoal
@alice I just reviewed your proposed text, and this does look good to me. Simple and to the point.
If we accept this, I wonder if we should temporarily monkey-patch HTML, describing the change we would make to HTML in the CSS spec, until HTML itself lands it, at which point we could remove that from the CSS side. Luckily the change to HTML is minimal. We should probably ask the WHATWG how they prefer to deal with this.
I took over the work @alice has been doing here and, following your advice, I created the PR 9664, adding a reference to the HTML event loop there.
Also, I'll try to gather opinions from the WHATWG on whether they think there is a better approach to integrate the changes in both specs.
@javifernandez @alice IMO it's better to make the change in both specs directly (assuming no opposition to add the event).
The CSS Working Group just discussed [cssom-view] No event to track window position
, and agreed to the following:
RESOLVED: Pursue event to make tracking window position more ergonomic
@javifernandez @alice IMO it's better to make the change in both specs directly (assuming no opposition to add the event).
The problem is that PRs for the HTML spec would require 2 implementations, and as far as I know only Chrome is interested for now.
JFYI, tests have been added at https://github.com/web-platform-tests/wpt/pull/44020
The window object exposes attributes to find the position (and size) of the window. However, there are no corresponding event, so anyone interested in tracking these must do so by actively polling, which is wasteful and/or laggy, depending on how frequently you poll.
A use case for doing this is when a parent page pops up an child window, and wants to keep it positioned to a particular spot relative to the parent window. That's currently doable, but it takes active polling. Being able to switch to an event would be good.
We already do have the resize event on the Window object, but that only solves half the problem, as there's no equivalent for the position.
So, can we get
to go along with
?
cc: @emilio @mrego