85165 - Sequentially repeated URL does not register in history

Status: NEW

(Core :: DOM: Navigation, defect, P3)

Description

[Aaron Kaluszka]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.1+)
Gecko/20010610
BuildID:    2001061020

If a page that has a link to itself is loaded, the multiple loads are not registered

Reproducible: Always
Steps to Reproduce:
1. Load a page
2. Load another page that has a link to itself
3. Hit Back

Actual Results:  You will be taken to the first page

Expected Results:  You should be taken to the same page that you are on

Comment 1

[Claudius Gayle]

I've confirmed this with a Mac 0.9.1 build. Confirming and changing OS/Platform
to all/all as this is an XP bug.- i guess it's a bug but I'd like to know under
what circumstance/situation it would be helpful. ps the mozilla.org banner is a
link back to mozilla.org

Comment 2

[Aaron Kaluszka]

Say you are on a page that generates content dynamically: ie. Bugzilla.
Now say you click on a link that effectively refreshes the page.
Now if you want to go back to view the differences between iterations, you can't.
Of course, this may not be a valid example, because of the way caching works,
but its all I could think of right now.

Another oddity:
Go to mozilla.org.
Click on a link.
Click Back
Now click the mozilla.org banner.
Notice Forward is still a valid option which takes you to the link you had
previously clicked.

Comment 3

[Radha on family leave (not reading bugmail)]

Not adding the same page to the history is a feature, just like the same page is
not added to global history over and over, no matter how many times you visit
it. each page in history takes up considerable space in memory and is not worth
storing. If a page generates dynamic content, that is the whole idea, (to be
different everytime you visit). If you are talking about a form-post that
submits to itself, there is already a bug for it assigned to (I think) Eric
Pollmann. Otherwise, I don't understand how this will be a useful.

Comment 4

[Aaron Kaluszka]

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

Comment 5

[Aaron Kaluszka]

REOPENing based on DUPLICATE bug 94737 comments

Comment 6

[Brendan Eich [:brendan]]

This bug is more general than described.  Try going to lxr.mozilla.org/mozilla
and typing addRequest into the Identifier search textbox.  Then revise your
search to look for AddRequest.  Go forward to some other page (perhaps by
clicking on one of the links returned by lxr).  Then go back, and you'll see the
first (http://lxr.mozilla.org/mozilla/ident?i=addRequest) results page, not the
second (http://lxr.mozilla.org/mozilla/ident?i=AddRequest).

This bug should be easy to fix, no?  It should not be targeted after mozilla1.0,
I think.

/be

Comment 7

[Brendan Eich [:brendan]]

I may be describing a separate bug, where this bug is complaining about the
duplicate suppression.  I'm complaining that the duplicate suppression wrongly
uses strcasecmp, at a guess.  Please file new bug if necessary, or tell me to do
it.  Thanks.

/be

Comment 8

[Radha on family leave (not reading bugmail)]

Brendan, for the problem you have described:

Docshell uses nsIURI::Equals()  to determine if 2 urls are the same.
nsIURI::Equals() uses strcasecmp for the same. I will file a bug against necko
for the problem. 

Comment 9

[Nathanael C. Nerode]

This bug causes the trouble in bug #136633 because currently view-source uses a
history-entry as its 'web page descriptor'.  View-source should probably use
something better, but there is nothing better.

Comment 10

[Radha on family leave (not reading bugmail)]

Moving out, since the bugs that this one depends on is targeted farther than
mozilla 1.0.1 

Comment 11

[Radha on family leave (not reading bugmail)]

Re-summarising ...

Comment 12

[Aaron Kaluszka]

Umm the new summary is incorrect.. maybe we need another bug for that specific
problem?

Comment 13

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 14

[Jesse Ruderman]

The case problem is bug 99091.

Comment 15

[Andrei Purice]

Hey Aaron,
Can you still reproduce this issue or can we close it?

Comment 16

[Andrew McCreight [:mccr8]]

I can reproduce the behavior described in comment 0. From this page, click on the link to the front page of bugzilla. Then click on the link to the front page of bugzilla. Hitting back takes you to this bug and not the front page. Maybe the current behavior is desired?

Comment 17

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.