Open Bug 261965 Opened 20 years ago Updated 2 years ago

foo/bar in the location is not sent to the keyword provider

Categories

(Core :: DOM: Navigation, defect)

defect

Tracking

()

People

(Reporter: nicolas.barbulesco, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10

When I enter "apple" in the address bar, Firefox goes to "http://www.apple.com",
and the address in the address bar remains "apple". This behavior is correct.

But when I enter "apple/imac", Firefox goes to "http://www.apple.com", and the
address in the address bar remains "apple/imac". This behavior is incorrect:
Firefox should go to "http://www.apple.com/imac".

The same (incorrect) behavior occurs if entering "http://apple" instead of "apple".

I used "apple" as an example, but the same (incorrect) behavior occurs with any
word.

Reproducible: Always
Steps to Reproduce:
1. Type "apple/imac" in the address bar.
2. Press Return.
Actual Results:  
Firefox went to "http://www.apple.com".
The address in the address bar remained "apple/imac".

Expected Results:  
Firefox should go to "http://www.apple.com/imac".
The address in the address bar should remain "apple/imac", or become
"http://www.apple.com/imac". (I find both of these behaviors correct.)
> The same (incorrect) behavior occurs if entering "http://apple" instead of
"apple".

I meant:

The same (incorrect) behavior occurs if entering "http://apple/imac" instead of
"apple/imac".
http://blah ends up doing an I'm Feeling Lucky search, which is currently not
updating the address bar display properly.

*** This bug has been marked as a duplicate of 254040 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
(In reply to comment #2)
> http://blah ends up doing an I'm Feeling Lucky search, which is currently not
> updating the address bar display properly.
> *** This bug has been marked as a duplicate of 254040 ***

This bug is not a duplicate of 254040.

The behavior I talk about (going to "http://www.apple.com" instead 
of "http://www.apple.com/imac") is not covered by 254040.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
There is a bug here.  "apple/imac" does a Google I'm Feeling Lucky search for
just "apple".  It should either add www. and .com to get
"http://www.apple.com/imac/" or send the whole phrase to Google.
Question for Nicolas: If apple/buy is entered in the address bar, where would
you expect in to go? http://www.apple.com/buy/ or
http://www.macnn.com/news/26001 (google's I'm feeling lucky result)
(In reply to comment #5)
> Question for Nicolas: If apple/buy is entered in the address bar, where would
> you expect in to go? http://www.apple.com/buy/ or
> http://www.macnn.com/news/26001 (google's I'm feeling lucky result)

http://www.apple.com/buy
It is the way Mac browsers behave since always. So it is what the user expects.
The first behavior you mentioned is wrong, and that is bug 254040.

I _do_ see that entering apple/imac in google's i'm feeling lucky service give
different result from entering _the same string_ in the location bar.
Assignee: firefox → p_ch
Status: UNCONFIRMED → NEW
Component: General → Search
Ever confirmed: true
OS: MacOS X → All
QA Contact: firefox.general → bugs.mano
Hardware: Macintosh → All
Summary: Incorrect URL handling when omitting "www." and ".com" in the URL → / is removed from search string (google's i'm feeling lucky from location bar) when there is no space before or after it
*** Bug 291030 has been marked as a duplicate of this bug. ***
With current 1.8 branch builds, entering apple/imac in the location bar does not result in a keyword search, and I get the "host cannot be found" error. From what I can tell,
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/docshell/base/nsDefaultURIFixup.cpp&rev=1.47&mark=309#307
is true, so we end up in the "prepend http://" case and just fail. I'm not sure that this can really be fixed without breaking others. In any case, this isn't a Firefox bug.
Assignee: p_ch → nobody
Component: Search → Embedding: Docshell
Product: Firefox → Core
QA Contact: bugs.mano → docshell
Summary: / is removed from search string (google's i'm feeling lucky from location bar) when there is no space before or after it → foo/bar in the location is not sent to the keyword provider
Version: unspecified → Trunk
1)  Did this ever use to "work"?
2)  Gavin, is FIXUP_FLAGS_MAKE_ALTERNATE_URI set in this case?
(In reply to comment #10)
> 1)  Did this ever use to "work"?
> 2)  Gavin, is FIXUP_FLAGS_MAKE_ALTERNATE_URI set in this case?

I don't know if it ever worked. I can't really look into this further until Saturday, I will do so then.
Though the previous summary seems to indicate that everything after the slash was stripped off, with the result being sent to the keyword handler. Not sure if that is your definition of "work", but the new summary here seems to be what the original reporter was looking for.
Well...  If MAKE_ALTERNATE_URI is set, I would expect us to fix up "foo/bar" to "http://www.foo.com/bar" without ever doing any keyword stuff.  If we're doing keyword stuff, that is, imho, a bug.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.