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

RESOLVED INVALID

Status

SeaMonkey
Location Bar
--
minor
RESOLVED INVALID
16 years ago
7 years ago

People

(Reporter: Kelley Cook, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

Comment 1

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

Comment 3

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

15 years ago
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?
To repeat, "The URLbar dropdown should filter these duplicates, though."

Comment 7

15 years ago
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.
Severity: normal → minor
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Summary: History URL with different name items (#) shouldn't be stored → URL bar dropdown shouldn't show same page with different name items (#)
and the component of the day is... ;)
Assignee: blaker → hewitt
Component: History: Global → URL Bar
(Assignee)

Updated

10 years ago
Product: Core → SeaMonkey
Assignee: hewitt → nobody
QA Contact: claudius → location-bar

Comment 9

9 years ago
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
Status: NEW → UNCONFIRMED

Comment 10

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

7 years ago
agree to comment 10
Whiteboard: [CLOSEME INVA/WONT?]

Updated

7 years ago
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → INVALID

Updated

7 years ago
Whiteboard: [CLOSEME INVA/WONT?]
You need to log in before you can comment on or make changes to this bug.