Refactor AppProvided Engine vs UserInstalledAppEngine
Categories
(Firefox :: Search, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox143 | --- | fixed |
People
(Reporter: mcheang, Assigned: mbeier)
References
Details
(Whiteboard: [sng])
Attachments
(1 file)
Context
In AppProvidedSearchEngine.sys.mjs, we currently have both AppProvidedSearchEngine and UserInstalledAppEngine defined in the same file. This is pretty confusing because "app-provided" should mean the engine is bundled with Firefox. Users shouldn't be able to install something that’s considered "app-provided." However, we now have a feature where users can install "app-provided" engines through contextual search.
Problem
The terminology has started to blur. Right now, AppProvidedSearchEngine and UserInstalledAppEngine are lumped together even though they represent different concepts. We need a clearer separation between engines that are pre-bundled with Firefox and those installed by users.
Solution
AppProvidedSearchEngine and UserInstalledAppEngine are engines from search-config-v2. That's the common theme.
We can introduce a ConfigEngine base class that both app-provided and user-installed config-based engines can extend. Something like:
SearchEngine
|
ConfigEngine
/ \
AppProvidedConfigEngine UserInstalledConfigEngine
Follow-ups / Cleanup
- All instances of
UserInstalledAppEngineshould be renamed to something more accurate, such asUserInstalledConfigEngine
→ UserInstalledAppEngine references - We could also consider removing
nsISearchEngine. The use ofengine.wrappedJSObjectfeels unnecessary and kind of a nuisance at this point
→ nsISearchEngine
| Reporter | ||
Updated•6 months ago
|
Updated•6 months ago
|
Updated•6 months ago
|
| Assignee | ||
Comment 1•6 months ago
|
||
Updated•5 months ago
|
Updated•5 months ago
|
Comment 3•5 months ago
|
||
| bugherder | ||
Updated•5 months ago
|
Description
•