603550 - No longer auto-capturing mouse move events on the content window / dragging an jQuery UI draggable element does not work correctly when mouse moves outside the window

Status: RESOLVED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Marios Titas]

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0b6) Gecko/20100101 Firefox/4.0b6
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b6) Gecko/20100101 Firefox/4.0b6

jQuery UI offers a method called draggable that makes any element draggable. In
olders versions of firefox as well as in other browsers (Chrome, Opera), when
the mouse moves outsides the window while an object is being dragged, then the
object continues to move. This doesn't happen under firefox 4.0 beta 6.

The same issue also appears with the draggable method in scriptaculous. You can
verify that with the following demo:
http://wiki.github.com/madrobby/scriptaculous/draggable

When the new (and non-standard methods) setCapture/releaseCapture are called from the mousedown/mouseup events then everything works fine.

Reproducible: Always

Comment 1

[Marios Titas]

Attachment: test case

This is a more simple test case for the problem. It works correctly under the following browsers:
  Firefox 3.0-3.6
  Chrome 4.0+
  Opera 9.2+
but not under Firefox 4. If the 2 lines with the setCapture/releaseCapture calls are re-enabled then it also works under Firefox 4.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Regression range would be great.
Did setCapture implementation cause this or something else?

Comment 3

[Alice0775 White]

Regression range from cached m-c hourly build:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=01fa971e62ee&tochange=0886ad6e6aaa

Local build;
Build from 7804b5cf4313 : testcase Fails
Build from 687b70fea4d0 : testcase Fails
Build from 4722b491cd0d : testcase works

Candidate regression ; Bug 130078

Comment 4

[Markus Stange [:mstange]]

Widgets automatically do mouse capturing. When the content area had its own widget before bug 130078, auto-captured mouse events outside the content area were sent to the document object of the content page. Now that the widget is gone they're only captured on the chrome XUL document and not sent to the content page any more.

http://news.qooxdoo.org/mouse-capturing (from October 2009) says:

> If a mouse button is pressed and dragged out of the browser window, Firefox
> will continue to fire mouse events on the document. Opera, Safari and Chrome
> are a little more tolerant and fire the events on the document.documentElement
> as well.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

The changes how to handle activeESM (bug 582771) should be helpful here.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Attachment: testcase with iframe

This is a case where Gecko and Webkit work the same way but IMHO Opera has
the sane behavior. With Opera it is possible to "drag" the rectangle over
iframe.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Attachment: possible patch (Opera behavior)

If we want to keep the current mouseover iframe behavior, it is enough
to move the code to happen after if (shell != this) { }

About to post the patch to tryserver.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 483442 [details] [diff] [review]
possible patch (Opera behavior)

Oops, the patch breaks event targeting somehow.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Attachment: testcase with 2 iframes

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

Attachment: drag inside an iframe page

Webkit doesn't like this one. It behaves inconsistently depending on where the
mouse is.
Opera works well.

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Attachment: patch

Targets events to (i)frame if mouse is over a subdocument, and
to document if mouse is outside the document presentation.
IMHO targeting document.documentElement doesn't make much sense
if mouse is actually outside of its presentation.

So this brings back the old behavior when mouse is outside the document, 
but adds new Opera-like behavior when mouse is over a subdocument.

Mochitests are still needed.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

It seems that test_selection_expanding.html doesn't like the patch. Investigating.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

Perhaps for FF4 it would be better to not change behavior, and just
leave the (i)frame handling the way it is.

Comment 14

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I don't really understand what's going on here. Are you suggesting we do nothing for FF4? Can you be more precise about what this patch actually does?

Comment 15

[Olli Pettay [:smaug][[e-mail]]]

sorry, I should have cleared the review request.
I'm suggesting that we take the part of the patch which handles
the case when mouse moves outside the
"active" document. But no need to change how
moving mouse over iframe works.
That approach should give us ff3.6 behavior.

post ff4 we could fix mouse-over-iframe to work
like in Opera.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 483475 [details] [diff] [review]
patch

OK, so I guess you're going to attach a new patch.

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

Attachment: patch

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

(Still missing mochitests, which I need to write before pushing the patch -
if the patch gets a review)

Comment 19

[Olli Pettay [:smaug][[e-mail]]]

Attachment: +test

Comment 20

[Olli Pettay [:smaug][[e-mail]]]

http://hg.mozilla.org/mozilla-central/rev/154f493a36dc

Comment 21

[Alice0775 White]

Broken again.

Works;
http://hg.mozilla.org/mozilla-central/rev/6e70eb8a5271
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101020 Firefox/4.0b8pre ID:20101020092853
Broken;
http://hg.mozilla.org/mozilla-central/rev/91a2567620be
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101020 Firefox/4.0b8pre ID:20101020110243
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=6e70eb8a5271&tochange=91a2567620be
Regressed by Bug 605242 - No :active state for <button>

Should I filed separately? OR Reopen this?

Comment 22

[Olli Pettay [:smaug][[e-mail]]]

I think I'll backout this and the rest of bug 605242.

Comment 23

[Olli Pettay [:smaug][[e-mail]]]

Oh, the regression was a silly mistake when commitin, I think. Fixing.

But I may still backout this one to get the d-n-d/clicking working again
properly on Windows.

Comment 24

[Olli Pettay [:smaug][[e-mail]]]

Btw,
Alice, thanks for testing this all!

Comment 25

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #23)
> Oh, the regression was a silly mistake when commitin, I think. Fixing.
Er, no. It is needed after all.
Uh, it is a bit difficult to emulate the used-to-be-handled-by-native-widget
things. Still investigating..

Comment 26

[Olli Pettay [:smaug][[e-mail]]]

And the reason why the test didn't capture the regression is that the
test doesn't check whether preventDefault() affects to the mouse event
handling in this case.
My bad.