Investigate code early initializing the Places Connection on startup

NEW
Unassigned

Status

()

enhancement
P3
normal
2 years ago
5 months ago

People

(Reporter: mak, Unassigned)

Tracking

(Blocks 1 bug)

unspecified
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox57 fix-optional)

Details

(Whiteboard: [fxsearch] [fxperf:p3])

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
Whiteboard: [fxsearch]
Blocks: PlacesIO
Priority: P2 → P3
Whiteboard: [fxsearch] → [fxsearch] [fxperf]
(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.
Flags: needinfo?(mak77)
Whiteboard: [fxsearch] [fxperf] → [fxsearch] [fxperf:p3]
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.
Flags: needinfo?(mak77)
(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).
Blocks: PlacesJank
No longer blocks: PlacesIO
You need to log in before you can comment on or make changes to this bug.