298697 - search (keyword) bookmarks should return root URL on blank query instead of hard-coded %s

Status: RESOLVED WONTFIX

(Firefox :: Bookmarks & History, enhancement)

Description

[Chris Petersen]

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

Comment 1

[J.P.Klippel]

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?)

Comment 2

[Chris Petersen]

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.

Comment 3

[:Gavin Sharp [email: [e-mail]]]

(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.

Comment 4

[Chris Petersen]

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.

Comment 5

[J.P.Klippel]

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. 
 

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Attachment: 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.

Comment 7

[Mikel Ward]

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 8

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 202905 [details] [diff] [review]
patch

This no longer applies, given the changes in bug 317107.

Comment 9

[Phil Ringnalda (:philor)]

*** Bug 224297 has been marked as a duplicate of this bug. ***

Comment 10

[Chris Casciano]

this seems like an odd and difficult to implement solution.. Not to mention the proposed solution would fail quote often, in my experience. Cases like the following are not considered in this proposal

- Bookmarklets
- Any other usages where the %s is not the last item in the string [or otherwise used to represent a query string value] 
- The many, many cases where the content at the root of domain is not related to the content at the full URL -- take google for example where everything from searches to their directory to adsense and analytics is run off the "www" subdomain



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


why would the following two be equivalent:
http://www.example.com/%s
http://www.example.com/webadmin/edit/%s

What would the fallback be for this bookmark?
javascript:window.resizeTo(%s,600);

It seems to me that the solution proposed in Bug 253457 is much more appropriate

Comment 11

[Milian Wolff]

Why not just replace %s with "nothing", i.e. an empty string? For normal URLs that would (imo) the correct and natural design!

The URLs from Chris' comment would all be good. In javascript bookmarklets (easy to match, via /^\s+javascript:/ or something) one would have to replace %s with '' or ""...

Comment 12

[Chris Wood]

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?

Comment 13

[:Felipe Gomes (needinfo for replies!)]

This seems to be WFM!

Comment 14

[Reuben Morais [:reuben]]

(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= )

Comment 15

[Phil Ringnalda (:philor)]

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=

Comment 16

[:Gavin Sharp [email: [e-mail]]]

Attachment: this should do it

untested

Comment 17

[:Felipe Gomes (needinfo for replies!)]

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.

Comment 18

[:Gavin Sharp [email: [e-mail]]]

(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).

Comment 19

[:Gavin Sharp [email: [e-mail]]]

Attachment: Mikel's suggestion

This might upset some people who rely on the current behavior, I guess.

Comment 20

[:Gavin Sharp [email: [e-mail]]]

And it looks like Milian's suggestion is actually our current behavior (we don't send "%s").

Comment 21

[:Gavin Sharp [email: [e-mail]]]

I'm going to say WONTFIX, I've already spent too many cycles on this :)