1307784 - [e10s] Network Monitor not showing security information for service workers

Status: RESOLVED DUPLICATE of bug 1836707

(Core :: DOM: Service Workers, defect, P3)

Description

[Fanolian]

Attachment: No green locks for service workers requests

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20161005030211

Steps to reproduce:

1. Open Network Monitor (Ctrl-Shift-Q).
2. Visit https://web.whatsapp.com/.
3. Observe Network Monitor.


Actual results:

Please see attachment.
1. No green locks for service worker requests even if they are loaded from a https address.
2. Security panes are missing for those requests.

Comment 1

[Fanolian]

Workaround:
Disable e10s.

Comment 2

[Andrew Overholt [:overholt]]

Josh, do you know what's going on here?

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

Honza, do you know what triggers the green lock?

I believe we do have security info for the response from the service worker, but perhaps its not getting set in the right place on HttpChannelChild.

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

I think we need to populate mSecurityInfo in HttpChannelChild::OverrideWithSynthesizedResponse().  We should also write a test to keep this from regressing in the future.

Comment 5

[Andrew Overholt [:overholt]]

Catalin, care to take a look?

Comment 6

[Cătălin Badea (:catalinb)]

Sure.

Comment 7

[Cătălin Badea (:catalinb)]

Because network interception is done in the child process, we'd need to bounce the channel's security info to the parent process in order to verify its certificate. At this time, it would be better to wait on bug 1231222 to be fixed.

Comment 8

[Jens Stutte [:jstutte]]

:catalinb, now that bug 1231222 is closed, would this be still something you want to look at? Thank you!

Comment 9

[Andrew Sutherland [:asuth] (he/him)]

:catalinb was a MoCo employee at the time and is not likely to want to look at this, although I am sure will celebrate the closing of bug 1231222! ;)

Comment 10

[Andrew Sutherland [:asuth] (he/him)]

If this is still happening we believe the work to make sure devtools can be aware of all related ServiceWorker activity in bug 1836707 will help with that. Otherwise we do believe in general that improvements have been made in this area.