So far I've found various things and possible solutions: 1. the star button is not shown on about:blank, about:newTab, about:home, though we still update its state. We can use pageproxystate to avoid the call to updateStarState, if we invoke it manually in popups using the bookmarkthispagebroadcaster (I have a patch, I think) 2. about:home and about:newtab define a link rel="icon" that tabbrowser catches and it tries to store it into the favicons service. We could just remove the links. 3. about:home and about:newtab are using history for link coloring, I don't recall if disableglobalhistory disables link coloring off-hand, but looks like a plausible improvement if these pages don't really need it

(In reply to Marco Bonardo [::mak] from comment #0) > So far I've found various things and possible solutions: > > 1. the star button is not shown on about:blank, about:newTab, about:home, > though we still update its state. We can use pageproxystate to avoid the > call to updateStarState, if we invoke it manually in popups using the > bookmarkthispagebroadcaster (I have a patch, I think) What happened to the patch? :-) > 2. about:home and about:newtab define a link rel="icon" that tabbrowser > catches and it tries to store it into the favicons service. We could just > remove the links. Then there won't be icons, right? How would that work? > 3. about:home and about:newtab are using history for link coloring, I don't > recall if disableglobalhistory disables link coloring off-hand, but looks > like a plausible improvement if these pages don't really need it This makes sense to me.

I had made a very WIP patch, but even disabling most of these things still ended up initializing the connection. But I didn't have much time to continue my investigation. I should still have that patch in queue and I can maybe extract some code for the star. (In reply to :Gijs from comment #1) > > 2. about:home and about:newtab define a link rel="icon" that tabbrowser > > catches and it tries to store it into the favicons service. We could just > > remove the links. > > Then there won't be icons, right? How would that work? We could either hardcode something at this level to force the firefox icon on some pages: https://searchfox.org/mozilla-central/rev/14d933246211b02f5be21d2e730a57cf087c6606/browser/base/content/tabbrowser.xml#812 Or, we could change the favicons service to not store chrome favicons in setAndFetchFaviconForPage and leave the code as-is. The downside of both approaches is that if a user bookmarks an about:something page, it won't have an icon. > > 3. about:home and about:newtab are using history for link coloring, I don't > > recall if disableglobalhistory disables link coloring off-hand, but looks > > like a plausible improvement if these pages don't really need it > > This makes sense to me. IIRC, disableglobalhistory didn't prevent link coloring from querying, but I don't remember details off-hand.

(In reply to :Gijs from comment #1) > > 2. about:home and about:newtab define a link rel="icon" that tabbrowser > > catches and it tries to store it into the favicons service. We could just > > remove the links. > > Then there won't be icons, right? How would that work? We tried removing the <link rel="icon" tag from activity stream (bug 1422074) and hardcoded the icon in browser code for about:home and about:newtab (bug 1401955), but we had to add the link tag back to fix some regressions (eg. when navigating back to the page, bug 1423256).