1218716 - Make the markup-view node drag clone and indicators nicer

Status: NEW

(DevTools :: Inspector, enhancement, P3)

Description

[Patrick Brosset <:pbro>]

From bug 1202179 comment 9:

"They were barely visible and they still are, even if I set opacity to 0.5 [1.1], [1.2]. The first thing that comes to mind is to indeed reduce the opacity of dragging element. Second thing is to set "z-index:2;" to indicators. Third thing is, actually, that old colors were more visible (but still not enough). Black color was completely ok for drop-target indicator on light theme. Now you're suggesting to use yellow which is less visible under (and above) white-text-on-blue of dragging element. What for dark theme... both blue and yellow are not visible enough. I'm not sure, but maybe red/violet color would be the right solution
[1.1] https://dl.dropboxusercontent.com/s/noy4xb6eu5es2ak/bug%201202179%20-%20discussion%20-%20%5B1.1%5D%20Barely%20visible%20lines%20%28opacity%20set%20to%200.5%29.png?dl=0
[1.2] https://dl.dropboxusercontent.com/s/6v0md3o1tmjkg8n/bug%201202179%20-%20discussion%20-%20%5B1.2%5D%20Barely%20visible%20lines%20%28opacity%20set%20to%200.5%29.png?dl=0"

And from a discussion with bgrins on IRC:

"<•bgrins> pbro: here's one thing (an existing issue we could do in a follow up or here): when an expanded element is really big it's drop clone thing is covering where it's going: https://www.dropbox.com/s/42h02l6105xtvum/Screenshot%202015-10-26%2009.05.15.png?dl=0
<•pbro> bgrins: yeah I know, I don't like this either. I tried fixing it while on this bug but didn't find a simple enough solution. It seemed to be more involved and thought it'd be better in its own bug.
<•pbro> What do you think about it? One option is to just show the collapsed node, another is to clip the clone gradually with a gradient to transparent"

So, this bug should be about making moving nodes in the markup-view easier by making sure users clearly see the drag indicator (where the drag started from), the drop indicator (where the node would go if the user released the mouse button now), the node being dragged, and the nodes below the node being dragged.

Comment 1

[Patrick Brosset <:pbro>]

Also from bug 1202179 comment 9:

"When I'm going to drag a huge element down, I see pointer's coordinates and the target coordinates. So I'm prepared to drag the element by N pixels (let say 60). But when I start dragging, the element is being removed from tree, so position of all elements placed lower also changes. So I can never tell where am I going to drag it (can't specify the target's placement) before I start the actual drag.
// Bug 1202458 is good testcase for this, though in fact that bug isn't about dragging"

One option is to leave the dragged element in the tree and only move a collapsed clone.

Comment 2

[arni2033]

"Dragging a clone" concept (or no image under mouse pointer at all, like in GoogleChrome) will fix both indicators and markup. I think that markup itself is much more important (bug 1197276 and others)

Comment 3

[Patrick Brosset <:pbro>]

Indeed, chrome doesn't show anything on drag, just the drop indicator as you move the mouse.
We should investigate a few ideas here.