Opened 12 years ago

Closed 12 years ago

#10749 closed defect (fixed)

BorderContainer: stuck in drag mode if mouse-up occurs off browser window

Reported by: dcbarans Owned by: bill
Priority: high Milestone: 1.5
Component: Dijit Version: 1.4.0
Keywords: bordercontainer splitter Cc:
Blocked By: Blocking:


If you start dragging the Splitter in a Border Container and you drag it out of the browser window it will not render the content properly anymore.

Change History (5)

comment:1 Changed 12 years ago by Craig Baker

More specifically: when you drag the splitter outside of the browser window and release the mouse the splitter is still dragging. I'm looking into watching for an onmouseleave event and canceling the splitter drag.

comment:2 Changed 12 years ago by Craig Baker

Ok so around line 550 of BorderContainer?.js (in the splitter code, bottom of startDrag) we could add in this:

		this.windowMouseOut = dojo.connect(
				if( == dojo.body().parentNode){

and to make sure the connection is cleaned up put something like this around line 590 (bottom of stopDrag):

		if(dojo.isArray(this.windowMouseOut)&& this.windowMouseOut[0] != undefined){

This may not be the best way to handle the disconnects, and the variable name windowMouseOut might not be the best place to store the connection, but thats it.

comment:3 Changed 12 years ago by abird

This same bug can be reproduced when using a BorderContainer? inside an iframe.

While dragging the splitter, if you move the mouse outside the iframe, the BorderContainer? will still show the splitter. If you release your mouse pointer outside the iframe, the splitter will still be present. If you then move your mouse back inside the iframe, and inside the BorderContainer? , the splitter will follow your mouse pointer even though your mouse button is not pressed. If you click, a new _startDrag event fires, and everything gets messed up.

As a solution, I have put this as the first line in _startDrag:

if (dojo.hasClass(this.domNode, "dijitSplitterShadow")){return;}

This will stop a new _startDrag from being started when mousedown fires, and the initial _stopDrag will fire on the corresponding mouseUP, so the borderContainer will not be in a bad state.


comment:4 Changed 12 years ago by bill

Milestone: tbd1.5
Owner: set to bill
Status: newassigned
Summary: BorderContainer does not render properly if dragged off the screenBorderContainer: stuck in drag mode if mouse-up occurs off browser window

This can be reproduced in test_BorderContainer.html.

The issue is detecting the mouseup event. On FF/safari we can detect it by connecting to onmouseup on dojo.doc, rather than <body>, which is what dojo.dnd.Manager does. However, that doesn't work for IE so it's not a full solution.

Note that the IE problem is not limited to BorderContainer. It happens even in test_movable.html. It could be resolved by detecting onmouseleave on window, as you suggested, although I guess we can wait to implement that until someone complains about IE drags getting stuck.

comment:5 Changed 12 years ago by bill

Resolution: fixed
Status: assignedclosed

(In [22433]) Monitor onmouseup on dojo.doc, rather than dojo.doc.body, so that we can detect mouseup even when it occurs outside of the browser window. Fixes #10749 !strict.

Note: See TracTickets for help on using tickets.