[e10s] Screen coordinates on the "dragend" event stopped working with e10s

RESOLVED FIXED in Firefox 48

Status

()

defect
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: thibaut, Assigned: mrbkap)

Tracking

Trunk
mozilla49
Unspecified
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(e10s?, firefox48 fixed, firefox49 fixed)

Details

(Whiteboard: dom-triaged)

Attachments

(4 attachments, 1 obsolete attachment)

Reporter

Description

3 years ago
Posted file test.html
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160127070712

Steps to reproduce:

Create an element with the draggable attribute set to true. Listen to the dragstart and dragend events.


Actual results:

On the dragend event, the event.screenX and event.screenY values are always zero.


Expected results:

event.screenX/Y should report the cursor coordinates. The test file works on FF 43 (can't test 44).

Note that there is a larger issue here (https://bugzilla.mozilla.org/show_bug.cgi?id=505521), which is that pageX/clientX/screenX don't work on drag events. "screenX" on dragend is the only one that used to work. With this bug it's now impossible to implement any kind of UI drag feature (like resizing) in Firefox using the Drag & Drop API.

A fix would be much appreciated.

Thanks.

Comment 1

3 years ago
could you attach results of about:support?
Flags: needinfo?(thibaut)
Reporter

Comment 2

3 years ago
Reporter

Comment 3

3 years ago
Flags: needinfo?(thibaut)

Comment 4

3 years ago
I can reproduce the problem with e10s.
Blocks: 936092
Status: UNCONFIRMED → NEW
tracking-e10s: --- → ?
Ever confirmed: true
OS: Unspecified → All
Summary: Screen coordinates on the "dragend" event stopped working in FF45 → [e10s] Screen coordinates on the "dragend" event stopped working
Version: 45 Branch → Trunk

Updated

3 years ago
Summary: [e10s] Screen coordinates on the "dragend" event stopped working → [e10s] Screen coordinates on the "dragend" event stopped working with e10s
Reporter

Comment 5

3 years ago
Right, didn't notice the A/B test. Good to know that this won't break when FF45 is released. Thanks!

Comment 6

3 years ago
> With this bug it's now impossible to implement any kind of UI drag feature (like resizing) in Firefox using the Drag & Drop API.

As an aside, resizing a UI element isn't something you would use the drag and drop API for.
Reporter

Comment 7

3 years ago
(In reply to Neil Deakin from comment #6)
> As an aside, resizing a UI element isn't something you would use the drag
> and drop API for.

Why not? It works perfectly in all browsers that implement the DND API, except Firefox.

The only alternative I'm aware of is to use mousedown/mousemove/mouseleave, which requires more code. The spec even says:

> On a visual medium with a pointing device, a drag operation could be the default action of a mousedown event that is followed by a series of mousemove events, and the drop could be triggered by the mouse being released.

http://www.w3.org/html/wg/drafts/html/master/editing.html#dnd

PS: honestly don't mean to complain. I love the work you're doing, especially with e10s.

Comment 8

3 years ago
The dragend coordinate is set in the parent process by calling nsIDragService::SetDragEndPoint. nsBaseDragService::FireDragEventAtSource then assigns it to event.refPoint just before firing the event. This will need to get transferred over when propagating the dragend event to the child process. Maybe smaug can indicate the best way to do this?
Flags: needinfo?(bugs)
Whiteboard: dom-triaged
waited to long, kickingt his back into triage.
Flags: needinfo?(bugs)
Sorry, I process needinfos in general once I have time between review requests. And I've been behind the review queue for weeks now.
Flags: needinfo?(bugs)
Niel, do you think this is something that should block e10s?
Flags: needinfo?(enndeakin)

Comment 12

3 years ago
It regressed functionality and one cannot receive event coordinates at the source when the drop is complete, so it would be good to fix it.
Flags: needinfo?(enndeakin)
Hey Blake - I _think_ it sounds like we need to just send the mouse coordinates down to the content along with the message that dispatches the dragend event. Does that sound right? (smaug is swamped). If so, where does that message get sent, do you know?
Flags: needinfo?(mrbkap)
Posted patch Fix (obsolete) — Splinter Review
In investigating this bug, I ended up writing the fix.
Attachment #8754060 - Flags: review?(enndeakin)
Assignee: nobody → mrbkap
Flags: needinfo?(mrbkap)
Flags: needinfo?(bugs)

Comment 15

3 years ago
I get build errors with this patch due to a caller of SendEndDragSession in nsBaseDragService.cpp not being updated.
Posted patch Fix v1.1Splinter Review
Sorry, I forgot to add that directory to the patch.
Attachment #8754446 - Flags: review?(enndeakin)
Attachment #8754060 - Attachment is obsolete: true
Attachment #8754060 - Flags: review?(enndeakin)

Updated

3 years ago
Attachment #8754446 - Flags: review?(enndeakin) → review+

Comment 18

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/937ab6cd1b48
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
Comment on attachment 8754446 [details] [diff] [review]
Fix v1.1

Approval Request Comment
[Feature/regressing bug #]: n/a
[User impact if declined]: Certain web sites won't work with e10s.
[Describe test coverage new/current, TreeHerder]: Not good test coverage.
[Risks and why]: Low risk, adds existing information to an existing event, using existing IPC channels.
[String/UUID change made/needed]: n/a
Attachment #8754446 - Flags: approval-mozilla-aurora?
Comment on attachment 8754446 [details] [diff] [review]
Fix v1.1

Improve e10s, taking it
Attachment #8754446 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.