Load search engines from appdir/distribution/searchplugins dir tree

RESOLVED FIXED in Firefox 3 alpha8

Status

()

Firefox
Search
RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: thunder, Assigned: thunder)

Tracking

Trunk
Firefox 3 alpha8
Points:
---
Bug Flags:
blocking-firefox3 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

11 years ago
I need to load up directories with engines that will live in appdir/distribution/* somewhere.  The actual directory to load will change depending on locale, so I can't hardcode it to be loaded during the search service's init.  It would be great if I could simply run loadEngines on the right path from my code.

Currently, FYI, I'm running my code using the "final-ui-startup" hook in nsBrowserGlue.js.  Though this may change.

Let me know what else you'd like to know.  I'm not tied to loadEngines as such.  addEngineToStore could be an option too.  Though I'd more or less reimplement loadEngines.
(Assignee)

Comment 1

11 years ago
Requesting blocker status.
Flags: blocking-firefox3?
(Assignee)

Updated

11 years ago
Blocks: 392501
(Assignee)

Comment 2

11 years ago
Created attachment 278561 [details] [diff] [review]
expose loadEngines v1

Gavin, does this look OK?
Attachment #278561 - Flags: review?(gavin.sharp)
(Assignee)

Comment 3

11 years ago
Changing bug's summary; the search service is not necessarily the correct place to fix the real bug that needs to be fixed (loading distro search plugins)
Assignee: gavin.sharp → thunder
Summary: Expose SearchService._loadEngines → Load search engines from appdir/distribution/searchplugins dir tree
(Assignee)

Comment 4

11 years ago
Created attachment 279822 [details] [diff] [review]
load distribution search engines v1

This patch makes it so, if they exist, the distribution search plugin directories will be prepended to the current list of search plugin directories.

It seems to work well on my machine.
Attachment #278561 - Attachment is obsolete: true
Attachment #279822 - Flags: review?(gavin.sharp)
Attachment #278561 - Flags: review?(gavin.sharp)
(Assignee)

Updated

11 years ago
Attachment #279822 - Flags: review?(mconnor)
OS: Mac OS X → All
Hardware: PC → All
Comment on attachment 279822 [details] [diff] [review]
load distribution search engines v1

Looks OK to me, might want to get Benjamin and Axel to review the idea if they haven't already.
Attachment #279822 - Flags: review?(gavin.sharp) → review+
(Assignee)

Comment 6

11 years ago
Comment on attachment 279822 [details] [diff] [review]
load distribution search engines v1

Requesting further review from Benjamin
Attachment #279822 - Flags: review?(mconnor) → review?(benjamin)
I'd prefer a comment for that function that actually defines what is intended to happen.

I guess Benjamin knows if NS_XPCOM_CURRENT_PROCESS_DIR is doing exactly what we need for all weird ways of invoking Firefox, the comments in nsDirectoryServiceDefs.h didn't enlighten me.

Apart from this, there isn't a whole lot l10n here, this is more about partners and if that has locale dependent parts, and I'm not familiar with anything there.
(Assignee)

Comment 8

11 years ago
Created attachment 279945 [details] [diff] [review]
load distribution search engines v1.1

Thanks Axel.  Here is a new patch with a comment above the function explaining what is going on.

About NS_XPCOM_CURRENT_PROCESS_DIR, I was also doubtful (the docs at http://developer.mozilla.org/en/docs/Code_snippets:File_I/O#Getting_special_files say "usually") but this actually came up in bug 392501 comment #8.  So I think it's OK.
Attachment #279822 - Attachment is obsolete: true
Attachment #279945 - Flags: review?(benjamin)
Attachment #279822 - Flags: review?(benjamin)

Updated

11 years ago
Attachment #279945 - Flags: review?(benjamin) → review+
(Assignee)

Comment 9

11 years ago
Comment on attachment 279945 [details] [diff] [review]
load distribution search engines v1.1

requesting m8 approval
Attachment #279945 - Flags: approval1.9?
Flags: blocking-firefox3? → blocking-firefox3+
Comment on attachment 279945 [details] [diff] [review]
load distribution search engines v1.1

a=me on behalf of 1.9 drivers, and carrying over mconnor's approval from dependent bug 392501
Attachment #279945 - Flags: approval1.9? → approval1.9+
(Assignee)

Comment 11

11 years ago
Checking in nsIBrowserSearchService.idl;
/cvsroot/mozilla/browser/components/search/nsIBrowserSearchService.idl,v  <--  nsIBrowserSearchService.idl
new revision: 1.19; previous revision: 1.18
done
Checking in nsSearchService.js;
/cvsroot/mozilla/browser/components/search/nsSearchService.js,v  <--  nsSearchService.js
new revision: 1.101; previous revision: 1.100
done
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
(Assignee)

Comment 12

11 years ago
Wheee - wrong patch.  Reverted:

Checking in browser/components/search/nsIBrowserSearchService.idl;
/cvsroot/mozilla/browser/components/search/nsIBrowserSearchService.idl,v  <--  nsIBrowserSearchService.idl
new revision: 1.20; previous revision: 1.19
done
Checking in browser/components/search/nsSearchService.js;
/cvsroot/mozilla/browser/components/search/nsSearchService.js,v  <--  nsSearchService.js
new revision: 1.102; previous revision: 1.101
done
(Assignee)

Comment 13

11 years ago
And relanded:

Checking in browser/components/dirprovider/nsBrowserDirectoryProvider.cpp;
/cvsroot/mozilla/browser/components/dirprovider/nsBrowserDirectoryProvider.cpp,v  <--  nsBrowserDirectoryProvider.cpp
new revision: 1.19; previous revision: 1.18
done
You need to log in before you can comment on or make changes to this bug.