If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Requests made by service workers have incorrect transfer size

UNCONFIRMED
Unassigned

Status

()

Firefox
Developer Tools: Netmonitor
P3
normal
UNCONFIRMED
11 months ago
10 months ago

People

(Reporter: Inian, Unassigned, NeedInfo)

Tracking

51 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

11 months ago
Created attachment 8803283 [details]
Screenshot 2016-10-21 10.51.24.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.59 Safari/537.36

Steps to reproduce:

Go to https://codecombat.com and open the dev tools
Wait for Service worker to install
Reload the page



Actual results:

The requests made by service workers do not have the correct transfer size - "It just says Service Worker". For example, https://codecombat.com/javascripts/aether.js has transfer size set to service worker. 


Expected results:

The size is correctly set to 11.36 MB but I would like to see the transfer size too.
(Reporter)

Updated

11 months ago
Component: Untriaged → Developer Tools: Netmonitor
Thanks for the report!

The text for "Transferred" column is hardcoded here:
https://dxr.mozilla.org/mozilla-central/rev/5e76768327660437bf3486554ad318e4b70276e1/devtools/client/netmonitor/requests-menu-view.js#1075

@Jarda: can we calculate real size of the request coming from service workers?

Honza
Flags: needinfo?(jsnajdr)
Priority: -- → P3

Comment 2

10 months ago
When a request is handled by a service worker, no data are transferred over network by HTTP. The response is either generated by JS code or served from cache. The JS code in the service worker can issue another request and just forward the response, but that would show up as another independent request in the network monitor.

The response size is in the "Size" column, and that's the only size information that's needed. "Transferred" makes sense only for HTTP responses, where the response could be base64-encoded, compressed etc.

Inian, what additional information do you expect in the "Transferred" column that is not already in "Size"?
Flags: needinfo?(jsnajdr) → needinfo?(inian1234)
Maybe the "Transferred" column should say "(service worker)" or something when it's from SW and not over the wire.  Similarly, when the response comes from the HTTP cache, the "Transferred" column could say "(cache)".

Comment 4

10 months ago
(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #3)
> Maybe the "Transferred" column should say "(service worker)" or something
> when it's from SW and not over the wire.  Similarly, when the response comes
> from the HTTP cache, the "Transferred" column could say "(cache)".

That's exactly what's happening now :)
(Reporter)

Comment 5

10 months ago
Hey, 

The number being showed in the sizes column is after the data is un-gzipped. I expect the number in the transferred column to be the size of the asset actually transferred down the wire. 

For example, the asset https://codecombat.com/javascripts/esper.js shows a transferred size of 780 KB which is the size of the asset after it has been un-gzipped.

Comment 6

10 months ago
When I load the codecombat.com site, I see two requests for the ember.js file:

1. A fetch request issued by the service worker, for https://codecombat.dexecure.net/javascripts/esper.js. This request actually goes over the network, and shows transferred size of 128.57kB, and uncompressed size of 783.13kB.

2. A request issued by the page, for https://codecombat.com/javascripts/esper.js, intercepted by the service worker. No network traffic here, it's just two browser components talking to each other internally. Size is 783.13kB.

Everything works as expected:
- a script tag in the page caused a request to be issued
- this request was intercepted by the SW, the interception code issued a fetch, shown as request #1
- after the fetch response arrived, SW sent a synthetic response back to the page, shown as request #2
(Reporter)

Comment 7

10 months ago
Wow excellent..this has been fixed in the recent Developer build. This wasn't how it was working in the Developer edition when I filed the bug. 

Should reach the stable build soon I guess.
(Reporter)

Comment 8

10 months ago
However, the page size is still being shown wrongly as 24.9 MB. See the attached screenshot. It is again considering the "size" instead of the "transferred size". Should I file another bug instead?

https://www.dropbox.com/s/3rrffbky21htccy/Screenshot%202016-11-15%2017.55.40.png?dl=0

Comment 9

10 months ago
Oh yes, I was testing in Nightly, and there was a recent fix of the Transferred info in bug 1309523. Version 51 and later should be fixed.

The performance pie chart shows the uncompressed sizes of the payload, not the network transferred sizes. That's probably not the expected behavior.
(Reporter)

Comment 10

10 months ago
Yup, I would expect the pie chart to contain the transferred sizes of the assets to match the behaviour of pages without service workers.
You need to log in before you can comment on or make changes to this bug.