We jump through a variety of hoops to get favicons to show up in things like about:home / about:newtab. It looks like sometimes we work around this by using data URIs. If we were able to use the page-icon service from the privileged about content process, we could side-step most of that complexity and probably improve memory usage while we're at it (since each data URI is a potentially large string that each about:newtab will hold in memory).

See bug 1184701 for a similar effort where we made the page thumbnail protocol work from the privileged about content process.

Hey mak, any objections if I try to move this forward?

I think the only concern is related to security/privacy, that boils down to our isolation safety, since if a third party should get access to this data from content they could extract info about the user history. I don't think it's a major problem considered that would be a break of our privileged/unprivileged boundary with a lot more implications.

About the implementation, as pointed out on Matrix, it will likely require IPC because other processed can't read from db.

Hey nika,

I've just started setting up the boilerplate for getting the page-icon:// protocol to work from the privileged about content process. It's at the point where it compiles, but that's it - I haven't actually done the interesting part where I pass the stream from the parent process down to content. Apparently, you have some goodies in the works that might make this easier for me to do? Are there any examples I can look at?

We discussed the possibilities a bit on matrix, so clearing ni

Hey nika,

Thanks for all your help so far! So what I have in https://phabricator.services.mozilla.com/D145622 mostly works - I can get page-icon: URIs loading in the privileged about content process when they point at an existing favicon. Yay!

What doesn't appear to work is the failure case, when a favicon doesn't exist (if you, for example, request page-icon:https://www.page-does-not-exist.com), we fail to get the default icon streamed down to the content process. I'm not sure why that is...

I'm creating a Pipe and passing the nsIOutputStream along to the FaviconDataCallback thing to have the existing infrastructure write to, and then on the other side of the pipe, I'm using NS_AsyncCopy to copy the nsIInputStream down to the DataPipeSender. I'm not 100% sure why the Pipe is necessary - if I just pass the DataPipeSender to the FaviconDataCallback to write to, the content process doesn't seem to get it.

At any rate, in the failure case, when no favicon can be found, we go through some rigamarole to get the default favicon here: https://searchfox.org/mozilla-central/rev/390f7009e9e5a9585297aeea5fb9202f800eaf12/toolkit/components/places/PageIconProtocolHandler.cpp#57-104

My patch mostly keeps that the same except for making the nsCOMPtr<nsIChannel> a Maybe<nsCOMPtr<nsIChannel>>.

Any idea why the default favicon case isn't working? And is there a reason I need the Pipe and can't just ->Write into the DataPipeSender?

I left some comments in the phabricator revision, so clearing this needinfo

Depends on D147180

Depends on D147181

Depends on D147334

ni?ing myself to send a message to firefox-dev about this capability once this lands and sticks.

https://hg.mozilla.org/mozilla-central/rev/0f60dbe1d87b
https://hg.mozilla.org/mozilla-central/rev/12c098c6d1a5
https://hg.mozilla.org/mozilla-central/rev/3bbdfa6e9b99
https://hg.mozilla.org/mozilla-central/rev/2f3bf2d5f1a6

Sent a message to firefox-dev: https://groups.google.com/g/firefox-dev/c/-FJSd_mbsNE