Cause field is set to `img-lazy` for favicons
Categories
(DevTools :: Netmonitor, defect, P2)
Tracking
(firefox77 fixed)
Tracking | Status | |
---|---|---|
firefox77 | --- | fixed |
People
(Reporter: mbalfanz, Assigned: hiro)
References
(Blocks 1 open bug)
Details
Attachments
(5 files)
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.
Reporter | ||
Updated•4 years ago
|
Assignee | ||
Comment 1•4 years ago
|
||
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.
Assignee | ||
Comment 3•4 years ago
|
||
I found that there is an attribute exposing the internal content type policy which can be used to distinguish favicon requests.
Comment 4•4 years ago
|
||
Sounds promising, thanks for working on this Hiro!
Honza
Assignee | ||
Comment 5•4 years ago
|
||
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
Assignee | ||
Comment 6•4 years ago
|
||
Assignee | ||
Comment 7•4 years ago
|
||
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.
Depends on D70571
Updated•4 years ago
|
Assignee | ||
Comment 8•4 years ago
|
||
Favicon requests happen in 'resource:///modules/FaviconLoader.jsm', so we need
the full URL to match sorted results in tests.
Depends on D70571
Assignee | ||
Comment 9•4 years ago
|
||
Depends on D70664
Assignee | ||
Comment 10•4 years ago
|
||
Comment 11•4 years ago
|
||
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
Comment 12•4 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/d8bb387bac95
https://hg.mozilla.org/mozilla-central/rev/2f099a730129
https://hg.mozilla.org/mozilla-central/rev/6ca89ac7b25e
https://hg.mozilla.org/mozilla-central/rev/dbafcc52a866
Updated•4 years ago
|
Description
•