731318 - Display response size before and after content decoding

Status: RESOLVED FIXED

(DevTools :: Netmonitor, defect)

Description

[Mihai Sucan [:msucan]]

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.

Comment 1

[Mihai Sucan [:msucan]]

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?

Comment 2

[Victor Porof [:vporof][:vp]]

(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.

Comment 3

[Mihai Sucan [:msucan]]

(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.

Comment 6

[Dane MacMillan [:danemacmillan]]

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.

Comment 10

[Jeff Griffiths (:canuckistani) (:⚡︎)]

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.

Comment 11

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Attachment: Show transferred size in Net Monitor

Victor, does seem like generally the right idea?

Still needs:
* Hide column (or something) for older servers
* Tests

Comment 12

[Victor Porof [:vporof][:vp]]

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.

Comment 13

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Attachment: 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

Comment 14

[Victor Porof [:vporof][:vp]]

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?

Comment 15

[Victor Porof [:vporof][:vp]]

(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!

Comment 16

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Fixed timeline-ticks test issue.

Try: https://treeherder.mozilla.org/ui/#/jobs?repo=try&revision=f4ecb288e283

Comment 17

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

https://hg.mozilla.org/integration/fx-team/rev/09bd629ead0f

Comment 18

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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

Comment 19

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(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.

Comment 20

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Attachment: 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

Comment 21

[Victor Porof [:vporof][:vp]]

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.

Comment 22

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

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

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/455a5366c877

Comment 25

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

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

Comment 26

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=6d17a6bceec7

Comment 27

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Try looks good.  Hopefully this can stay this time!

https://hg.mozilla.org/integration/fx-team/rev/2d8d90eaab6e

Comment 28

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/2d8d90eaab6e