918293 - loading favicon not included in webdeveloper-console

Status: RESOLVED FIXED

(DevTools :: Netmonitor, defect)

Description

[[:philipp]]

the loading of favicons is not logged in the network-section of the developer console. 

since favicons now also seem to be able to break a secure connection when loaded through http (see bug 878153), it is difficult to diagnose this with firefox' own developer tools, since the favicon won't show up as mixed content...

Comment 1

[Panos Astithas (he/him) [:past] (please ni?)]

IIRC favicons are loaded by the outer window, while the rest of the page is loaded by the inner window. Mihai is this accurate? Does the network actor filter out anything not coming from the inner window?

Comment 2

[Mihai Sucan [:msucan]]

All favicons are loaded by the tab browser - the network requests point to the chrome window (browser.xul). As such, the network actor filters these requests out. I seem to remember discussing this issue with Tanvi or Ivan from the security team.

I'm not sure how we can fix this bug. Do you have any ideas?

Comment 3

[Panos Astithas (he/him) [:past] (please ni?)]

I think we should just special-case favicons in this case and include them in the monitored requests.

Comment 4

[Mihai Sucan [:msucan]]

(In reply to Panos Astithas [:past] from comment #3)
> I think we should just special-case favicons in this case and include them
> in the monitored requests.

How should we do this? With the available network request info I am not sure how we can safely special-case favicons.

Comment 5

[Panos Astithas (he/him) [:past] (please ni?)]

Maybe we could use nsIFaviconService to find out the favicon URL and transmit the protocl request out of sequence. Here is an algorithm that should work:

1. On each network request, check if the favicon URL is known and if not, use the nsiFaviconService to get it and store it
2. Use the existing filter for the request
  a. If the favicon is known, create a protocol event if the filter matches or the request matches the favicon URL
  b. If the favicon is not known, store the request temporarily
3. When we learn about the favicon URL, go over the cache of rejected-but-temporarily-stored requests, find the favicon request and create a protocol event for it. Then, remove the cache and store the favicon to short-circuit this logic for future requests.

I haven't looked very carefully into the available APIs, but I think this should work.

We could also try to find someone experienced in how necko/places/whetever handles favicons and ask for a better idea!

Comment 9

[Tom Tromey :tromey]

I suspect this will be fixed by bug 1453751

Comment 10

[Tom Tromey :tromey]

Indeed, that fixed it.
I verified it by opening bugzilla.mozilla.org while looking at the network panel.