Closed Bug 972054 Opened 10 years ago Closed 10 years ago

Numeric status codes in the network monitor

Categories

(DevTools :: Netmonitor, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
Firefox 30

People

(Reporter: dcamp, Assigned: rcampbell)

References

Details

Attachments

(2 files, 2 obsolete files)

At least for folks that are used to dealing with HTTP status codes, the color swatches can be an unnecessary hiding of useful data.

Should we reconsider that?
What do you think?
Flags: needinfo?(dhenein)
As a color blind person, the symbols didn't help that much :-/

+1 for actual status codes.
I don't think it's completely terrible as-is:

* 2xx / 3xx / 4xx codes are different shapes
* it isn't obvious which shape is which initially, but you can hover over the items to see the exact code

The colour-blind case gives me pause though, the design relies pretty heavily on colour cues. We could have numeric status codes as an option - would be interesting to see a quick mock-up.
I also think sometimes you actually need to know the specific numeric code, and having to mouseover could be annoying.
Yeah, there are a lot of use cases where we would get annoying. Chrome has a column dedicated to it ( in Safari you have to dig around a bit ). Could consider adopting chrome's approach.
Would it be prefferrable to have two separate columns, or optionally changing the appearance of the "status code" column from shapes to numbers? I'm happy with both approaches.
(In reply to Victor Porof [:vporof][:vp] from comment #1)
> What do you think?

I'm more inclined to show the numerical code by default, or at the very least allow it to be toggled on. I agree that often knowing the specific code is useful, and don't see a lot of value in hiding it.

The shapes/colors are good for a glance-able indication of how requests are returning, but if you're debugging some caching issue or something you may want actual codes.
Flags: needinfo?(dhenein)
Given that we don't have column customization, seems like we should just change the contents of the column, not add a second?
If we use codes instead of shapes, can we at least retain the color of the shape so that quick glancing can still be useful?
(In reply to Panos Astithas [:past] from comment #9)
> If we use codes instead of shapes, can we at least retain the color of the
> shape so that quick glancing can still be useful?

Absolutely. In fact I suggest we keep the shapes as well where they are, and have the status codes as a column which you can sort by, etc.
(In reply to Darrin Henein [:darrin] from comment #10)
> (In reply to Panos Astithas [:past] from comment #9)
> > If we use codes instead of shapes, can we at least retain the color of the
> > shape so that quick glancing can still be useful?
> 
> Absolutely. In fact I suggest we keep the shapes as well where they are, and
> have the status codes as a column which you can sort by, etc.

If we have both, would it make sense to have them be separate columns? I don't see any reason why it would. I think we could save some horizontal space with no negative effects by having them in the same column (which would still be sortable, etc).
(In reply to Nick Fitzgerald [:fitzgen] [Ðoge:D6jomNp59N9TVfgc538HU3RswwmwZwcrd7] from comment #11)
> If we have both, would it make sense to have them be separate columns? I
> don't see any reason why it would. I think we could save some horizontal
> space with no negative effects by having them in the same column (which
> would still be sortable, etc).

Yes, valid point. For some reason I was thinking the current icon column wasn't sortable (which I now see it is). I like how some other browsers (i.e. Chrome) show the text of the status code ("Not Modified", etc.) though I don't see how we can incorporate this in our current slim row design. Maybe once we have customizable columns :)
A few people mentioning customizable columns; do we have a bug filed?
(In reply to Nick Fitzgerald [:fitzgen] [Ðoge:D6jomNp59N9TVfgc538HU3RswwmwZwcrd7] from comment #13)
> A few people mentioning customizable columns; do we have a bug filed?

Bug 862855?
(In reply to Nick Fitzgerald [:fitzgen] [Ðoge:D6jomNp59N9TVfgc538HU3RswwmwZwcrd7] from comment #14)
> (In reply to Nick Fitzgerald [:fitzgen]
> [Ðoge:D6jomNp59N9TVfgc538HU3RswwmwZwcrd7] from comment #13)
> > A few people mentioning customizable columns; do we have a bug filed?
> 
> Bug 862855?

Yes.
Also note that I am working on a Table Widget, which can be then further enhanced to be used by Net Monitor too. (bug 970517)
Is this a good-first-bug?
(In reply to Dave Camp (:dcamp) from comment #17)
> Is this a good-first-bug?

Yes. Do you want to mentor it? :)
Just kiddin'.
OS: Mac OS X → All
Hardware: x86 → All
Whiteboard: [good first bug][lang=js][mentor=vporof]
At a second glance, this isn't really *that* trivial, since it involves a bit of xul wrangling.
Assignee: nobody → vporof
Status: NEW → ASSIGNED
Whiteboard: [good first bug][lang=js][mentor=vporof]
yoink.
Assignee: vporof → rcampbell
Attached patch statuscode (obsolete) — Splinter Review
Attachment #8379310 - Flags: review?(vporof)
Attached patch statuscode (obsolete) — Splinter Review
missed a commented section - removed.
Attachment #8379957 - Flags: review?(vporof)
Attachment #8379310 - Flags: review?(vporof)
Comment on attachment 8379957 [details] [diff] [review]
statuscode

Review of attachment 8379957 [details] [diff] [review]:
-----------------------------------------------------------------

In certain scenarios when the request verbs are too long, the status code will end up containing/being an ellipsis. Make the status header cells wider by tweaking the width inside the .requests-menu-status-and-method class (there's two occurrences in netmonitor.inc.css (one for regular toolbox hosts and one for side hosts) and one occurrence in themes/linux/netmonitor.css (where the rows are narrower for some reason)).

::: browser/themes/shared/devtools/netmonitor.inc.css
@@ +175,4 @@
>    -moz-margin-end: 5px;
>    border-radius: 10px;
>    transition: box-shadow 0.5s ease-in-out;
> +  margin-bottom: 2px; /* needed to align with text baseline */

This margin doesn't actually make any difference on my machine, but has nasty side-effects on a stock Ubuntu. The necessity of this is most likely a byproduct of your build SDK.

tl;dr Please remove this.
Attachment #8379957 - Flags: review?(vporof) → review-
Attached image ellipsis
Attachment #8379310 - Attachment is obsolete: true
Attached patch statuscodeSplinter Review
Attachment #8379957 - Attachment is obsolete: true
Attachment #8384751 - Flags: review?(vporof)
Comment on attachment 8384751 [details] [diff] [review]
statuscode

Review of attachment 8384751 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/themes/shared/devtools/netmonitor.inc.css
@@ +175,4 @@
>    -moz-margin-end: 5px;
>    border-radius: 10px;
>    transition: box-shadow 0.5s ease-in-out;
> +  margin-bottom: 2px; /* needed to align with text baseline */

As I said in the previous patch, please remove this.
Attachment #8384751 - Flags: review?(vporof) → review+
https://hg.mozilla.org/mozilla-central/rev/e3b1a2c04ead
https://hg.mozilla.org/mozilla-central/rev/33b9a3c7c963
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 30
Status: RESOLVED → VERIFIED
Depends on: 987812
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.