54392 - Autocomplete should try ignoring trailing '/' after hostname

Status: RESOLVED FIXED

(Core Graveyard :: History: Global, defect, P2)

Description

[Karl Stephenson-Möller]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16 i586; en-US; m18) Gecko/20000927
BuildID:    2000092708

If both www.mozilla.org and www.mozilla.org/ (with an ending slash) are in the
history, both will be shown in the autocompletion menu.

Reproducible: Always
Steps to Reproduce:
1. Type in a domain name in the location bar, eg www.mozilla.org.
2. Type the same domain name preceding a /, eg www.mozilla.org/.
3. Type the first letters of the name, eg www.moz.

Actual Results:  Both www.mozilla.org and www.mozilla.org/ is suggested as
complete adresses.

Expected Results: A new address should not be added to the autocompletion
history if the same address is already in the history, even if it has one slash
more or less.

Comment 1

[WD]

This one is kinda along the lines of bug 53831
Symptoms are the same....   just a different way of getting it
The bottom line is, Mozilla needs to be a little smarter about what it includes
as an autocomplete possibility.

Comment 2

[Radha on family leave (not reading bugmail)]

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

Comment 3

[Radha on family leave (not reading bugmail)]

Attachment: Patch to JS file

Comment 4

[Jean-Francois Ducarroz]

Radha, can you put the following lines outside the while loop:

+             var uriToAdd =
Components.classes["@mozilla.org/network/standard-url;1"]
+                            .createInstance(Components.interfaces.nsIURI);

+             uriToAdd.spec = urlToAdd;
+             var rdfUri = Components.classes["@mozilla.org/network/standard-url;1"]
+                          .createInstance(Components.interfaces.nsIURI);

Don't need to do that for each element!

Comment 5

[Radha on family leave (not reading bugmail)]

Attachment: Another patch to sessionHistoryUI.js

Comment 6

[Radha on family leave (not reading bugmail)]

Nice catch! The latest patch does that.

Comment 7

[Alec Flett]

looks good, sr=alecf

Comment 8

[Viswanath Ramachandran]

nav triage: accepting for nsbeat1 as a p2. 

Comment 9

[Radha on family leave (not reading bugmail)]

This got fixed a while ago.

Comment 10

[R.K.Aa.]

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

Comment 11

[R.K.Aa.]

According to reporter in dup bug 66773, this bug is still alive. (2001-012006)
Reopening.

Comment 12

[Alec Flett]

this is a URL Bar bug, reassigning appropriately

Comment 13

[Jesse Ruderman]

This bug also shows up on Windows.

Comment 14

[Matthew Wilson]

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

Comment 15

[Boris Zbarsky [:bzbarsky]]

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

Comment 16

[Boris Zbarsky [:bzbarsky]]

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

Comment 17

[Paul Chen]

Ok, marking nsbeta1+, setting target milestone mozilla0.9

Comment 18

[Alec Flett]

ok, this bug is fixed, but if you have old entries in your history, they will
probably stick around. try it with a fresh profile

The one odd situation that this isn't fixed for is:
http://www.foo.com/
http://www.foo.com/#

these are treated as different urls, and this can be fixed by fixing nsIURL::Equals

but since users generally don't type empty anchor tags, I don't think this
warrants an nsbeta1+, so I'm moving back to nsbeta1

Comment 19

[Paul Chen]

nav triage team:

Not a beta1 stopper as it currently stands, marking nsbeta1-

Comment 20

[Alec Flett]

reassign url bar bugs to new owner..

Comment 21

[Blake Ross]

Joe was dying to have these bugs. Who am I to say no?

Comment 22

[Joe Hewitt (gone)]

Over to history, because these similar urls shouldn't even be stored.

Comment 23

[Blake Ross]

As Alec noted, this is fixed...