Closed Bug 532444 Opened 10 years ago Closed 10 years ago

Create search engine cache in BrowserCLH.js

Categories

(Firefox for Android Graveyard :: General, defect)

x86
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
fennec1.0

People

(Reporter: mfinkle, Assigned: mfinkle)

Details

Attachments

(1 file, 1 obsolete file)

Everytime we open the awesomebar, we load search engines. The first time the awesomebar is opened, the search engines are added to a search engine cache, which can take ~450ms on the N900.

We could get the search engine service to load the engines, and create the cache, in BrowserStartup.js, which is run during the Fennec installation.

Fennec is launched with -silent during installation, so we can save some runtime slowdown by moving the cache generation to install time.
tracking-fennec: --- → ?
All that's needed to trigger a build of the cache is a getService() of the search service, fwiw.
Attached patch patch (obsolete) — Splinter Review
This patch just does a getService on the browser search from BrowserStartup
Assignee: nobody → mark.finkle
Attachment #415691 - Flags: review?(gavin.sharp)
Comment on attachment 415691 [details] [diff] [review]
patch

This doesn't seem to work... I get:

throw from SearchService: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIProperties.get]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: file:///Users/gavin/mozilla/mobile192/obj-fennec/mobile/dist/Fennec.app/Contents/Frameworks/XUL.framework/Versions/1.9.2b5pre/components/nsSearchService.js :: getDir :: line 418"  data: no]

on the initial attempt to init, presumably because the directory service isn't fully set up yet? We might have to find another place to put this... command line handler, maybe?
Attachment #415691 - Flags: review?(gavin.sharp) → review-
Attached patch patch 2Splinter Review
OK, I see the error now too. Moving to BrowserCLH gets everything working as intended.

I also added a check for the "silent" flag, since the code is in the CLH now. Now we only do this when "-silent" is passed on the command line.
Attachment #415691 - Attachment is obsolete: true
Attachment #416033 - Flags: review?(gavin.sharp)
Comment on attachment 416033 [details] [diff] [review]
patch 2

>diff --git a/components/BrowserCLH.js b/components/BrowserCLH.js

>   handle: function fs_handle(cmdLine) {
>+    // Instantiate the search service so the search engine cache is created now
>+    // instead when the application is running. The install process will register
>+    // this component by using the -silent command line flag, thereby creating
>+    // the cache during install, not runtime.
>+    if (cmdLine.findFlag("silent", false) > -1) {
>+      let searchService = Cc["@mozilla.org/browser/search-service;1"].
>+                          getService(Ci.nsIBrowserSearchService);
>+    }

I like this better - isolates it to the -silent run which is less likely to cause issues in the future if we stop using the search service on normal startups and can live with delaying its initialization.

This depends on our handler being registered to run before "y-default" (nsDefaultCLH), which consumes -silent. We may want to note that here just for completeness. Eventually we may want to handle -silent ourselves and stop shipping the default handler somehow, just to cut down on the number of JS components we need to load.
Attachment #416033 - Flags: review?(gavin.sharp) → review+
Summary: Create search engine cache in BrowserStartup.js → Create search engine cache in BrowserCLH.js
pushed:
https://hg.mozilla.org/mobile-browser/rev/fae38ea6ab0e
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → Post-B5
tracking-fennec: ? → ---
You need to log in before you can comment on or make changes to this bug.