Improve handling of search term parameter names
Categories
(Firefox :: Search, task, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox133 | --- | fixed |
People
(Reporter: standard8, Assigned: mbeier)
References
(Blocks 2 open bugs)
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 EngineURL
s 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•9 months ago
|
Assignee | ||
Updated•4 months ago
|
Assignee | ||
Comment 1•4 months ago
|
||
Comment 3•4 months ago
|
||
Backed out for causing docu perma failures
Backout link: https://hg.mozilla.org/integration/autoland/rev/7a925f96907d627e7f808399c82155fe74828165
Reporter | ||
Updated•4 months ago
|
Comment 5•4 months 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•4 months ago
|
Comment 7•4 months ago
|
||
bugherder |
Description
•