Closed Bug 1546079 Opened 3 years ago Closed 2 years ago

Reconsider expanding/collapsing UX of layout panel

Categories

(DevTools :: Inspector: Layout, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1576604

People

(Reporter: ntim, Assigned: gl)

Details

(Whiteboard: [dt-q])

Attachments

(1 file)

The new flexbox/grid highlighting tools are pretty nice, however most of the time, when I consult the Layout panel, I only want to see the Box model view.

Unfortunately, every time I select a new element in the inspector that has Grid/Flexbox, the Grid/Flexbox section expands automatically and pushes down the Box Model section, meaning I have to close the sections manually every time... Not to mention the Box model section gets automatically collapsed in that case too, which means I have to re-expand it.

Some possible ways to fix this are:

  • Move the Box Model section to the top (that would be reasonable IMO, since Chrome has the Box Model on top of the computed view)

  • Remember the last collapsed state for grid items/flex items/etc.: meaning if I last collapsed the Grid inspector for a grid item, it should remember that next time I select a grid item

  • Stop doing auto-collapsing for the box model view

Summary: Reconsider UX of layout panel → Reconsider expanding/collapsing UX of layout panel

I share the same overall frustration. :)

Stop doing auto-collapsing for the box model view

+1. When other panes are expanded you often need to scroll down to get to the Box Model view. Having to scroll + click to expand is taxing; scrolling should be enough.

Move the Box Model section to the top (that would be reasonable IMO, since Chrome has the Box Model on top of the computed view)

+1. Box Model on top would follow a pattern of "General case first, special cases (Flex, Grid) second".
My main use case for this is when I select several elements in the tree in succession to check their metrics and display type (who is tall? who has position:relative?). The Box Model section is great for that, but if it's closed or out of view every other click it's quite maddening.

I suppose having Grid then Flex on top was a way to make those tools more discoverable and give them more press.
Personally I would still be in favor of Box Model on top, but there might be good other reasons not to do it?

Remember the last collapsed state for grid items/flex items/etc.

I think it's already the case?

I've experienced it feeling very unpredictable though, but I wonder if it's due to:

  • using the Browser Toolbox: it uses a different set of preferences I believe
  • different settings being applied for different nodes or display types? (I remember specific instances of changing nodes in the markup view and getting different collapsed/expanded states in Layout as a result; can't reproduce on Nightly, I wonder if those were bugs that got fixed)
Whiteboard: [dt-q]
Attached video index.mp4

The last collapsed state is saved, but the implementation seems to be based on the the panel index rather than the actual panels. This is problematic as the number of panels can change (=> flexbox can have 2 panels for container and item).

In the video attached you can see the effect.

@Martin That looks like what I've seen before. Good catch!
I wonder if we could fix that simply, and maybe even backport it to beta?

Assignee: nobody → gl
Status: NEW → ASSIGNED
Priority: -- → P3

Looks like I've duped this bug in bug 1576604, which has a patch landing today (so it will be in Firefox 70).

My patch fixes:

  • Remember the last collapsed state for grid items/flex items/etc.
  • Stop doing auto-collapsing for the box model view

We can dupe this bug on the newer one (sorry :P), or repurpose it to improve the UX of the Flex accordion items.

With my patch, things like Grid and Box Model getting opened/closed erratically are fixed. But the Flex accordion items still seem to behave strangely. The main issue is that we have 3 different accordion items:

  1. "Flexbox": shows a generic message, "Select a Flex container or item to continue."
  2. "Flex Container"
  3. "Flex Item of …"

Meanwhile, we only have one pref called devtools.layout.flexbox.opened.

On the JS side:

  • In the React state (which is temporary but used when switching between elements), we save the opened/closed state for each of the 3 Flex-related accordion items.
  • In preferences, though, we always write to the devtools.layout.flexbox.opened preference.

So if I have a Flex Item which is also a Flex Container (like the blue squares in https://codepen.io/fvsch/pen/yLBMEwe), as a user I'm seeing:

  • "Flex Container"
  • "Flex Item of …"

Let's say both are open. If I close "Flex Container" but keep "Flex Item of …" open, our case sets the devtools.layout.flexbox.opened to false. If I close devtools, reopen it and select the same element, both accordion items will be closed (because they both read the same pref to get their initial open/closed value when the Accordion component is instantiated).

So even with my patch, which improves the situation a bunch in my tests, the Flexbox accordion items seemed a bit erratic because of that.

A possible fix would be to have 3 preferences:

  • devtools.layout.flexbox.opened (use for "Flexbox" and "Flex Container")
  • devtools.layout.flex-item.opened (new, use for "Flex Item of …")

Should we try to address that in this bug?
Any other fix we could do?

Flags: needinfo?(mbalfanz)

Clearing the ni for now, I've been looking at how the flex-related accordions work and need to summarize the UX and technical issues more clearly.

Flags: needinfo?(mbalfanz)

Closing since the main issue was fixed in bug 1576604.

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1576604

Moved the discussion of Flexbox accordions state to bug 1578097.

You need to log in before you can comment on or make changes to this bug.