148183 - URL bar dropdown shouldn't show same page with different name items (#)

Status: RESOLVED INVALID

(SeaMonkey :: Location Bar, defect)

Description

[Kelley Cook]

The history file stores a seperate entry for all URLs that have # (ie referring
to specifc name tag) in them.

For example for today I have:

http://gcc.gnu.org/ml/gcc-patches/2002-05/threads.html#02439
http://gcc.gnu.org/ml/gcc-patches/2002-05/threads.html#02426
http://gcc.gnu.org/ml/gcc-patches/2002-05/threads.html#02409
http://gcc.gnu.org/ml/gcc-patches/2002-05/threads.html#02408
http://gcc.gnu.org/ml/gcc-patches/2002-05/threads.html#02395
http://gcc.gnu.org/ml/gcc-patches/2002-05/threads.html#02387
http://gcc.gnu.org/ml/gcc-patches/2002-05/threads.html#02373
http://gcc.gnu.org/ml/gcc-patches/2002-05/threads.html#02367

which of course all refer to the same page

This causes a few problems.

A) The link color of any hypertext refering to that page with a name tag only
gets changed if the URL exactly matches one with the same name tag.

B) Location Bar gets very cluttered with all of the # versions which slows it
down significantly and makes the automatic quicktype selection much less useful.

C) It would cut down on the history.dat size, thus speeding it up also.

The solution is two only store up to the # in the history file and only lookup
matches to the Read (Purple) link color up to the # sign of URL referenced in
the page being displayed.

This is the behavior of MS Interent Explorer, FWIW.

Comment 1

[Kelley Cook]

To see an example:

Go to http://gcc.gnu.org/ml/gcc-patches/2002-04/threads.html

Click on an entry.
Click on Thread Index (which will incorrectly be blue)
Click on a different entry
Click on Thread Index (which will incorrectly be blue)
Click on a different entry
Click on Thread Index (which will incorrectly be blue)

View your History.

Comment 2

[Boris Zbarsky [:bzbarsky]]

(A) is actually desired behavior.  It makes page navigation much clearer.  The 
IE behavior there is very confusing.

The URLbar dropdown should filter these duplicates, though.

Comment 3

[Kelley Cook]

I forgot to mention the fact that since they are "different" URLs, it won't 
pull the (same) page from the cache, which matters over slow connections.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Sure it'll pull the same page.  The #ref is ignored when generating the cache 
key.  See 
http://lxr.mozilla.org/seamonkey/source/netwerk/protocol/http/src/nsHttpChannel.
cpp#919

Let's not confuse history and cache.  ;)

Comment 5

[Michael Lefevre]

if I understand Boris' comments, mozilla is doing what is desired here, and so
this isn't a bug, and therefore should be INVALID? is that right?

Comment 6

[Boris Zbarsky [:bzbarsky]]

To repeat, "The URLbar dropdown should filter these duplicates, though."

Comment 7

[Michael Lefevre]

ah... ok. thanks.

well I can't see any other bug for making the URL bar filter the duplicates, so
I'll update and confirm this one for that.

Comment 8

[Boris Zbarsky [:bzbarsky]]

and the component of the day is... ;)

Comment 9

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 10

[Kelley Cook]

Though the URLBar issue is technically still there, the changes over the years from simply alphabetical sorted to the popularity sorted URLbar to the now much smarter places bar has made this issue completely irrelevant for me.  

I had forgotten about it.

As the original opener, I'd advocate closing it as INVALID

Comment 11

[Otto Koehn]

agree to comment 10