Closed Bug 1628423 Opened 4 years ago Closed 4 years ago

Cause field is set to `img-lazy` for favicons

Categories

(DevTools :: Netmonitor, defect, P2)

defect

Tracking

(firefox77 fixed)

RESOLVED FIXED
Firefox 77
Tracking Status
firefox77 --- fixed

People

(Reporter: mbalfanz, Assigned: hiro)

References

(Blocks 1 open bug)

Details

Attachments

(5 files)

Attached image image.png

STR:

  • visit a website like google.com
  • open devtools with the network panel
  • hard refresh the page and look for the the request to the favicon

ER: Cause field should bet set to img

AR: Cause field is set to lazy-img

Seems like Ci.nsIRequest.LOAD_BACKGROUND is true for favicons.

Flags: needinfo?(hikezoe.birchill)

Huh, I didn't know that favicons are associated with nsIContentPolicy::TYPE_IMAGE, I thought TYPE_IMAGE is only for DOM elements. Need to figure out a way to differentiate them.

Thanks for the report Martin!

Honza

Priority: -- → P2

I found that there is an attribute exposing the internal content type policy which can be used to distinguish favicon requests.

Assignee: nobody → hikezoe.birchill
Flags: needinfo?(hikezoe.birchill)

Sounds promising, thanks for working on this Hiro!

Honza

Status: NEW → ASSIGNED

I finished writing a test case for favicon requests, but there are a couple of annoying things to handle favicon requests in test. A biggest one is that the request happens in FaviconLoader.jsm, it's in load() function, so the stack is totally out of control for the test. Though I did introduce wild card "*" for such call stacks, I am open how to handle them.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=5e715db729da336f793b308fec4b193c86a1dde8

Note that it seems unpredictable when we receive the favicon request in the
network monitor, for example, on a Linux machine, the favicon request for a
static link element after the stylesheet link element in
html_cause-test-page.html it happens after the XHR request was received. So
instead of using a static link favicon element, we add a favicon link
dynamically in tests. Unfortunately there is no handy way to tell a favicon
request has done in contents, so we use LinkHandlerParent utility here.

Also note that the favicon request is triggered in FaviconLoader.jsm, as of
m-c revision of ad39876e99241d98766ba2e5c74fd984cba79191, it's triggered at [1]
in FaviconLoad.load(), which means it's out of control for the test. So in this
patch I did introduce wild card "*" to match such kind of request's triggers.

[1] https://searchfox.org/mozilla-central/rev/9120151ddb35f2d4c37bfe613a54a4f10a9a3dc5/browser/modules/FaviconLoader.jsm#165

Depends on D70571

Attachment #9139873 - Attachment description: Bug 1628423 - Add test cases for image srcset to make sure the next change will not regress the cases. r?honza → Bug 1628423 - Add test cases for image srcset to make sure a subsequent change will not regress the cases. r?honza

Favicon requests happen in 'resource:///modules/FaviconLoader.jsm', so we need
the full URL to match sorted results in tests.

Depends on D70571

Pushed by hikezoe.birchill@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d8bb387bac95
Add test cases for image srcset to make sure a subsequent change will not regress the cases. r=Honza
https://hg.mozilla.org/integration/autoland/rev/2f099a730129
Use full URL path for expected stacks to sort them properly in tests. r=Honza
https://hg.mozilla.org/integration/autoland/rev/6ca89ac7b25e
Use the proper property name for filename in stacks. r=Honza
https://hg.mozilla.org/integration/autoland/rev/dbafcc52a866
Distinguish favicon loads from lazy loading images. r=Honza
QA Whiteboard: [qa-77b-p2]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: