Display response size before and after content decoding

RESOLVED FIXED in Firefox 38

Status

()

Firefox
Developer Tools: Netmonitor
RESOLVED FIXED
5 years ago
2 years ago

People

(Reporter: msucan, Assigned: jryans)

Tracking

Trunk
Firefox 38
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

5 years ago
Another problem I bumped into this weekend with web app deployment and network logging: we need to display the response size.

Currently we display the reported Content-Length header coming from the server response, but if the response doesn't include the header, then the web developer has no way to check the response size.

Beyond that I needed to be able to tell the difference between the response size before content decoding and after (if there's gzip or deflate encoding).

Currently Dragonfly and Web Inspector display no size information if Content-Length is missing (or they don't do so in an obvious manner - I didn't find the values). Firebug displays the response body size before decoding, but it doesn't tell the user clearly if the value is before or after.
(Reporter)

Comment 1

4 years ago
We now display the response size in the new netmonitor, but we do not say anything about content encoding.

Victor, how is the response size determined? Before or after decoding?
Component: Developer Tools: Console → Developer Tools: Netmonitor
(In reply to Mihai Sucan [:msucan] from comment #1)
> We now display the response size in the new netmonitor, but we do not say
> anything about content encoding.
> 
> Victor, how is the response size determined? Before or after decoding?

I'm using the contentSize property of a responseContent packet.
(Reporter)

Comment 3

4 years ago
(In reply to Victor Porof [:vp] from comment #2)
> (In reply to Mihai Sucan [:msucan] from comment #1)
> > We now display the response size in the new netmonitor, but we do not say
> > anything about content encoding.
> > 
> > Victor, how is the response size determined? Before or after decoding?
> 
> I'm using the contentSize property of a responseContent packet.

Hmm, this sounds like it is after decoding. We need to investigate this more.
Summary: Network panel needs to display response size → Display response size before and after content decoding
Priority: -- → P3
Duplicate of this bug: 866257
Duplicate of this bug: 884318
I wrote a bug report, then found this one, so I'll just paste it here and cancel the report:

Title:
------
Network monitor's "Size" column does not reflect gzipped size.

Body:
-----
The "Size" column in the Network Monitor does not take into consideration assets that are gzipped. Instead the size displayed is the actual size. "Size" should reflect the size of the asset coming downstream, not the actual size of the file. This is important for understanding the performance aspects of a site. For reference, both Firebug and Chrome DevTools do this.
(Assignee)

Updated

3 years ago
Duplicate of this bug: 953351
(Assignee)

Updated

3 years ago
Duplicate of this bug: 953372
(Assignee)

Updated

3 years ago
Duplicate of this bug: 970510
This has been duped several times and is now also a pretty popular suggestion on uservoice:

http://ffdevtools.uservoice.com/forums/246087-firefox-developer-tools-ideas/suggestions/5896352-show-compressed-and-uncompressed-size-of-http-resp

( I've duped several feedback items into that one, so the otes there under-represent the interest :( )

Please consider bumping the priority; I also wonder if this could be a mentored bug.
Priority: P3 → --
Created attachment 8531943 [details] [diff] [review]
Show transferred size in Net Monitor

Victor, does seem like generally the right idea?

Still needs:
* Hide column (or something) for older servers
* Tests
Assignee: nobody → jryans
Status: NEW → ASSIGNED
Attachment #8531943 - Flags: feedback?(vporof)
Comment on attachment 8531943 [details] [diff] [review]
Show transferred size in Net Monitor

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

Nice! r+ with test! Hiding columns can be done in a followup.
Attachment #8531943 - Flags: feedback?(vporof) → feedback+
Created attachment 8532441 [details] [diff] [review]
Show transferred size in Net Monitor (v2)

Hides columns when server support is missing, and adds tests.

Try: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=8beb93dbacd8
Attachment #8531943 - Attachment is obsolete: true
Attachment #8532441 - Flags: review?(vporof)
(Assignee)

Updated

3 years ago
Blocks: 937586
Comment on attachment 8532441 [details] [diff] [review]
Show transferred size in Net Monitor (v2)

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

r+ with issue below fixed.

::: browser/devtools/netmonitor/netmonitor-view.js
@@ +419,5 @@
> +
> +    if (!NetMonitorController.supportsTransferredResponseSize) {
> +      $("#requests-menu-transferred-header-box").hidden = true;
> +      $("#requests-menu-item-template .requests-menu-transferred").hidden = true;
> +    }

What happens after a navigation to a server that supports transferred response size? Are the columns permanently hidden in that case? How about hiding those does by default in xul, and then altering their visibility on tab navigation?
Attachment #8532441 - Flags: review?(vporof) → review+
(In reply to Victor Porof [:vporof][:vp] from comment #14)
> Comment on attachment 8532441 [details] [diff] [review]
> Show transferred size in Net Monitor (v2)
> 

Oh, now I realize that by server you mean devtools server. Land away!
Fixed timeline-ticks test issue.

Try: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=f4ecb288e283
https://hg.mozilla.org/integration/fx-team/rev/09bd629ead0f
Whiteboard: [fixed-in-fx-team]
Mochitest-e10s-devtools was failing with this patch, so backed out in https://hg.mozilla.org/integration/fx-team/rev/22eb2228358f

https://treeherder.mozilla.org/ui/logviewer.html#?job_id=1386853&repo=fx-team
Flags: needinfo?(jryans)
(In reply to Wes Kocher (:KWierso) from comment #18)
> Mochitest-e10s-devtools was failing with this patch, so backed out in
> https://hg.mozilla.org/integration/fx-team/rev/22eb2228358f
> 
> https://treeherder.mozilla.org/ui/logviewer.html#?job_id=1386853&repo=fx-team

*Shakes fist at e10s*! Thanks for the backout.

Might be a little while before I can get back to this.
Flags: needinfo?(jryans)
Created attachment 8534586 [details] [diff] [review]
Transferred size for e10s too

For e10s, we need to preserve the original |notificationCallbacks| on the channel, so that other interfaces like nsILoadContext are still accessible.  So, I hold onto the original one and forward interface requests we can't respond to.

I'll fold this into the previous patch before landing.

Try (w/ e10s too): https://treeherder.mozilla.org/#/jobs?repo=try&revision=80c4614b74a5
Attachment #8534586 - Flags: review?(vporof)
(Assignee)

Updated

3 years ago
Attachment #8534586 - Attachment description: 0002-Bug-731318-Transferred-size-for-e10s-too.-r-vporof.patch → Transferred size for e10s too
Comment on attachment 8534586 [details] [diff] [review]
Transferred size for e10s too

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

I think I understand this code.
Attachment #8534586 - Flags: review?(vporof) → review+
Fixed debug build failures, green try: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=ef6f0ccfe296

Pushed combined patch: https://hg.mozilla.org/integration/fx-team/rev/455a5366c877
https://hg.mozilla.org/mozilla-central/rev/455a5366c877
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]
Target Milestone: --- → Firefox 37

Updated

3 years ago
Depends on: 1115976

Updated

3 years ago
Depends on: 1116864
Duplicate of this bug: 1118700
I've backed out this bug, as it exposes latent networking issues (see bug 1116867).  Will land again when that is resolved.

remote:   https://hg.mozilla.org/integration/fx-team/rev/8fe5a1d4052e
remote:   https://hg.mozilla.org/integration/fx-team/rev/6174f981f675
Status: RESOLVED → REOPENED
Depends on: 1116867
Resolution: FIXED → ---
https://treeherder.mozilla.org/#/jobs?repo=try&revision=6d17a6bceec7
Try looks good.  Hopefully this can stay this time!

https://hg.mozilla.org/integration/fx-team/rev/2d8d90eaab6e
Whiteboard: [fixed-in-fx-team]
https://hg.mozilla.org/mozilla-central/rev/2d8d90eaab6e
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 years ago
Resolution: --- → FIXED
Whiteboard: [fixed-in-fx-team]

Updated

2 years ago
Depends on: 1125501
(Assignee)

Updated

2 years ago
Target Milestone: Firefox 37 → Firefox 38
You need to log in before you can comment on or make changes to this bug.