User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.0.4-1.3.1 Firefox/1.0.4 For lack of dealing with two bookmark addresses like galeon does (my preferred method of dealing with this), I suggest that smart bookmarks should behave like the search engines do when no keyword is entered. Thus, for a bookmark like: "google" -> http://www.google.com/search?q=%s when the user types "google" instead of "google for-something", they would end up at http://www.google.com/ instead of http://www.google.com/search?q=%s (with an actual %s). This won't fit 100% of the time (eg. someone would rather default to http://www.google.com/ig/), but it would at least catch a good 95% of cases. Reproducible: Always Steps to Reproduce: see description
in response to your usage example: I don't think it should redirect you to http://www.google.com/ . I think it can be real hard to figure out the right url here. Instead it would be ok for me if the %s would be replaced by nothing. In this case you would be redirected to http://www.google.com/search?q= (which has a resulting page similiar to http://www.google.com). I think a variable or a placeholder should always be replaced when it gets interpreted. (btw. is there a way to quote that %s so that it explicetly does not get replaced while query execution?)
setting it to blank defeats the whole purpose. a search for nothing would be "google " -- compared to "google" which is *not* searching. Google may be a bad example in this case, though.. Maybe something like wikipedia would be a better example. I don't want to see a blank results-page if I don't type anything in. I want to see the homepage associated with the search URL. I suggested just going to the root URL because that's how the search engine box works, and I figured that bookmarks should at *least* work how it does. But seriously, having two URL's (even if it was an advanced option to enable in about:config) is the best option, esp. with sites like ebay, where the search URL is on a completely different server.
(In reply to comment #1) > in response to your usage example: > I don't think it should redirect you to http://www.google.com/ . I think it can > be real hard to figure out the right url here. The search bar already just takes the host portion of the URL when you do a blank search. That solution is good enough to catch 90% of the use cases.
That was my point.. For lack of a dual-URL option, my suggestion is to make the normal location box act like the searcn engine box. For consistency in user interface, if nothing else.
I think we all agree, that there has to be a better solution than transmitting a placeholder "%s" to the server. Right now I am in favour of the "search bar solution" as well (you somewhat convinced me). But 90% is a good start but not good enough. If the search bar solution gets implemented I would prefer an option in about:config to disable it for the location bar, as there might be another usecase (not typing a search request) in which an empty query is needed and valid. In that case - using the "search bar solution" - one could not use the keyword option for a shortcut in the location bar but would have to either type the complete url or create another bookmark for an empty request. As this is clearly an example for the other 10% it should be ok for them to use about:config to disable the "search bar solution" feature.
Created attachment 202905 [details] [diff] [review] patch I ended up changing getShortcutOrURI quite a bit, to use early returns as opposed to multiple levels of indentation. I'm not sure I like the change in behavior, to be honest, I think it might be better to just strip out the %s and load that URL, which in most cases would be the equivalent of a blank query. I still need to play with this some more, but I'm dumping what I have in case anyone wants to comment.
I just experienced this because of a search bookmark for Bugzilla. Typing only "bugzilla" took me to a page which had "zarro boogs". :-) I like all the ideas proposed so far, however I prefer another option: If there is no query string, act as if the search bookmark does not exist. In this case, typing "bugzilla" would look for a host called bugzilla or perform a search according to the keyword.URL preference. This should also be easier to implement as it wouldn't require any user interface changes.
Comment on attachment 202905 [details] [diff] [review] patch This no longer applies, given the changes in bug 317107.
*** Bug 224297 has been marked as a duplicate of this bug. ***
Shouldn't this bug depend on bug 253457 and bug 306221, since it's either this bug or those two, but not both, that get fixed?
This seems to be WFM!
(In reply to :Felipe Gomes from comment #13) > This seems to be WFM! If I go to https://developer.mozilla.org/, add a keyword for the search (say, "mdn") and then type "mdn" and hit enter, I still see the bug (I get https://developer.mozilla.org/en-US/search?q= )
Yeah, more like DOESNTWORKFORME. STR: 1. Right click the search box at the top of this page, Add a Keyword for this Search 2. Put bmo in the keyword field and save the bookmark 3. Type bmo in the addressbar and hit enter Expected: https://bugzilla.mozilla.org/ Actual: https://bugzilla.mozilla.org/buglist.cgi bitching about the empty search after a redirect from https://bugzilla.mozilla.org/buglist.cgi?quicksearch=
Ok, so to clarify, this works for the built-in search engines as they have the blank URL functionality (same as if you go to an empty search bar and press enter). But it does not work to custom-added search keywords. But it's worth considering comment 10 here to ponder if this really should be fixed or not.
(In reply to Chris Casciano from comment #10) > Why would the following three bookmarks ultimately go to the same place? > https://www.google.com/adsense/report/%s > http://www.google.com/Top/%s > http://www.google.com/search?q=%s Because that's better than them going to more-specific searches for "%s" (our current behavior), arguably. We're very much in edge case territory here; we don't really expose bookmark keywords to begin with (particularly not those that take parameters). Given that, I'm really inclined to just leave things as-is and WONTFIX this, but since the proposed behavior is relatively simple to implement (see patch), I figured it might not hurt to just make that tweak. Mikel (comment 7) or Milian's (comment 11) other suggestions would be fine too, IMO (they are also easy to implement).
Created attachment 727101 [details] [diff] [review] Mikel's suggestion This might upset some people who rely on the current behavior, I guess.
And it looks like Milian's suggestion is actually our current behavior (we don't send "%s").
I'm going to say WONTFIX, I've already spent too many cycles on this :)