Selection in panes are impossible to see

[hfhchan]

It is impossible to see what I've selected in any row in the "Headers" pane in the right hand side of the "Network" tab. The color of each row is exactly the same as the selection background.

Example:

One would be mislead that I have selected the whole string, but in fact I haven't selected anything (CTRL+C does nothing). When I select everything by triple clicking, I get this:

The same applies to other tabs and panes.

[fvsch]

Thanks for the report Henry. I agree that this is not ideal.

It looks like the simpler fix would be to remove the "selected row" style altogether, since it doesn't seem to perform any action in the headers list or in the cookies list.

The same applies to other tabs and panes.

Do you happen to know which ones. I looked briefly but many tools which have a "selected row" style don't allow text selection, such as the Inspector's markup view, the Debugger's Sources pane, etc. Only exception I found was the Network list of request.

[hfhchan]

I check again and indeed it seems constrained to the Network tab.

While at it, it would benefit UX if the selection behavior of key/value rows were consistent across different panes. It seems a minor inconvenience that some rows support a selection on value, and some can only be copied in full. If possible, supporting selecting any part of the key and/or value, and having a context menu (with something like Copy Property and Copy Value), like it is in the Inspector pane, would be a nice addition.

Meanwhile, when copying rows on the right pane for the Storage tab, a space is missing after the colon:

Copied Value:

CreationTime:"Thu, 08 Oct 2015 XX:XX:XX GMT"

[nchevobbe]

I experienced the same thing in the inspector when trying to copy an attribute value on a selected node.

[fvsch]

I experienced the same thing in the inspector when trying to copy an attribute value on a selected node.

I think we disable text selection in the markup view on purpose. Not sure why, but since we have interactions such as double-click for editing and dragging to move nodes around, and those two interactions can trigger selections by default, allowing selections would result in an awkward experience.

Maybe @captainbrosset or @gabrielluong know more about the rationale for that.

[nchevobbe]

it's not disabled:

by default, if you double click only the attribute value gets selected:

but if you double click (or Ctrl+A), the whole input content is selected, and it can be mistaken with the selected background color.

[captainbrosset]

I think what @fvsch is saying is that, unless you double click to enter edit mode, you can't select text in the markup-view. That is correct, and is indeed something we did when we implemented drag and drop support for re-ordering nodes in the DOM. Prior to that, it was possible to drag with the mouse cursor to select text outside of an input field.

But, yes, @nchevobbe is correct in that selecting the entire string of text in one of the attribute edit field gives it the same color background than the node behind it, making it hard to understand that a text selection does exist.

I would argue that this is a somewhat different issue than in the netmonitor though. Here, the natural (mouse-based) way of triggering editing is to double click. And doing so only selects the value, leaving the name unselected, hence on a white background. It's quite clear that an input field exists and that only part of it is selected. Selecting the entire text requires a triple click, or an extra double click or ctrl+A. So probably less likely to happen by accident.

[fvsch]

Selecting the entire text requires a triple click, or an extra double click or ctrl+A

You can also double-click the equal sign. (Maybe that's not an intended result.)

[fvsch]

Not a general solution for all the things, but I filed a bug for the Netmonitor's "Headers" tab. https://bugzilla.mozilla.org/show_bug.cgi?id=1537724