Bug 29935 – Expand triangles by default in Web Inspector's Resources

• Component: Web Inspector (Deprecated)
• Status: RESOLVED INVALID

[Jeroen Bensch]

GET/POST data has recently been added to Web Inspector which is already a huge help.

What would be even more helpful is if the sections like "HTTP Information" and such would be expanded by default instead of collapsed. This way we could go through the different resources way faster, without having to expand sections for each resource each time to see what kind of request, GET or POST, what payload data, etc..., it was.

It's a dev-tool, so there's no need to hide information I think.

Even handier would be to mention in the Resources bar on the left what kind of request each request is in the case of a GET or POST.

[Jeroen Bensch]

When I click in the "Request Payload" section of a POST request method the text disappears.

[Timothy Hatcher]

We should just remember the expanded/collapsed state.

[Patrick Mueller]

re: comment 1, This should be broken out to a separate bug.  

For that new bug, explain *what* text disappears, and providing a test case would be useful.  A URL to an existing web site that exhibits the problem would be best, otherwise a snippet of HTML.

[Patrick Mueller]

re: comment 2

To be more precise, I think the thinking here is that once a disclosure button has been activated, we should remember it's state across the entire app.  So that any other resource you look at will have the disclosure setting (expanded/collapsed) the same.

While we're fixing that ...

It would be convenient to be able to expand/collapse the entire "tree" of up to 5 (I think) expandable elements at once.  There doesn't seem to be any default behaviour to do this in the existing code, that I can see; at least the classes relevant to these tree elements.  I thought I remembered seeing something like this at one time ...

In any case, there's no good place to "hang" such behaviour anyway, since there is no visible root for these tree elements.  How about if we enabled double-click on any of the top level elements (like "HTTP Information") to expand/collapse all?  There's already some kinda funky behaviour when you double-click these elements - we should fix that anyway, and we can fix it by adding new function!

Since this seems like really useful function, it would be a shame to hide it behind a double-click that pretty much no one will ever find.  What if we add a tooltip on the top-level elements as well indicating the function is available?

It seems a bit unkosher, but also pretty useful.

[Jeroen Bensch]

(In reply to comment #3)

http://www.lumacentral.com/CocaCola/index.html

This loads a .swf.

In Web Inspector's Resources select the execBatch one, expand Request Payload and click on the revealed text. It's gone.

[Jeroen Bensch]

(In reply to comment #4)
 
> In any case, there's no good place to "hang" such behaviour anyway, since there
> is no visible root for these tree elements.  How about if we enabled
> double-click on any of the top level elements (like "HTTP Information") to
> expand/collapse all?  There's already some kinda funky behaviour when you
> double-click these elements - we should fix that anyway, and we can fix it by
> adding new function!

In my opinion the "root" for these tree elements are the resources in the sidebar on the left. If you click one you expand whatever's underneat. This way you always get everything expanded. If then you want to hide certain sections you can close them (and their state'd be remembered throughout the app)

[Timothy Hatcher]

(In reply to comment #6)
> (In reply to comment #4)
> 
> In my opinion the "root" for these tree elements are the resources in the
> sidebar on the left. If you click one you expand whatever's underneat. This way
> you always get everything expanded. If then you want to hide certain sections
> you can close them (and their state'd be remembered throughout the app)

THat sounds good.

[Patrick Mueller]

(In reply to comment #6)

> In my opinion the "root" for these tree elements are the resources in the
> sidebar on the left. If you click one you expand whatever's underneat. This way
> you always get everything expanded. If then you want to hide certain sections
> you can close them (and their state'd be remembered throughout the app)

May be just me, but when I select a resource from the left column I'm usually wanting to see the resource payload (the response payload).  I believe that's the only way to see the resource - select it from the left column?  And then, if I "click" it to select it, which shows it AND expands the other info, this means you always get the expanded info by default.  I think this is probably too busy - I'll attach a screen shot to show an example.

I'm beginning to think that it probably doesn't make sense to individually expand/collapse the individual tree elements at all - all or nothing.  Perhaps we could actually provide a "root" element underneath the URL which it would then be easy to expand/collapse the whole thing in a single gesture.

[Timothy Hatcher]

(In reply to comment #8)
> (In reply to comment #6)
> 
> I'm beginning to think that it probably doesn't make sense to individually
> expand/collapse the individual tree elements at all - all or nothing.  Perhaps
> we could actually provide a "root" element underneath the URL which it would
> then be easy to expand/collapse the whole thing in a single gesture.

I totally disagree with that. The contents of those could be very long and annoying to expand everything just to see one thing.

I am fine expanding some or all by default, but all or nothing is off the table.

Maybe only expand by default the things that ususaly short, not the POST data, etc.

[Patrick Mueller]

Created attachment 40449 [details]
example of a resource displayed with all the tree elements expanded

I think this is a bit busy as the "default" view of a resource - most people seem to be pretty happy with seeing the resource data, but of course have been wanting a way to get at the request payload as well.  I don't think everyone needs to see the headers and request payload all the time, by default.  Note I believe this is the default window size for a detached inspector - a docked inspector will of course be typically "shorter", but "wider".  Making the inspector shorter worsens the problem, I think - you might not see ANY of the resource response payload without scrolling.

[Patrick Mueller]

(In reply to comment #9)

> I am fine expanding some or all by default, but all or nothing is off the
> table.
> 
> Maybe only expand by default the things that ususaly short, not the POST data,
> etc.

I'm not sure there is a "usually" case for any of these.  We could do it heuristically - if you have less than 5 request headers (or 5 form elements, etc) then expand by default.  But that doesn't seem right either.

The rationale behind my suggestion about doing them all or nothing is that I suspect people want to look at the resource data, or the meta data, but don't need to see them both at the same time.  And when you want to see the meta data, you want to see all of it.  It's less flexible compared to the "pick whatever you want to expand", but I suspect it would work well for most folks most of the time, and flexibility brings busy-ness.

I just had someone give me a little FireBug demo (not set up to run correctly on my box at the moment), and I can see they show a tabbed container with a tab for content, and a tab for headers, which shows both the request and response headers together.  All or nothing approach - though with FB, you can't see the resource data AND headers together, ever, unlike in WI, where they are combined into a scrollable area.