New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 448427 link

Starred by 18 users

Issue metadata

Status: Fixed
Closed: Nov 20
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

Allow ServiceWorker to handle favicon requests

Project Member Reported by, Jan 13 2015

Issue description

At the moment, we explicitly bypass service workers when fetching a favicon to prevent cross origin favicon tainting. It would be great if we could allow service workers to provide a favicon.

We could simply by pass the service worker if the request is cross origin or not cache a cross origin favicon if provided by a service worker.
Labels: -Pri-2 Pri-3
Status: Available
Thanks for filing this!

I'm reading this as a P3 task. Actual customers looking forward to this would help boost the priority.

Comment 2 by, Apr 16 2015

Labels: -Pri-3 Pri-2 M-44
The security work at  issue 435446  may help with this.

Comment 3 by, May 21 2015

Labels: -M-44 MovedFrom-44 M-45
Status: Untriaged
[AUTO] Moving all non essential bugs to the next Milestone.  (This decision is based on the labels attached to your ticket.)


Comment 4 Deleted

Comment 5 by, Jun 29 2015

Labels: -M-45 M-47
Status: Available

Comment 6 by, Oct 26 2015

Labels: -M-47
webmanifest icons also need to be provided by service worker.
Re: c#7, thank you for reporting it. I think it's a separate issue. Could you file a new one?

Comment 9 by, Aug 23 2016

Status: Assigned (was: Available)
Labels: M-56
Labels: -M-56 WorkerPainPoint
See more context at  issue 422250  and  issue 413097 .
I'm finding this quite troubling that my service worker is not able to handle favicon requests (from my same domain). It would be really nice to see this fixed finally.
I think it would be more secure and easier for future updates if the SW would have it's own site specific cache for every resource. Also imo cross origin should be disabled for the SW too. Otherwise you can route your request over the SW using the message event and postMessage. Maybe it would be easier to pre define rules for external resources since they shouldn't be modified anyway (It could be important for the SW developer to send an event to refetch this resource as it maybe outdated). I think usually if you really need the full control over a resource you could easily host it by yourself.
Status: Started (was: Assigned)
Project Member

Comment 16 by, Nov 15

The following revision refers to this bug:

commit 7578354354afd3b9c74c54585b3ed0a89c864850
Author: Tsuyoshi Horo <>
Date: Thu Nov 15 00:21:35 2018

Support service worker handling of same origin favicon requests

There was a bug that service workers can inject image into favicon cache of any
origins ( ). This is becuase the icon URL is used as a key of the
"favicons" table in ThumbnailDatabase. So currently
MultiResolutionImageResourceFetcher sets the SkipServiceWorker flag of all
favicon requests, to make it impossible to handle the fetch event of favicon
requests in service workers.

Ideally we should change the data scheme of ThumbnailDatabase not to reuse the
favicon which was served from a service worker. But it is complicated to change
the data scheme, and also there is a performance trade-off.

So this cl change MultiResolutionImageResourceFetcher to set the
SkipServiceWorker flag only for cross origin favicon requests. So the service
worker can handle the same origin favicon requests.

Bug:  448427 
Change-Id: I3237ae9c4d0cc5d2374830e2c4865a8a852d37c6
Reviewed-by: Matt Falkenhagen <>
Reviewed-by: Kinuko Yasuda <>
Commit-Queue: Tsuyoshi Horo <>
Cr-Commit-Position: refs/heads/master@{#608189}

Labels: M-72
Status: Fixed (was: Started)
Created a chromestatus at

Marking this fixed.  Created issue 906986 for cross-origin favicons.

Sign in to add a comment