nonexistant pages added to history and displayed in URL bar

VERIFIED DUPLICATE of bug 14695

Status

()

Core
Document Navigation
P3
normal
VERIFIED DUPLICATE of bug 14695
18 years ago
9 years ago

People

(Reporter: dbaron, Assigned: Radha on family leave (not reading bugmail))

Tracking

Trunk
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

18 years ago
DESCRIPTION:  URLs that do not work are:
  * shown in the URL bar
  * added to the back/forward history
  * added to the history used to color visited links

The basic problem, I think, is that URLs are being added to the history too
early.  A URL should be added to the history (both types) and to the URL bar the
instant some content for the page starts to display on the screen and replace
the content being shown before it.

STEPS TO REPRODUCE:
 1) load http://www.people.fas.harvard.edu/~dbaron/css/test/pseudos2
 2) click on one of the "link" links ... you'll get an error message
 3) hit reload
 4) hit back
 5) hit reload

ACTUAL RESULTS:
 * after 2), the URL of the page shows in the URL bar even before the error
message appears.  The URL bar should (IMO) show the URL of the page currently
being shown in the browser.  The incorrect URL continues to show in the URL bar
after the error message
 * after 3), the error message is shown again, even though the page currently
displayed (and the one that should be being reloaded) is the original URL loaded
in (1)
 * after 5), the links to the page that did not exist (and was never visited)
turn to the visited color

EXPECTED RESULTS:
 * after 2, the incorrect URL never shows in the URL bar (or, if it does, is
removed from the URL bar after the error message)
 * after 3, the original page is reloaded, and the links to the bad page are not
marked as visited

DOES NOT WORK CORRECTLY ON:
 * Linux, mozilla, 2000-02-24-15-M14

Comment 1

18 years ago
Attempting to reproduce this with 2000-03-05-16-M15 on WinNT found a new
crasher: bug 30682, "Reproducible crash in nsTextFormatter".

Other than that, this bug will surely be related to either bug 14695,
"nonexistant sites should not be added to session history SH", ASSIGNED, M20,
(and the related bug 11325) or bug 29604, "too much is ending up in the 
history", NEW -- or to both.

Comment 2

18 years ago
sounds like a dupe to me jsut not sure which of the two.

Comment 3

18 years ago
Please test this again.  This should actually be fixed now.  They shouldn't be 
being added to session history until after the site has been contacted and the 
content type has been retrieved.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 4

18 years ago
travis this does not work as of 2000030709 builds (WinNT). Bad url's are still added to session history (and displayed in url field). 
I do note that they are NOT added to global history however.
I just checked with 03/08 bits on linux(newest opt available) - same deal.
I'm going to temporarily reopen this bug to close it as a dupe of 14695
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 5

18 years ago


*** This bug has been marked as a duplicate of 14695 ***
Status: REOPENED → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → DUPLICATE

Comment 6

18 years ago
VERIFIED dupe
Status: RESOLVED → VERIFIED

Updated

9 years ago
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.