Last Comment Bug 408248 - When Seamonkey is launched from the command line with 'seamonkey.exe "? queryterm"', it throws an error message instead of launching the default search engine and searching for 'queryterm', the expected behaviour in Windows XP
: When Seamonkey is launched from the command line with 'seamonkey.exe "? query...
: helpwanted, imap-interop
Product: SeaMonkey
Classification: Client Software
Component: General (show other bugs)
: SeaMonkey 1.1 Branch
: x86 Windows XP
-- major with 1 vote (vote)
: ---
Assigned To: general
Depends on:
  Show dependency treegraph
Reported: 2007-12-13 13:07 PST by Hammer
Modified: 2010-01-12 15:22 PST (History)
9 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

Proposed patch (2.82 KB, patch)
2007-12-31 12:28 PST,
bugzilla: review+
jag-mozilla: superreview+
Details | Diff | Splinter Review

Description User image Hammer 2007-12-13 13:07:52 PST
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071128 SeaMonkey/1.1.7 Mnenhy/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20071128 SeaMonkey/1.1.7 Mnenhy/

Windows XP handles default browsers other than its own Internet Explorer by modifying the following registry keys:
HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\SearchScopes

When a third party application requests the launch of the default internet browser (in my case seamonkey, obviously), to search for a queryterm, using that browsers default internet search engine (in my case google), the operating system will launch the default internet browser, using the following command format:
browser.exe “? queryterm”
With seamonkey this operation fails with the following error message:
‘The URL is not valid and cannot be loaded’
Trying the same with Internet Explorer, Opera or Safari is successful. Seamonkey itself also already supports using the format ‘? Queryterm’ in the addressbar, if ‘Enable Internet Keywords’ is set in preferences/Navigator/Smart Browser.

Reproducible: Always

Steps to Reproduce:
1.Open a command line (going to Start/Run/cmd and hit enter)
2.Navigate to the directory in which seamonkey is installed (e.g. C:\program files\\seamonkey)
3.type seamonkey.exe "? queryterm"


1. Download Process Explorer from
2. Run that program
3. Highlight any process in the list
4. Hit Ctrl+M

Actual Results:  
Seamonkey launches with the error message
'The URL is not valid and cannot be loaded'

Expected Results:  
Seamonkey should launch and search for your queryterm, using the default search engine, OR if you used Process Explorer to reproduce the problem
Seamonkey should launch and search for the process that you highlighted in process explorer.

This seems like a fairly simple problem with how SM handles command line input under Windows XP (and presumably other windows versions as well).
Seamonkey should accept "? queryterm" and launch its default search engine and search for queryterm, a behavior that is already implemented when a queryterm is put into the address bar (provided that behavior has been switched on in preferences).
Comment 1 User image Hammer 2007-12-13 13:10:30 PST
Addendum: I only confirmed this problem with 1.1.7, but it may also exist on the trunk as well as almost certainly in older versions of SM.
Comment 2 User image 2007-12-31 10:22:15 PST
OK, so this is techincally feasible, if you turn on the keyword.enabled prefernce, and we change some of the backend code. On the branch we would need to change several places, including the following:

navigator.js Startup() to tell loadURI to allow keyword fixup.
nsNativeAppSupportWin.cpp OpenBrowserWindow() to allow keyword fixup.

On the trunk we would only need to change nsBrowserContentHandler.js resolveURIInternal() however it would need tweaking because resolveURI has a bug and can't handle arguments including ? or # characters.
Comment 3 User image 2007-12-31 12:28:12 PST
Created attachment 294981 [details] [diff] [review]
Proposed patch

Should jag like this I'll then find someone to test on Windows.
Comment 4 User image 2008-01-01 07:16:38 PST
Comment on attachment 294981 [details] [diff] [review]
Proposed patch

On the basis that this is OS integration ;-)
Comment 5 User image Frank Wein [:mcsmurf] 2008-01-01 13:00:18 PST
BTW: One can find more info on this Windows feature under (for Vista and Server 2008).
Comment 6 User image Frank Wein [:mcsmurf] 2008-01-01 15:53:36 PST
Firefox handles this differently, see Bug 341405, Attachment 225606 [details] [diff]. Their patch has the advantage that it doesn't need keywords to be enabled. Neil, what do you think (like better)? :) If we use Attachment 294981 [details] [diff] here, then I think we should also enable keywords by default so that the search feature in Vista always works when SeaMonkey is the default browser.
Comment 7 User image Frank Wein [:mcsmurf] 2008-01-02 01:46:40 PST
Though now that I think about it...we have no search service yet (which that patch uses) ;-).
Comment 8 User image 2008-01-02 02:57:48 PST
We have a search service, if you'd prefer to go that way...
Comment 9 User image Hammer 2008-01-04 11:33:59 PST
Guys, has anyone checked whether this still exsists on latest trunk builds?
Comment 10 User image therube 2008-01-22 16:36:12 PST
I basically posed (what I believe to be) the same question here:

AutoRuns Search Functionality with SeaMonkey


Autoruns 9.01 with Alternative Browsers

Might help.

On the trunk, seamonkey.exe "? autoruns" opens the URL:


and proceeds to provide a directory listing of the current directory.

Actually I'm not sure I understand the reasoning for the construct "? search_item"?  From a command line, seamonkey.exe URL should & will open URL.  Called from a third party application is different cause it will be using constructs found in the Windows Registry.

(I'm not in a position to set SeaMonkey 2.0a as my default browser to confirm whether AutoRuns/ProcessExplorer will work correctly, though based on my findings on a "mule", it appears not.)
Comment 11 User image Hammer 2008-01-31 15:28:20 PST
@ Rube:
The reasoning behind the ? queryterm construct is that it will allow Microsoft to jerk around non-IE browsers. We only have two choices:
1) Implement it OR
2) Watch people switch back to IE
Luckily this seems to be a fairly simple fix. However, I strongly believe this should be done even for the next 1.1.x security fix as it affects usability quite a bit.

Hammer :)
Comment 12 User image Frank Wein [:mcsmurf] 2008-03-08 15:18:13 PST
Comment on attachment 294981 [details] [diff] [review]
Proposed patch

r+ but only when we then enable keywords by default. Because then we can really integrate better on Windows Vista (and not only works for some users and for others not).
Comment 13 User image Robert Kaiser 2008-03-08 15:25:39 PST
Enabling keywords by default is IMHO a good idea anyways - hey, even Firefox does that!
Comment 14 User image 2008-03-08 15:44:29 PST
Fix checked in. New trunk 2.0a1pre builds should now support "? queryterm".

As I mentioned in comment 2, it would be rather harder to fix 1.1.x builds.
Comment 15 User image Frank Wein [:mcsmurf] 2008-03-08 16:34:53 PST
We should also update then (and move to some Wiki?).
Comment 16 User image Robert Kaiser 2008-03-08 16:39:00 PST
getting those end user docs somewhere else is in discussion elsewhere - I'd be so happy if someone would want to take on the task of working with Mozilla people to get something sumo-like up and running for us (and probably seeded with those docs).

Note You need to log in before you can comment on or make changes to this bug.