A way to get mouse coordinates without mouse moving

[oleedd]

What problem are you trying to solve?

Getting mouse coordinates at some concrete moment.

What solutions exist today?

No response

How would you solve it?

For example, something like navigator.mouse.clientX, navigator.mouse.clientY.

Anything else?

No response

[nektro]

could you elaborate more on the intended use case?

[oleedd]

No mouse moving. The task is to determine over which element the cursor is. It is impossible.

[nektro]

that doesn't explain the why

[oleedd]

Because your code can't wait for some event. You need the coordinates right away.
And because setting an event listener and removing it just to get coordinates is a bit stupid.

[pshaughn]

It's possible for a page to lose focus and then regain focus with the mouse in a different position, without receiving any mouse event about the position change. For example, in Firefox on Cinnamon, pressing the Win/Super key, moving the mouse, and pressing Escape will do this.

I can think of a cosmetic use case for detecting such a position change: if the page is using Javascript to animate a cursor, the animation won't match the real cursor position until a mouse event comes in.

However, this use case could be supported by just guaranteeing mousemove events in more situations, rather than adding a whole different API. I can't think of any actual use case for a separate API.

[oleedd]

navigator.mouse.clientX and navigator.mouse.clientY should use getters to get the coordinates at some moment (very easy in c++ without any mouse movements). So it is not about much frequent updates than mousemove.
And it is very good for the use case you described.
Adding an event listener and removing it just to get coordinates once is a really bad way, very bulky. And bad performance. But only this way is available. And it requires waiting for an event.

[pshaughn]

You'll have to explain your actual use case if you want anyone to follow along. Why would you simultaneously:
(1) only want the coordinates just once,
(2) in code that's being triggered by an event that isn't a MouseEvent, and
(3) in a context where the performance cost of an event handler is meaningful?

[oleedd]

To use elementFromPoint() once.
For example, triggered by a keyboard event. No mouse moving.
A good developer has to always think about performance because it consists of grains. But the bulkiness is more annoying.

[BlobTheKat]

Many low level libraries will expose mouse cursor by events. The issue here is not that the cursor position isn't accessible from anywhere but that no mouse event occurs when the tab is refocused. I believe I have seen it mentioned elsewhere that not being able to see the mouse position before the user has hovered over the tab is intentional and will not be addressed.

Rather than set up and event listener to delete it again, keep one event listener on and use it to update a variable that you can read at any time.

[oleedd]

Yes, events are generated only when the cursor is inside the page. Because we use window.addEventListener or document.addEventListener and then the cursor is outside document and window. So it is logical. And navigator.mouse.clientX, navigator.mouse.clientY may work in such cases. But I don't see why getting coordinates may be needed when it is outside.

Rather than set up and event listener to delete it again, keep one event listener on and use it to update a variable that you can read at any time.

It is very bad. To handle events a whole day to use it several times. These events consume a lot of performance. 1 more reason to add this.

[pshaughn]

Have you measured this performance change?

[oleedd]

Yes, the cursor lags a bit.

[pshaughn]

From my own experiences, I believe it far more likely that whatever lag you're observing is a symptom of some performance bug in your code, or some misunderstanding of how to use events, not because of the performance cost of one simple mousemove handler.

Implementers (Apple, Google, Mozilla) rarely add new API just for performance reasons, and certainly not without data. If there actually is an issue here (which I'll admit I continue to doubt), you'll need to show a reproducible, measurable demonstration of the problem, not an anecdote.