dragover event under Linux is not following MDN specification
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
People
(Reporter: aafnbugzilla.map1bid, Unassigned, NeedInfo)
References
Details
(Keywords: platform-parity)
Attachments
(4 files)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:65.0) Gecko/20100101 Firefox/65.0
Steps to reproduce:
Under Linux on FF, subscribe to the dragover event on an HTML object.
E.g.
xxx.addEventListener("dragover", bkmkDragOverHandler);
Actual results:
When dragging something over the object, and leaving the pointer still (immobile) above it while keeping the drag button pressed, only one dragover event is received and then no more.
More dragover events are only received when moving the pointer, but not when staying still.
This means there is no 100% safe way to know when the pointer gets away from the element, in order to stop any particular thing we want to activate on the element while it is under drag (like highlighting it or a border or ..).
Indeed, under some circumstances, the dragleave and dragexit events do not fire when leaving. I guess I should open another bug for that, but lets fix the dragover thing first ..
So to 100% know that the drag pointer is not anymore on the element, I am relying on dragover frequency and timeouts on it to detect when the drag is not on the element anymore and restore things on it.
This is not working on Linux.
Note: since no mousexxx and pointerxxx events are reaching the object when there is a drag on it (I guess the drag implementation does a pointrId capture ...), there is no easy workaround available.
Expected results:
The dragover event should fire around every few hundred ms as per MDN specs
https://developer.mozilla.org/en-US/docs/Web/Events/dragover
This -> https://developer.mozilla.org/en-US/docs/Web/Events says it should be "every 350ms".
As for W3 specs, I can read this is around every 350 +/- 200 ms.
It does happen like that under Windows.
It does not under Linux, as said only 1 event is sent.
Updated•6 years ago
|
Comment 1•6 years ago
|
||
As this is a linux issue, I'm guessing widget component would be a better fit.
Updated•3 years ago
|
Comment 2•18 days ago
|
||
I am not sure the issue from the description is the actual cause for the stuck scrolling in bug 1850788, but that problem is easily reproduced using the example from https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/dragover_event: Just add <div style="height: 200vh"></div> as line 4 of the HTML code and observe dragging the item behaving differently under Windows and Linux.
Martin, could you offer any insight on this?
Comment 3•17 days ago
|
||
I don't use Windows - so what's different on Linux? You can get toolkit level D&D log by running with MOZ_LOG="WidgetDrag:5" env variable to get more info what's going on.
Comment 4•17 days ago
|
||
Comment 5•17 days ago
|
||
Comment 6•17 days ago
|
||
Comment 7•17 days ago
|
||
Comment 8•17 days ago
|
||
(In reply to Martin Stránský [:stransky] (ni? me) from comment #3)
I don't use Windows - so what's different on Linux? You can get toolkit level D&D log by running with MOZ_LOG="WidgetDrag:5" env variable to get more info what's going on.
It's about the behavior when you drag over the lower end of the viewport in order to trigger scrolling. On Windows, scrolling continues while remaining at the same point, while on Linux, you have to wiggle the mouse pointer, otherwise scrolling stops. Please see the attached screen recordings, along with their corresponding WidgetDrag/WidgetDragService logs.
Description
•