1401214 - Investigate code early initializing the Places Connection on startup

Status: NEW

(Toolkit :: Places, enhancement, P3)

Description

[Marco Bonardo [:mak]]

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

Comment 1

[:Gijs (he/him)]

(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.

Comment 2

[Marco Bonardo [:mak]]

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.

Comment 3

[Florian Quèze [:florian]]

(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).

Comment 4

[Dale Harvey (:daleharvey)]

This will need to be reinvestigated as there have probably been changes around what could cause early initialisation