591815 - event.preventDefault() in mousedown doesn't work on an img element that has been appended to a different element

Status: RESOLVED FIXED

(Core :: DOM: Events, defect)

Description

[mattga]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b4) Gecko/20100818 Firefox/4.0b4
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b4) Gecko/20100818 Firefox/4.0b4

If an element is appended to another element using appendChild() inside of a mousedown event handler, and the mouse is over an img element, you can't use event.preventDefault() to prevent the default dragging behavior.

Reproducible: Always

Steps to Reproduce:
1. Open http://jsbin.com/ahuce3/4 in Firefox 4 Beta
2. Try clicking and dragging the 2nd firefox logo

Actual Results:  
The element is dragged.

Expected Results:  
The element should not have been dragged.

Webkit based browsers and Firefox 3.6 correctly disable the dragging of the element.

Comment 1

[Nickolay_Ponomarev]

Attachment: testcase from the reporter

Comment 2

[Nickolay_Ponomarev]

I can reproduce this regression on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:2.0b6pre) Gecko/20100904 Firefox/4.0b6pre (works in Firefox 3.6.8)

Comment 3

[Neil Deakin]

This isn't specifically drag related. nsEventStateManager::PostHandleEvent never gets called when the element is moved so there isn't any default behaviour handling to prevent.

Comment 4

[mattga]

I believe this link shows another symptom of the same problem: http://jsbin.com/efowe4/9

Comment 5

[Alice0775 White]

Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/021bf8e64199
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100413 Minefield/3.7a5pre ID:20100416094911
Fails:
http://hg.mozilla.org/mozilla-central/rev/935bb616b8a6
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a5pre) Gecko/20100413 Minefield/3.7a5pre ID:20100416121540
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=021bf8e64199&tochange=935bb616b8a6
Candidate bug:
Bug 502937 - (lazyfc) Consider doing lazy frame construction

Comment 6

[Johnny Stenback (:jst)]

Timothy, can you look into this regression, from the above comment this could be fallout from your lazy frame construction work...

Comment 7

[Timothy Nikkel (:tnikkel)]

At the start of nsEventStateManager::PostHandleEvent we bail if there is no current (frame) target and the event is not a mouse button up, so we never reach the StopTrackingDragGesture() call that happens for mouse downs in that function when the event status is consume no default. There is not current target frame when we post handle the event because the event handler moves the content node, so we eagerly delete the frame, and lazyily recreate it.

So I think we just need to not bail for mouse down events at the start of PostHandleEvent.

Comment 8

[Timothy Nikkel (:tnikkel)]

Attachment: patch

Comment 9

[Damon Sicore (:damons)]

What's next here?  Is this ready to land?

Comment 10

[Timothy Nikkel (:tnikkel)]

Yes, but the tree is restricted to beta7 blockers.

Comment 11

[Timothy Nikkel (:tnikkel)]

http://hg.mozilla.org/mozilla-central/rev/c6c3db22a0d2