The latest Linux nightly build (2000-09-21-06) cannot pass smoketest IB.3. To reproduce: 1) http://home.jp.netscape.com/ja/ 2) http://home.netscape.com/ko/ 3) http://home.netscape.com/zh/cn/ 4) http://home.netscape.com/de/ 5) Use the dropdown button on the back button to go back to #3 6) Click back all the way to #1 The forward button will be disabled.

Adding keywords. Nominating beta3 dues to smoketest failure.

Ugh. This is bad. It happens on Windows too with yesterday's 2000092005 build. There's something screwey about that first URL because it shows up twice in session history. Radha, what's going on here and how common is this kind of problem?

cc'ing adam. In case this is a regression of the load flags changes that were checked in yesterday?

I just now pulled the tree. I see the problem. netscape japan and netscape deutsche 1) and 4) do redirections. So the back and forward misbehave on those pages. I already have a beta3 bug for redirections. I think this should be marked dupe of 39948. I don't see how this is a smoketest blocker

This bug seems to be related to some weird Javascript in the first URL. At the top of this URL is this Javascript: -- // the code redirects 2.x users to the download page. The FRAMESET tag hides the rest of the page so it doesn't display. if (parseFloat(navigator.appVersion) < 3) { document.write('<FRAMESET>'); location.href="/ja/download/index.html"; } else if ((parseFloat(navigator.appVersion)>=5)&&((navigator.appName=="Netscape")||(navig ator.appName=="Mozilla"))) { location.href="/ja/index1.html"; } -- Mozilla triggers the second condition which changes the location to: http://home.jp.netscape.com/ja/index1.html The funny thing is that the page you are redirected to also has this Javascript at the top. I think that Mozilla is running the script and not realising that URI it has been asked to load is the same as the current URI. It adds two entries to the session history. From there it's likely that the session history is getting confused as to how many entries it has so when you start to navigate backwards you run off the end of the SH and into strange behaviour. Since the page is not reloaded the duplicate session history entry should not have been created. The workaround for smoke test is to disable Javascript or find another Japanese character set page. Does this make sense?

cc'ing eric. This looks similar to a bug he has on location.href. I think what happens is, when the home.netscape.com/ja/index1.html comes for loading for the second time, Session History thinks that it is a fresh traversal and therefore removes all previous forward traversals, which included the korean and deutsche page. Therefore 2 entries for the japan page and no more forward pages. I would like to mark this as dependant of my other redirection bug, 39948. Triage team, PDT, I don't think this is a smoke test blocker

Radha, is the location.href problem you are thinking of bug 48382?

pdt agrees p2.

a note on the smoketest keyword. Having the smoketest keyword there doesn't necessarily mean "the world falls apart for this bug". It really just means there is a specific smoketest that fails specifically because of this bug. the smoketests are there to catch regressions of basic functions on a daily basis. This smoketest did just that - it caught a basic regression on the day it happened.

Let's get this thing fixed for RTM if possible.

nav triage team: adding [RTM NEED INFO] as a way to ask for a patch so we can rtm+ this.

Clearing milestone.

Minusing this for RTM. It's not an bovious or common thing that will happen to users, we believe. Sorry.

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

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

nav triage team: Not a beta stopper.

client side JS redirection. 39938 is addressing all clientside redirection problems. *** This bug has been marked as a duplicate of 39938 ***

verified dupe