The tree view in inspector puts all the attributes into the view, which makes it fairly hard to see the tree structure in many cases. For comparison, the DOM inspector shows the actual tree structure, just the nodeName, and allows adding optional columns to see things like id, class, localName, etc. Attribute names/values except for class and id are in a separate panel once you select the element you care about.

I think it's very important that the markup-view shows all attributes by default. For one that's what other devtools do, and we've been trying to level up with them for a while. It could be confusing for someone specifically looking for a data attribute or custom attribute and not finding it there. Now, having an option that drives which attributes are shown, or if we show them at all, sounds interesting to me.

We were just discussing this recently. Seems like the best solution (in line with DOMi) is to hide most the attributes in the markup view and add a Node side panel with attributes. Of course this would be preffable, and off by default for web content, but it could be on by default for the Browser Toolbox since it's so hard to scan with the number of attributes used within the browser.

I believe the DOM tree and the rule view would be much more readable if text wouldn't wrap.

With no wrapping, there's one node per line. Much easier to scan.

This could be an option. And it would affect the ruleview, the markupview and the computedview.

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #6) > This could be an option. And it would affect the ruleview, the markupview > and the computedview. That would definitely be easier to implement. There is still noise from all the attributes, but it seems like the tree structure would be a lot easier to view. If you actually wanted to work with the attributes that were off screen it would be inconvenient, but that would be a tradeoff from setting that pref I guess.

(In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from comment #5) > With no wrapping, there's one node per line. Much easier to scan. How are the attributes ordered in these views? We could probably match DOMi pretty closely if we promoted the 'id' attribute and then the 'class' attribute to the front of the list.

Note that attribute order can matter when debugging what JS on the pa will do....

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #8) > (In reply to Paul Rouget [:paul] (slow to respond. Ping me on IRC) from > comment #5) > > With no wrapping, there's one node per line. Much easier to scan. > > How are the attributes ordered in these views? We could probably match DOMi > pretty closely if we promoted the 'id' attribute and then the 'class' > attribute to the front of the list. This is exactly what it does: http://dxr.mozilla.org/mozilla-central/source/browser/devtools/markupview/markup-view.js#2164

I was about to file a dup of this asking for a quick way to turn on/off the attribute view, because this is the #1 usability problem I have with Inspector, I think: all the attributes just make it _very_ hard to orient myself.

(In reply to Boris Zbarsky [:bz] from comment #11) > I was about to file a dup of this asking for a quick way to turn on/off the > attribute view, because this is the #1 usability problem I have with > Inspector, I think: all the attributes just make it _very_ hard to orient > myself. When you say "turn off the attribute view", do you mean hiding *all* attributes? And is this something you'd want to do only temporarily? Filtering down the list of displayed attributes using a pref should be fairly easy (there will probably be some more complex cases to fix when editing attributes because the code assumes all attributes to be displayed, but it should generally be fine). How about we introduce a pref that corresponds to the list of attributes that we want to display. This pref would not exist by default. Setting it to, say, "id,class" would only display ids and classes in the inspector. We could potentially surface this in the devtools settings panel too, but maybe not before we come up with an attributes panel somewhere. Someone changing this setting by mistake could be very easily confused when looking at the inspector. Would introducing a pref only for now be acceptable?

> do you mean hiding *all* attributes? I'm not sure. Being able to see id and class is sometimes pretty useful, but long ids/classnames can also make things confusing... In my ideal world, I guess, this would be a tristate (element name only, name + id + class, all attrs) that could be switched quickly. > And is this something you'd want to do only temporarily? In the sense that I wouldn't care if it persists to the next time I open inspector? I probably wouldn't care about that if switching is simple enough. In practice, I almost never want the "all attributes" view by default, though. Again for purposes of making my way around the tree. Once I focus on a particular node, I often want to see its attributes. > Would introducing a pref only for now be acceptable? As long as I can still see the values of the other attributes for a node I select (e.g. in the sidebar on the right), sure.

Here is a potential plan: 1 - introduce a pref that drives which attributes get displayed in the markup-view, 2 - whenever this pref is changed, refresh the markup-view, 3 - add 3 predefined states (mentioned in comment 13) for this pref and UI in the settings panel to switch through them, 4 - add a new settings menu in the inspector itself to switch through the states more quickly, see bug 1022220, 5 - create a new sidebar panel that lists attributes of the selected element. I don't like part 5 though, because we already have more sidebar panels than the default width can accommodate, and in the majority of cases (where the pref won't be set), the panel will show the exact same information as the markup-view.

I don't think #5 is needed if there's a quick way to switch to the "all attributes" view, right?

(In reply to Patrick Brosset [:pbrosset] [:pbro] from comment #14) > Here is a potential plan: > 1 - introduce a pref that drives which attributes get displayed in the > markup-view, > 2 - whenever this pref is changed, refresh the markup-view, What happens if I manually add an attribute that doesn't match this pref? Attribute disappears after finishing? Show all attributes just for that node? > 3 - add 3 predefined states (mentioned in comment 13) for this pref and UI > in the settings panel to switch through them, I don't think we'd need this setting in the settings panel UI. There are other tool specific settings (like in the debugger) that don't get surfaced to the settings panel. And this is something you probably only want to flip temporarily away from your preferred default anyway so going over to settings would be a lot of work. I have an alternative idea for the UI. What if your default setting (none, id+class, all) was used for all elements, and then if some attributes were being hidden due to that filter there would be an icon at the end of the open tag element (same place where the 'new attribute' space when you tab through attrs). If you click the icon, expand all attributes just on that node. If you click it again, recollapse all attributes. If you add a new non-matching attribute on a node with collapsed attributes, it's as if you clicked the icon. We can give it tab ordering too so it would be keyboard accessible.

(In reply to Patrick Brosset [:pbrosset] [:pbro] from comment #14) > Here is a potential plan: I worry that this plan is too heavily engineered, will take too much time and gets into feature creep territory. I think we could get this 80% better by simply removing the word-wrap and adding horizontal scrolling for people who need to read through and/or edit all of their attributes. Paul, do you still have your patch that you wrote for comment #4, or remember how you did it? I can write a patch for this if someone can point me to the relevant files.

(In reply to Brian Grinstead [:bgrins] from comment #2) > We were just discussing this recently. Seems like the best solution (in > line with DOMi) is to hide most the attributes in the markup view and add a > Node side panel with attributes. Of course this would be preffable, and off > by default for web content, You say "of course" but this isn't all that obvious to me. Our pain points will also be pain points for web devs dealing with content as complex as the browser UI. I'm sure such web content exists. I realize that parity with other browsers' dev tools is important to you, but it would also be a shame to throw away opportunities to provide a better UX for the sake of parity.

(In reply to Brian Grinstead [:bgrins] from comment #16) > I don't think we'd need this setting in the settings panel UI. There are > other tool specific settings (like in the debugger) that don't get surfaced > to the settings panel. And this is something you probably only want to flip > temporarily away from your preferred default anyway so going over to > settings would be a lot of work. FYI, having to switch to the settings for many things is really cumbersome. So I created bug 1230488 to improve the UX. Regarding this bug I'd go with Paul's suggestion first. And if there's still a need for the features mentioned in comment 14, implement them in a separate bug. Sebastian

Note that the reporter of this bug (me) pretty much never uses our devtools on our browser UI. I use them (or rather DOMI, because of issues like this one) to examine web pages that Gecko bugs are reported on. So comment 18 is spot on in terms of this biting people debugging web pages...

(In reply to Dão Gottwald [:dao] from comment #18) > (In reply to Brian Grinstead [:bgrins] from comment #2) > > We were just discussing this recently. Seems like the best solution (in > > line with DOMi) is to hide most the attributes in the markup view and add a > > Node side panel with attributes. Of course this would be preffable, and off > > by default for web content, > > You say "of course" but this isn't all that obvious to me. Our pain points > will also be pain points for web devs dealing with content as complex as the > browser UI. I'm sure such web content exists. I realize that parity with > other browsers' dev tools is important to you, but it would also be a shame > to throw away opportunities to provide a better UX for the sake of parity. The 'of course' is about not changing the default behavior of the inspector for web developers and adding yet another side panel in the inspector. We have so panels already that new ones add visual clutter and make it harder to get to others. Which is why I commented that it should be off by default if we went that route. I like the idea in Comment 17 if that solves the original problem. Would having something like attachment 8512861 [details] help?

That would help some, but is still pretty hard to skim...

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #17) > (In reply to Patrick Brosset [:pbrosset] [:pbro] from comment #14) > > Here is a potential plan: > > I worry that this plan is too heavily engineered, will take too much time > and gets into feature creep territory. I think we could get this 80% better > by simply removing the word-wrap and adding horizontal scrolling for people > who need to read through and/or edit all of their attributes. I would prefer to not have preferences in the settings for this; it seems to niche a problem for the majority of people. I agree with Jared: let's remove the word-wrap and add horizontal scrolling and not feature creep. Let's move the additional feature requests into other bugs.

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #17) > (In reply to Patrick Brosset [:pbrosset] [:pbro] from comment #14) > > Here is a potential plan: > > I worry that this plan is too heavily engineered, will take too much time > and gets into feature creep territory. I think we could get this 80% better > by simply removing the word-wrap and adding horizontal scrolling for people > who need to read through and/or edit all of their attributes. > > Paul, do you still have your patch that you wrote for comment #4, or > remember how you did it? I can write a patch for this if someone can point > me to the relevant files. I think setting width: -moz-max-content; on the body in markup view will do the trick. Though we need to decide if we want a pref for this exposed in the settings UI or if we set this as default behavior in browser toolbox (without an easy way to switch back since it's hard to get to about:config in the BT process)

An example of how this could work

I think wrapping should be an option in the context menu. If there's a data url or any very long attribute, the user will most likely want to wrap.

Inspector Bugs Triage - Filter on CLIMBING SHOES