<div dir="ltr">This landed once again and is in current Nightlies. There are a couple of regressions I'm tracking already, the most serious of which can cause a previous site's favicon display for a new page loaded in the same tab, I think that's a pretty easy fix thankfully.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jun 26, 2018 at 8:22 AM Dave Townsend <<a href="mailto:dtownsend@mozilla.com">dtownsend@mozilla.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Aaaand it's been backed out. Hold those thoughts for a little while!<div><br></div><div>Also I forgot to mention the bug number: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1453751" target="_blank">https://bugzilla.mozilla.org/show_bug.cgi?id=1453751</a></div></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Jun 25, 2018 at 6:02 PM Dave Townsend <<a href="mailto:dtownsend@mozilla.com" target="_blank">dtownsend@mozilla.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I just landed a fairly major change to how favicons are loaded on mozilla-inbound and it looks like it might stick. Previously we relied on the places service and XUL image elements to load favicons from the main process but now we load the favicon data in the content process and then just re-use that data everywhere we need it, currently as a data URI.<div><br></div><div>This should mean we now honour CSP rules for favicons, expose favicon requests properly to webextensions and a few other things. But the change is significant enough that there might be some edge cases that changed.</div><div><br></div><div>If you notice any oddities around favicons in tabs, the new tab page or the all tabs menu please CC me on the bugs you file.</div></div>
</blockquote></div>
</blockquote></div>