Closed Bug 341405 Opened 18 years ago Closed 18 years ago

accept ? %s as a command-line parameter that launches browser and runs a search

Categories

(Firefox :: Shell Integration, defect)

2.0 Branch
x86
Windows Vista
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 2 beta2

People

(Reporter: beltzner, Assigned: benjamin)

References

(Blocks 1 open bug, )

Details

(Keywords: fixed1.8.1)

Attachments

(1 file)

From Sean Lyndersay of the Windows Vista team: As you may or may not know, Vista has local search capabilities built-in. Many of those entry-points have a way to send the search query to a web search engine. For a picture of what this entry- point might look like, see the picture of the start menu on this page: http://www.microsoft.com/windowsvista/features/foreveryone/ searchorg.mspx As you can see, at the bottom of the start menu, there is an option to "Search Internet" using the search term the user has typed (in this case "ca"). The way this feature is implemented is that the user's default browser is launched with the string "? Searchterm" as a parameter (i.e., a question mark followed by the string the user has typed so far). What we do is pretty much the equivalent of appending "? <search term>" to the browser's command line (which today simply does an "I'm feeling lucky" search in FF). So it would be: firefox.exe "? foo" Technically we're using ShellExecuteEX to open the program registered for the http protocol and then we pass "? <search term>" as the lpParameters argument, where <search term> is replaced with the term the user wanted to query for. This behavior is in the latest public Vista Beta, so it should be easy to check out (To try it out you can select "search the internet" from Vista's Start menu, then spawn a search from there while FF is the default browser).
Benjamin, is this difficult to do?
Flags: blocking-firefox2+
No, though the fact that it doesn't use standard /flag or -flag is quite annoying.
FWIW, on testing with Vista the param is passed as "? searchparam" (one argument with a space), not as two arguments
This at least handles the argument reasonably: it opens a new window to display the search results. If you already have Firefox open, this will *not* obey tabbed-browsing preferences, because that requires changes to nsIBrowserDOMWindow.
Attachment #225606 - Flags: superreview?
Attachment #225606 - Flags: review?
Attachment #225606 - Flags: superreview?(mconnor)
Attachment #225606 - Flags: superreview?
Attachment #225606 - Flags: review?(gavin.sharp)
Attachment #225606 - Flags: review?
Assignee: nobody → benjamin
Comment on attachment 225606 [details] [diff] [review] Open a new window with the default search engine, rev. 1 >+function doSearch(searchTerm, cmdLine) { Is there a reason for passing the cmdLine object itself, instead of having the caller pass just the features (especially since both can just call this.getFeatures)?
Attachment #225606 - Flags: review?(gavin.sharp) → review+
Comment on attachment 225606 [details] [diff] [review] Open a new window with the default search engine, rev. 1 >+function doSearch(searchTerm, cmdLine) { >+ var ss = Components.classes["@mozilla.org/browser/search-service;1"]. >+ getService(nsIBrowserSearchService); >+ >+ var submission = ss.defaultEngine.getSubmission(searchTerm); >+ >+ // fill our nsISupportsArray with uri-as-wstring, null, null, postData >+ var sa = Components.classes["@mozilla.org/supports-array;1"]. >+ createInstance(Components.interfaces.nsISupportsArray); >+ >+ var wuri = Components.classes["@mozilla.org/supports-string;1"]. >+ createInstance(Components.interfaces.nsISupportsString); >+ wuri.data = submission.uri.spec; I'm not so keen on this style, please use the prevailing (common) style with aligned periods as you do with wwatch below otherwise, sr=me, please make sure there's a bug on the XXX comment
Attachment #225606 - Flags: superreview?(mconnor) → superreview+
Attachment #225606 - Flags: approval1.8.1+
Target Milestone: Firefox 2 beta1 → Firefox 2 beta2
Fixed-on-trunk
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Blocks: 343006
Fixed on 1.8 branch for ff2b1
No longer blocks: 343006
Keywords: fixed1.8.1
Blocks: 343006
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: