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

RESOLVED FIXED in mozilla1.0

Status

P3
enhancement
RESOLVED FIXED
19 years ago
10 years ago

People

(Reporter: gabriel, Assigned: bugzilla)

Tracking

({verifyme})

Trunk
mozilla1.0
verifyme

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

19 years ago
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

19 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

19 years ago
is this a dupe?
url bar is xpapps
Assignee: asa → don
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
should return simply Go, or really do Search? over to claudius...
QA Contact: sairuh → claudius
(Assignee)

Comment 5

19 years ago
taking...

brade's right, we have to watch out for javascript: urls.
Assignee: don → blakeross
(Reporter)

Comment 6

19 years ago
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.
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
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?
(Assignee)

Comment 8

19 years ago
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?
(Assignee)

Comment 9

19 years ago
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.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME

Comment 10

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

Comment 11

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

Comment 12

17 years ago
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 13

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

Comment 14

17 years ago
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
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago17 years ago
Resolution: --- → WORKSFORME

Comment 15

17 years ago
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

17 years ago
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.
Status: RESOLVED → VERIFIED

Comment 17

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

Updated

17 years ago
Blocks: 76547

Comment 18

17 years ago
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

17 years ago
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

16 years ago
With Internet Keywords disabled, this bug is still present.  Reopening.
Blocks: 53171
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---

Comment 21

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

Comment 22

16 years ago
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

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

Comment 24

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

Comment 25

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

Comment 26

16 years ago
Created attachment 132187 [details] [diff] [review]
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

16 years ago
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.
Attachment #132187 - Flags: review-

Comment 28

16 years ago
Created attachment 132408 [details] [diff] [review]
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.
Attachment #132187 - Attachment is obsolete: true

Comment 29

16 years ago
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.
Attachment #132408 - Flags: review-

Comment 30

16 years ago
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

16 years ago
(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

15 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 17 years ago15 years ago
Component: XP Apps → Location Bar
Keywords: verifyme
Resolution: --- → FIXED
Summary: If URL bar contains spaces, pressing return should search → Internet Keywords: spaces should not block keyword (search) request

Updated

15 years ago
No longer blocks: 53171

Comment 33

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

Comment 34

15 years ago
*** Bug 224153 has been marked as a duplicate of this bug. ***
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.