***Overview Description: Just pressing enter or typing in the same url a second time and pressing enter adds an identical, duplicate entry to the Session History. It appears in the 'Go' menu and when clicking 'Back' you have to pass through it (even though it doen't actually load, different related bug) ***Steps to Reproduce: 1) go to http://www.mozilla.org 2) press 'Enter' while the location field has focus. ***Actual Results: You've now added an additional, useless entry to SH. ***Expected Results: Reload the page. ***Build Date & Platform Bug Found: 2000082108 Win98 ***Additional Information: This works fine it you just click 'Reload'. Discovered this bug while verifying bug 45770. i just wrote bug 49911 which may be related

nominating nsbeta3

nav triage team: nsbeta3+ because it affects everyone and is damn annoying, makes session history practically unusable.

Marking P1

I'm aware of this. Actually, I would say that this behavior is helping us coverup other notoriously bad bugs like, "Back/forward don't work properly in pages with same urls but different post datas". Because of adding the url again to SH and simply traversing thro' them, we are avoiding more complex postdata comparison in the code. I wouldn't buy the phrase, "This makes SH practically unusable". Back/Forward/Go menus work just fine though there are 2 entries for the url in Session History. I don't think this should be nsbeta3+, P1. Fixing this involve more changes to docshell and *may* re-open some of the bugs I fixed recently. I think we can address this post 6.0, when we will hopefully have code for postdata comparisons etc...

removing nsbeta3+ for re-evaluation

PDT marking nsbeta3-

Hrmm, I always thought pressing enter in the location bar without changing the url was the same as shift-reload. Guess I was wrong, because shift-reload doesn't add an entry to session history, but pressing enter in the url bar does.

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

Patch looks fine to me but if you want to trap the postdata issue, maybe you could only set updateHistory to PR_FALSE only when the URIs are the same AND there is no postdata, r=adamlock@netscape.com

sr=alecf

fixed today

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

nav triage: nsbeta1

mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31. if you think this particular bug is not fixed, please make sure of the following before reopening: a. retest with a *recent* trunk build. b. query bugzilla to see if there's an existing, open bug (new, reopened, assigned) that covers your issue. c. if this does need to be reopened, make sure there are specific steps to reproduce (unless already provided and up-to-date). thanks! [set your search string in mail to "AmbassadorKoshNaranek" to filter out these messages.]

Note: this caused bug 182689 and probably various other frameset bugs...