272897 - Mouse events are not captured after "dragging" the TEXT out of the window.

Status: NEW

(Core :: DOM: Events, defect, P5)

Description

[Dmitry Koterov]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910

Here is the simple script which tries to handle dragging. If you drag empty 
field, all works OK. But if the cursor was above text while start dragging, 
capture becomes broken after leaving the browser window. See sample code below 
and steps to reproduce.

<pre id="test" style="border: 1px solid; width:80%; height: 80%;">
Some text.
</pre>
<script>
    var th = { ii: 0 };
    var span = document.getElementById("test");
    self.addEventListener("mousedown", function(event) {
      event.preventDefault();
      var doc = span.ownerDocument;
      self.status = "Drag started";
      var eMm, eMu;
      addEventListener("mousemove", eMm = function(event) {
        if (!event) event = self.event;
        self.status = "Dragging... " + th.ii++;
      }, true);
      addEventListener("mouseup", eMu = function(event) {
        removeEventListener("mousemove", eMm, true);
        removeEventListener("mouseup", eMu, true);
        self.status = "Drag ended";
      }, true);
    }, true);
</script>

Reproducible: Always
Steps to Reproduce:
1. Push left button inside text area (NOT ONTO TEXT, in blank field!!!).
   Holding button, move mouse out of window edges. You see that
   capture is kept. Release button outside the window - you will see
   "Drag ended" message in status bar. Everything is OK.

2. Now push left button inside text area (ONTO TEXT).
   Holding button, move mouse out of window edges. You see that
   capture is BKOKEN when you have moved the mouse outside the window!
   Release button outside - you will NOT see "Drag ended" message in 
   status bar. And if you then move the mouse into the window (with
   all buttons released) you will see that capture is still in active
   (counter in status bar increases). BAD LUCK!
Actual Results:  
1. Works fine - onmousemove generated even when cursor is outside the window.
2. Capture is broken - onmouseup does not work outside the browser window.

Expected Results:  
When releasing mouse button outside the window, and capture must be in hold. 
Corresponding event has to be generated in all cases, no mattew from where I 
have started dragging.

If I remove event.preventDefault(), all works fine, BUT text is badly selected. 
So I cannot handle dragging fully functionaly.

Comment 1

[Brendan Eich [:brendan]]

Reporter: JavaScript Engine is for core JS language bugs, please file accordingly.

/be

Comment 2

[Wladimir Palant]

Attachment: Reporter's testcase

Comment 3

[Wladimir Palant]

Confirm - the behavior here is inconsistent.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Wladimir, I'm 99% sure this is already filed.  Please find the original and mark
this duplicate.

Comment 5

[Wladimir Palant]

Boris, I've found quite a few bugs dealing with similar issues (bug 78976, bug
136027, bug 175501, bug 180514). It might be that some of them have the same
reasons, but AFAICT they all deal with slightly different problems... Did I miss
something?

Comment 6

[mig]

I have the same problem when attempting to drag my -chrome window
(hidechrome="true") around, using javascript on my background image.

This seems to be a standard errata on Win32 -- unless an HWND has called
SetCapture, you will not get any WM_MOUSEMOVE messages when the mouse is not
over your main OS window.  Hence, your event chain becomes broken at the OS layer.

Some of the native OS ui controls do their own SetCapture during UI handling, so
this bug will seem "intermittant" depending upon how you are testing them.  For
instance, the thumb of a slider properly tracks the mouse (and properly returns
events) even if the mouse is outside of the OS window area.

Some of the bugs cited as possible dupes above are linux only, etc.  It is
possible there are a handful of event-chain bugs to be tracked but this one is
pretty specific.

In the included .xul, dragging on the text will drag the whole moz window around
unless you drag around too quickly and the mouse exits the OS window.

Probably the best place to solve this problem is in your WndProc where you do
your own SetCapture when you handle a mousedown... of course, SetCapture and
Popups like to fight each other, but, hey, whaddaya want from Win32?

mig

Comment 7

[mig]

Attachment: XUL file that allows you to drag the whole window around.

Comment 8

[mig]

Using a global message filter instead of setcapture would work, too.  Still have
to preserve internal state for a condition where you get a mousedown in your
window and a mouseup outside of it, tho.

Comment 9

[meiya]

Emu boots is popurlar increasingly as Ugg boots. They are genuine sheepskin boots. We have all the fashionable styles availably who can help you to got the cheap ugg boots!!
http://www.emu-boots.org/

Comment 10

[Firefox Bug Husbandry Bot]

https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.