Drag events out of order

RESOLVED FIXED in mozilla2.0b8

Status

()

Core
Drag and Drop
RESOLVED FIXED
8 years ago
7 years ago

People

(Reporter: Daniel Bates, Assigned: Neil Deakin (away until Feb 4))

Tracking

({html5})

Trunk
mozilla2.0b8
html5
Points:
---

Firefox Tracking Flags

(blocking2.0 betaN+)

Details

Attachments

(2 attachments)

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3

The drag-and-drop processing model used in Firefox does not conform to section 7.9.4 of the HTML 5 spec. <http://dev.w3.org/html5/spec/Overview.html#drag-and-drop-processing-model>. In particular, the order of dragenter and dragleave events are reversed in Firefox. That is, Firefox fires dragleave then dragenter, but it should be dragenter then dragleave.

This issues is similar to an drag event ordering issue in WebKit bug #30754 <https://bugs.webkit.org/show_bug.cgi?id=30754>.

Reproducible: Always
(Reporter)

Comment 1

8 years ago
Created attachment 411490 [details]
Test case

Test case derived from a similar WebKit test.
Confirmed on trunk.
Status: UNCONFIRMED → NEW
Component: General → Drag and Drop
Ever confirmed: true
Keywords: html5
OS: Mac OS X → All
Product: Firefox → Core
QA Contact: general → drag-drop
Hardware: x86 → All
Version: unspecified → Trunk
Probably a quick fix for somebody familiar with the code and an HTML5 compliance win.  Nominating for blocking.
blocking2.0: --- → ?

Comment 5

8 years ago
need a dupeme maybe, But also I think trunk is correct.

Comment 6

8 years ago
oops sorry missed comment 2

Comment 7

8 years ago
Enn, can you take this? (And hopefully get a test into the HTML test suite, if such a thing exists.)
Assignee: nobody → enndeakin
blocking2.0: ? → betaN+
(Assignee)

Comment 8

7 years ago
Created attachment 492371 [details] [diff] [review]
Patch

This patch moves the dragleave event to fire after the dragenter event. For developers that want the more sensible event order, including the places in browser, editor and toolbar customization code, the dragexit event still fires before the dragenter event as before.

The event order then is:
  dragexit, dragenter, dragleave

Can't be tested automatically. Works with the testcase.
(Assignee)

Updated

7 years ago
Attachment #492371 - Flags: review?(Olli.Pettay)
(Assignee)

Updated

7 years ago
Attachment #492371 - Flags: review?(dao)

Updated

7 years ago
Attachment #492371 - Flags: review?(dao) → review+
Whiteboard: [needs review smaug]

Comment 9

7 years ago
This is rather strange. Why should dragenter fire before dragleave?
Is this something that IE does always? I guess I need to test IE.

Could we just change HTML5 draft?
(Assignee)

Comment 10

7 years ago
IE always fires dragenter before dragleave. About a year ago, Webkit was changed to this behaviour as well.

Changing our behaviour could have compatibility issues for us which is why I had to change code to use the dragexit event.

Likely though, there would be less of a problem to go from the IE behaviour to our behaviour as I can't see why the unusual event order would be useful and relied on.
Yeah the IE behaviour (and thus the spec) is pretty nutty here.

dropexit seems like a reasonable idea; if you'd like it formalised and specced please feel free to mail the WHATWG list mentioning it.

Updated

7 years ago
Attachment #492371 - Flags: review?(Olli.Pettay) → review+
(Assignee)

Updated

7 years ago
Keywords: checkin-needed
Whiteboard: [needs review smaug]

Comment 12

7 years ago
http://hg.mozilla.org/mozilla-central/rev/d11d8ac9ffe3
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
No longer blocks: 467530
You need to log in before you can comment on or make changes to this bug.