Improve handling of search term parameter names
Categories
(Firefox :: Search, task, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox133 | --- | fixed |
People
(Reporter: standard8, Assigned: mbeier)
References
(Blocks 1 open bug)
Details
(Whiteboard: [sng])
Attachments
(1 file)
With the new search configuration, we now have a dedicated searchTermParamName. For application provided engines, we should be able to use those details directly, rather than going through the conversion to a URL and look for {searchTerms} process.
It might be that we extend EngineURLs with a specific option for the search term, rather than having AppProvidedSearchEngine add a "normal" parameter.
Some exploration might be needed for the best way of doing this. Ideally, we'd potentially only process once the search term parameter name for other engine types as well.
Whilst here, or maybe in a follow-up, we should also update SearchEngine.searchTermFromResult to get the search term parameter name directly, rather than going through getURLParsingInfo(). This would be more efficient in avoiding unnecessary conversions of the URL template to a nsIURI.
Updated•2 years ago
|
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 1•1 year ago
|
||
Comment 3•1 year ago
|
||
Backed out for causing docu perma failures
Backout link: https://hg.mozilla.org/integration/autoland/rev/7a925f96907d627e7f808399c82155fe74828165
| Reporter | ||
Updated•1 year ago
|
Comment 5•1 year ago
|
||
Backed out for causing docu perma failures
Backout link: https://hg.mozilla.org/integration/autoland/rev/57a73a854a08b460c721a973cbca8879a1f3cf81
[Failure log -> https://treeherder.mozilla.org/logviewer?job_id=477680830&repo=autoland&lineNumber=810](sphinx.errors.ExtensionError: Handler <function analyze at 0x7f61129ecea0> for event 'builder-inited' threw an exception (exception: Your code contains multiple documented objects at each of these paths:)
| Reporter | ||
Updated•1 year ago
|
Comment 7•1 year ago
|
||
| bugherder | ||
Description
•