User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090223 SeaMonkey/2.0a3 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090223 SeaMonkey/2.0a3 When I type 'cnn' in the location bar, and (1) "www." and ".com" are added and (2) unknown locations are searched for by the search engine, then I expect (1) to happen before (2), so that the web page www.cnn.com is displayed. Not so, a Search result page for 'cnn' is displayed. Reproducible: Always Steps to Reproduce: 1. in Preferences in Category Browser, Location Bar in the field Unknown Locations check 'add "www." and ".com" to the location if a web page is not found' and check 'Perform a web search when entered text is not a web location' 2. type 'cnn' in the location bar 3. hit return Actual Results: A search result page for 'cnn' is displayed Expected Results: The web page 'www.cnn.com' is displayed When either 'add "www." and ".com" to the location if a web page is not found' or 'Perform a web search when entered text is not a web location' is checked, the behaviour is alright. But when both are checked, the behaviour is strange. When both are checked, now, the checking of the Search box always overrides the checking of the www-com box. Instead it should depend on it. If 'www.cnn.com' does not exits, then Search for 'cnn'. If 'www.cnn.com' does exist, then, according to the checking of the www-com box, display it.
Neil, Frank, you have been working with location bar stuff, are we applying domain fixup and keyword search in a wrong order, is this bug invalid, or is there a bug somewhere in between those two extremes?
The code for this is all in docshell, so Firefox will have the same bug. The normal keyword code (in nsDefaultURIFixup.cpp) only triggers for strings either a) beginning with a "?" symbol or b) containing at least two words, the first of which cannot contain ".", ":" or "?" c) not guessable as a URI However when the load of http://cnn/ fails there is code in nsWebShell.cpp (nsDocShell.cpp on trunk) that forces keyword fixup before domain guessing, because the original Netscape keyword server included domain guessing. FYI the original keyword code was added 10 years ago (in bug 11869).
Thanks Neil for replying. Does the code in nsWebShell.cpp, that forces keyword fixup (I assume this results in a search result page) before domain guessing, ever execute the domain guessing part, since a search query always succeeds? I assume the intention of the makers is to let the domain guessing happen before the keyword search, otherwise the domain guessing will never happen, if both options are checked. Does this mean that the code in nsWebShell.cpp has been wrong all the time?
As I mentioned before, the code was designed for search keywords to override domain guessing, since the Netscape keyword server already did domain guessing. I can't tell whether this makes the code wrong or not. Note that you can't try both domain guessing and keywords on the same word, since both features destroy the original input word.
Firefox has a location bar and a search bar, typing 'cnn' in the location bar displays the web page www.cnn.com, typing 'cnn' in the search bar displays a search result page for 'cnn'. That works alright. However it has always been a strong feature of Seamonkey that you could use the location bar for web addresses and search queries. In Firefox one often finds oneself typing the entry in the wrong bar... Can the design of the code that was designed for search keywords to override domain guessing, be turned around, so that domain guessing comes first and if succeeds, displays the web page (like www.cnn.com)? If domain guessing and keywords can't be used on the same word since the original input word is destroyed, can the original input word then be saved in a variable or so? variable=originalinputword if www.variable.com exists then display www.variable.com else search variable and display search results
No, Firefox does keyword lookup too. Its keyword lookup for cnn is http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=cnn which redirects to www.cnn.com in any browser. SeaMonkey's keyword lookup for cnn is http://www.google.com/search?ie=UTF-8&oe=utf-8&q=cnn which is just a search page. Note: I don't know whether we're allowed to use Firefox's keyword lookup URL.
Ok. But if I change http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=cnn in for instance http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=google then I get a search page again, so it is not a way to trick the Search engine into domain guessing. Perhaps it also works only for Google. Is there anyone who can tell whether the expected unknown location behaviour of the location bar can be realized? Otherwise it is no use checking both 'add "www." and ".com" to the location if a web page is not found' as well as 'Perform a web search when entered text is not a web location', since adding www. and .com will never be done. Radio-buttons should be made then out of the checkboxes.
(In reply to comment #7) > Is there anyone who can tell whether the expected unknown location behaviour of > the location bar can be realized? > > Otherwise it is no use checking both 'add "www." and ".com" to the location if > a web page is not found' as well as 'Perform a web search when entered text is > not a web location', since adding www. and .com will never be done. Though surely the same is true in reverse, since if you add the www. and .com and that still fails then the web search won't be performed since by this point it won't know if you originally typed in the full domain name.
(In reply to comment #5) > variable=originalinputword > if www.variable.com exists then display www.variable.com > else search variable and display search results I overlooked this part of your question, but from the SeaMonkey point of view, we just tell the internal browser to open "cnn" and it then decides (based on preferences) whether to do keyword search or domain guessing (but not both).
OK, that means if we want (already for many years) the internal browser to behave for unknown locations in the expected way , we should redirect our quest for changing the code to another department, to the people who make the code for the internal browser. To which department should we redirect our question then? To the department/component "General" or "Preferences"? I am missing a department/component "internal browser".
Well, I guess we could start with the component where the feature is actually implemented, which in this case is Core:Document Navigation.
Thanks Neil. I rephrased the summary. Should I pose the question again or will people take up the matter here automatically?
Created attachment 440464 [details] [diff] [review] Possible patch This makes it so that domain guessing (for supported words) takes priority over keyword search when they are both enabled. Since keyword search used to supersede domain guessing, also requesting review to turn domain guessing "back" off for Firefox, in case they don't want it to start domain guessing.
Comment on attachment 440464 [details] [diff] [review] Possible patch r=bzbarsky
I think this would impact Firefox's behavior when loading things from drags (where we currently don't allow keyword search) - domain guessing would be disabled so we'd just fail to load most single words as "invalid hosts". We probably want to revise the decision to not allow keyword search in that case, so that might not matter, though.
Comment on attachment 440464 [details] [diff] [review] Possible patch I don't think we can take this until comment 15 is addressed somehow.
Well, we could always leave domain guessing on, if you'd be happy with it taking precedence over keyword search...
I don't think that we would want that behavior change either.
> We probably want to revise the decision to not allow keyword search in that case Drag&drop often happens unintentionally. Feeding the word or sentence to a search engine is an information leak. Sure, DNS currently also sees it, but DNS is less logged and analyzed than search engines. That's probably why it currently is the way you described.