1327984 - Cursor is displayed as "default" instead of "col-resize" in some cases when I drag HTML replacement for XUL splitters

Status: NEW

(DevTools :: Shared Components, defect, P3)

Description

[arni2033]

>>>   My Info:   Win7_64, Nightly 53, 32bit, ID 20161119030204 (2016-11-19)
STR_1:
1. Open devtools -> inspector or devtools -> debugger
2. Hover mouse over any vertical splitter, hold left mouse button
3. Move mouse to the content area


AR:  Displayed cursor is "default"
ER:  Displayed cursor should be "col-resize", as it was before regression bug 1260552 & Co


STR_2:
1. Open devtools -> inspector or devtools -> debugger. Open split console
2. Hover mouse over any vertical splitter, hold left mouse button
3. Move mouse to the split console@ Jan Honza Odvarko [:Honza] (PTO: 12/09-01/01):
It seems that this is a regresion caused by your change. Please have a look.

Comment 1

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Honza, maybe a quick one to fix or mentor?  Not sure if it warrants regression tracking.

Comment 2

[Jan Honza Odvarko [:Honza] (always need-info? me)]

Hmm, this seems to be tricky. I don't know how to set the cursor also for the content document and any other opened document the mouse can hover over. This could also involve RDP communication, which seems ascrazy.

Is there any way how to force mouse-cursor no matter what the mouse is hovering over?
@Nicolas: any tips?

Note that currently, the cursor is set only for the document where the splitter lives.

Another issue I found when testing this:

1) Open DevTools and select the Inspector panel
2) Start changing width of the Sidebar (using vertical splitter)
3) Move mouse over to the content (page) document area
4) Release the mouse button
5) Move mouse back to the Inspector panel -> the dragging is still in progress even if the mouse button isn't pressed -> BUG

This is because "mouseup" event in't handled by the splitter more precisely Draggable component (since it happened in different documen) and the splitter 'thinks' that the dragging is still in progress. This seems to be a bit more important and also less hard to fix.

Honza

Comment 3

[Nicolas Chevobbe [:nchevobbe]]

For the cursor, I think that if we set the css cursor property on the html element, it will keep the same cursor as long as the mouse button is down. 
I set up a little example here : http://codepen.io/nchevobbe/pen/WRxpvO .
If you only hover the body (in red), it show you a move cursor, but if you go outside, it revert to the appropriate cursor on the element you hover.
Now, if you click on the red background body, and then, with the mouse button still pressed, move to the editor, or outside the firefox window, you still have the move cursor.
We could some thing like that by adding a class to the html element the splitter lives in (.splitter-moving , or something similar), and then change the cursor in CSS ( `html.splitter-moving { cursor: resize }` ) and it should work.

> This is because "mouseup" event in't handled by the splitter more precisely Draggable component (since it happened in different documen) and the splitter 'thinks' that the dragging is still in progress. This seems to be a bit more important and also less hard to fix.

We had to deal with such bug in the inspector when dragging node, if the mouse was released over the content window. The fix, if I remember correctly was to have to mousemove event declared on the window, which would track and capture mouse event even if the mouse is out of the firefox window (or the content window).