Closed
Bug 1244533
Opened 8 years ago
Closed 8 years ago
[e10s] Screen coordinates on the "dragend" event stopped working with e10s
Categories
(Core :: DOM: Copy & Paste and Drag & Drop, defect)
Tracking
()
RESOLVED
FIXED
mozilla49
People
(Reporter: thibaut, Assigned: mrbkap)
References
Details
(Whiteboard: dom-triaged)
Attachments
(4 files, 1 obsolete file)
628 bytes,
text/html
|
Details | |
5.06 KB,
text/plain
|
Details | |
4.68 KB,
text/plain
|
Details | |
6.75 KB,
patch
|
enndeakin
:
review+
Sylvestre
:
approval-mozilla-aurora+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 2•8 years ago
|
||
Reporter | ||
Comment 3•8 years ago
|
||
Flags: needinfo?(thibaut)
Comment 4•8 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•8 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•8 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•8 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•8 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•8 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)
Updated•8 years ago
|
Whiteboard: dom-triaged
Comment 10•8 years ago
|
||
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)
Comment 11•8 years ago
|
||
Niel, do you think this is something that should block e10s?
Flags: needinfo?(enndeakin)
Comment 12•8 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)
Comment 13•8 years ago
|
||
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)
Assignee | ||
Comment 14•8 years ago
|
||
In investigating this bug, I ended up writing the fix.
Attachment #8754060 -
Flags: review?(enndeakin)
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → mrbkap
Flags: needinfo?(mrbkap)
Flags: needinfo?(bugs)
Comment 15•8 years ago
|
||
I get build errors with this patch due to a caller of SendEndDragSession in nsBaseDragService.cpp not being updated.
Assignee | ||
Comment 16•8 years ago
|
||
Sorry, I forgot to add that directory to the patch.
Attachment #8754446 -
Flags: review?(enndeakin)
Assignee | ||
Updated•8 years ago
|
Attachment #8754060 -
Attachment is obsolete: true
Attachment #8754060 -
Flags: review?(enndeakin)
Updated•8 years ago
|
Attachment #8754446 -
Flags: review?(enndeakin) → review+
Comment 18•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/937ab6cd1b48
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox49:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
Assignee | ||
Comment 19•8 years ago
|
||
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?
Updated•8 years ago
|
status-firefox48:
--- → affected
Comment 20•8 years ago
|
||
Comment on attachment 8754446 [details] [diff] [review] Fix v1.1 Improve e10s, taking it
Attachment #8754446 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment 21•8 years ago
|
||
bugherder uplift |
https://hg.mozilla.org/releases/mozilla-aurora/rev/5f53adc1bdfa
You need to log in
before you can comment on or make changes to this bug.
Description
•