687456 - Channel may not have local and remote addresses accessible during nsISocketTransport::STATUS_WAITING_FOR

Status: NEW

(Core :: Networking: HTTP, defect, P5)

Description

[Honza Bambas (:mayhemer)]

- first, we post an event to distributor observers from the network thread (in nsHttpTransaction::OnTransportStatus)
- second, we post an event to the channel (again, in nsHttpTransaction::OnTransportStatus)
- if we reuse a connection for that channel, there is no STATUS_CONNECTED_TO sent to the channel
- therefor the channel grabs addresses from the transport in STATUS_WAITING_FOR event first
- this event is delivered to distributor observers sooner then to the channel -> when observers call on the channel it doesn't have the address yet

I propose to reverse order of posts to distributor and to the channel (transport sink) from nsHttpTransaction::OnTransportStatus.

Comment 1

[Honza Bambas (:mayhemer)]

Fixed as part of bug 648878.

Comment 2

[Jason Duell]

Honza, are you sure this is a dupe of 648878?  That bug was 1) fixed 3 months before you reported this, and 2) seems to be not something that would fix your issue here (it's a local/remote address bug, but only for e10s, and this sounds like a main process issue).

On the plus side, you've made me realize that we never closed up the followup to bug 648878--bug 664163. Thanks! :)

Comment 3

[Honza Bambas (:mayhemer)]

You are right, thanks.  I forgot the details of this bug.  The problem is elsewhere.

Comment 4

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 5

[[:nickname] nilfalse]

I believe I may be encountering this issue in the WebExtensions API when utilizing browser.webRequest.onResponseStarted.addListener().

Not yet sure about a shorter way to reproduce, but here's how I've been consistently seeing an issue so far:

• open about:debugging, load an addon which registers onResponseStarted listener to simply log the received parameters
• open a second tab and load any website. For instance, https://hg.mozilla.org/mozilla-central/file/tip/toolkit/components/extensions/ext-toolkit.json -- in the logs you'll be able see the IP address in the ip field (as expected)
• close the browser and reopen it so that it restores the previous browsing session and shows you about:debugging as an active tab
• load the same addon again (since temporary addons are removed at the end of session)
• ...

Now go to the second tab, this will trigger its loading. After this in the addon logs you'll consistently see ip field represented as null.
I was suspecting that it might be the case if the response was coming from cache, but I've noticed fromCache is usually set to false when ip === null in this case.

This behaviour is inconsistent with the Chromium implementation at the moment where it always returns the IP address to chrome.webRequest.onResponseStarted and other webRequest listeners.

If my hunch is right and this issue is the root cause this bug may need a higher priority.