58867 - Internet Keywords: spaces should not block keyword (search) request

Status: RESOLVED FIXED

(SeaMonkey :: Location Bar, enhancement, P3)

Description

[gabriel]

I think it's great that Mozilla has a configurable search, but often I enter
some search terms in the URL bar and press return without thinking instead of
clicking on the Search button.

Of course, Mozilla then spins for a while and then comes back with 'could not
find website', etc.

I think it would be even better if Mozilla were smart enough to determine that
spaces in a URL indicated search terms, and acted as if the search button had
been clicked when I pressed enter.

Comment 1

[Kathleen :Brade]

Since a space isn't a valid character in a url (unless it's escaped), I agree
with this.  Confirming.

If we needed to be more clever (for some reason we want users to be able to put
spaces in a url), we could check for a space and no ':' character.  That'd
probably be better since you could have a javascript: url with spaces in the alert.

Comment 2

[timeless]

is this a dupe?

Comment 3

[Doron Rosenberg (IBM)]

url bar is xpapps

Comment 4

[sairuh (rarely reading bugmail)]

should return simply Go, or really do Search? over to claudius...

Comment 5

[Blake Ross]

taking...

brade's right, we have to watch out for javascript: urls.

Comment 6

[gabriel]

I'd say really do a search, cause to have spaces in, the user must've typed it
in, so search is prolly what they intended.

Comment 7

[Matthew T (active 1999-2002)]

Leading or trailing spaces (or quote marks, or brackets of any sort not allowed 
in URLs>]}) should be ignored, as they are likely to be present as a result of an 
address being copied or pasted, or as a result of a user who is unfamiliar with 
URL syntax blindly typing in what they see in the newspaper. Blake, do you want a 
separate bug for any of that?

Comment 8

[Blake Ross]

Good news:  this works fine if you have Internet Keywords enabled (and 
javascript: urls with spaces work fine too, since we test for those first), so 
very little work will be required here.  Actually, in the brief prefs 
description about internet keywords, it does say they offer search capability.  
But I still don't think it's clear that space-delimited phrases only get 
searched with internet keywords on.  Matthew, how do you suggest we resolve 
this bug?

Comment 9

[Blake Ross]

marking this wfm, since the original issue is fine if you have internet 
keywords on.  But I do think we need some UI help here.  If you agree, please 
file a new bug and cc me.

Comment 10

[R.K.Aa.]

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

Comment 11

[R.K.Aa.]

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

Comment 12

[Gili Tzabari]

This bug isn't closed because if you use Google as your search engine and you
enable Internet Keywords, it'll still use Netscape's search engine; which is
incorrect.

Comment 13

[John Levon]

Erm, no it won't. I do this daily. You must have misconfigured it
somehow.

Comment 14

[timeless]

using netscape is using a search engine, the fact that you misconfigured your 
internet keyword server doesn't negate the fact that you triggered one.

the bug as filed works for you. for help configuring internet keywords, contact 
a vendor or visit irc.mozilla.org #mozillazine

Comment 15

[Gili Tzabari]

According to http://www.mozilla.org/docs/end-user/internet-keywords.html, I need
to manually edit prefs.js to change my internet-keywords server.

Look, this is plain silly. I don't care about internet keywords; what I care
about is being able to enter search items in the URL bar, press ENTER, and have
it search using Google. I don't see why any user should have to manually edit
prefs.js to make this happen.

If you can't make internet-keywords use the server configured under "Internet
Search" (in preferences) then you guys should add a new feature that works
without it. The goal is being able to enter search terms directly on the URL bar
and pressing ENTER to search; that's it.

Comment 16

[timeless]

vrfy wfm [per blake, and per the reporter's comments]

a UI to select a keyword server is another bug, which i'd hope is filed.

Comment 17

[Jesse Ruderman]

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

Comment 18

[Jeremy M. Dolan]

Yes, there are other bugs to do something about the stupid inconsistencies and
confusion between search and keywords. Just don't hold your breath.

Comment 19

[benc]

This bug is only WFM because the default IK server is a search engine.

In some ways, that isn't the same thing.

Comment 20

[Jesse Ruderman]

With Internet Keywords disabled, this bug is still present.  Reopening.

Comment 21

[R.K.Aa.]

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

Comment 22

[Jason Bassford]

Also, even *with* "Enable Internet Keywords" checked it still doesn't work.

E.g. with or without keywords, if I type "Give me a recipe for apple pie." into
the URL I get a "The URL is not valid and cannot be loaded." error page.

The reason for the above is the trailing "." character.   If I leave it out,
it's fine.  But if there's a space in what's entered, it should assume it's
going to a search engine, and automatically disable all other parsing code and
simply ignore any punctuation or characters used.

Comment 23

[Alfonso Martinez]

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

Comment 24

[Alfonso Martinez]

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

Comment 25

[Gilles Durys]

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

Comment 26

[Massimo Dal Zotto]

Attachment: fixes this really annoying problem

My patch seems to solve the problem. If the url contains a space and doesn't
contain a '://' the OpenSearch() function is called instead of
BrowserLoadURL().

Note thet if you are searching a single word you need to append a space before
hitting Enter.

Note also that my patch is for the navigator.js file included in comm.jar
distributed with mozilla 1.4. It should be applied to the original sources
instead but I don't have time/will to do it.

Comment 27

[timeless]

Comment on attachment 132187 [details] [diff] [review]
fixes this really annoying problem

>+  // If url contains spaces and no '://' handle it as search -- dz
comment not needed. the checkin comment and blame to the bug is enough

>+  if (url.match(/ /) && !url.match(/:\/\//)) {
>+    OpenSearch('internet', false, QualifySearchTerm());

I frequently copy server names which happen to have space prefixed to them,
e.g.: " lxr.mozilla.org" this is not a search. I shouldn't have to meticulously
remove spaces from the beginning of the location field just to get mozilla to
contact the server.

I wouldn't cry if someone fixed both the problem I described above in addition
to fixing bookmark keywords so that " bug 58867" would match my bookmark
keyword "bug" <url:http://bugzilla.mozilla.org/show_bug.cgi?id=%s>

Comment posted based on n7.1 (m1.4) behavior. It's possible (however unlikely)
that mozilla has changed since then.

I'd probably suggest this: (!/:\/\//.test(url) && /\w+\W+\w/.test(url)) if I
were asked to provide something based on the current patch. However I don't
think I like that. Consider: "mailto:foo bar <foo.bar@black>". protocol
handlers should get first dibs. guessing should happen last.

Comment 28

[Massimo Dal Zotto]

Attachment: revised patch

> (From comment #27)
> >+  // If url contains spaces and no '://' handle it as search -- dz
> comment not needed. the checkin comment and blame to the bug is enough

The comment was intended for readers of the sources, not readers of the patch.
Anyway I have removed it.

> I frequently copy server names which happen to have space prefixed to them,
> e.g.: " lxr.mozilla.org" this is not a search. I shouldn't have to
meticulously
> remove spaces from the beginning of the location field just to get mozilla to

> contact the server.

We can automatically strip leading blanks but not both leading and trailing
spaces because we want an easy way of forcing a search.

> I wouldn't cry if someone fixed both the problem I described above in
addition
> to fixing bookmark keywords so that " bug 58867" would match my bookmark
> keyword "bug" <url:http://bugzilla.mozilla.org/show_bug.cgi?id=%s>
> 
> Comment posted based on n7.1 (m1.4) behavior. It's possible (however
unlikely)
> that mozilla has changed since then.

I don't understand this. Could you please explain better or point to some
existing document.

> I'd probably suggest this: (!/:\/\//.test(url) && /\w+\W+\w/.test(url)) if I
> were asked to provide something based on the current patch. However I don't
> think I like that. Consider: "mailto:foo bar <foo.bar@black>". protocol
> handlers should get first dibs. guessing should happen last.

I don't understand the second part of your test, anyway I changed my test to

  (url.match(/^\"/) || (url.match(/ /) && !url.match(/^[a-z]+:/i)))

so that any text beginning with doublequote or containing non-leading spaces
but not starting with a protocol specifier pattern is handled as search.
Any input starting with protocol-like text is now handled as url unless you
enclose it in doublequote. Maybe we could check only valid protocols.

In my opionion fixing this problem will always make some user unhappy with
the new behavior. What I propose is a simple patch which can satisfy most
users under the most common situations. I think that my solution is far more
better than a "site not found" message. Another possibility is enabling this
feature with an user preference option.

A problem with my patch is also that it takes precedence over the "Internet
Keywords" feature, but in my opinion the problem is the way I.K. is handled
by the browser. I would prefer that the browser would always search using my
preferred search engine and that I.K. would be just another search engine
selectable in the preferences dialog. With my patch we have also the odd
behavior that hitting Enter or pressing the Search button invokes the
preferred search engine while pasting a search text in the window invokes
always the Internet Keywords search.

Comment 29

[Christian Reis]

Comment on attachment 132408 [details] [diff] [review]
revised patch

Let me clarify the problem here: this check is performed too early. Any
protocol handlers registered should have a chance to look at gURLbar.value
beforehand and decide if they want to eat up the string -- only then should we
be considering doing a keyword search.

Comment 30

[Christian Reis]

The code also needs to be written for CVS HEAD, by the way.

Don't let us discourage you, though -- when the first attempts fail, *try again* :-)

Comment 31

[Massimo Dal Zotto]

(From comment #29)
> Let me clarify the problem here: this check is performed too early. Any
> protocol handlers registered should have a chance to look at gURLbar.value
> beforehand and decide if they want to eat up the string -- only then should we
> be considering doing a keyword search.

I know but I haven't found a better place where do it. The search is not
done if the url begins with a protocol: pattern so that protocol handlers
could still be called as before.

Is there any protocol handler which is not invoked by a protocol: prefix?
The only I can think of is the file:///path which can also be invoked by
a /path, but this can be taken in account in the test:

  (url.match(/^\"/) || (url.match(/ /) && !url.match(/^([a-z]+:|\/)/i)))

If we find any other case we can add add more ad-hoc patterns.

Is there a single place where all protocols handler hare checked and we
could add a search default action?


(From comment #30)
> The code also needs to be written for CVS HEAD, by the way.
> 
> Don't let us discourage you, though -- when the first attempts fail, *try
again* :-)

I don't want to spend time on cvs until we reach some consensus on the code.

Comment 32

[benc]

RESOLVED:fixed.
The spaces problem was fixed some time ago, (see comments in bug 58141).

As for the patch, please create a fix that follows the current design structure.
IK != Search, but the URL is configurable, if you want IK == search.

Adding yet-another behavior to URL bar will not make the code any better. There
are currently several bugs where your concerns about URL scheme recognition are
being fixed.

I've also moved several dupes into Bug 197918, because they actually pertain to
the fact that IK is off in Mozilla-only (not Firefox), so people are saying it
doesn't work correctly, when it isn't even on.

Comment 33

[R.K.Aa.]

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

Comment 34

[R.K.Aa.]

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