Steps to reproduce: 1) Go to my.netscape.com 2) Click on a link in the technews section 3) Docshell first initiates load of a page in netcenter with loadType loadLink 4) Then it is redirected to a page in cnet. This page is processed with loadType loadNormal. 5) Docshell adds both these pages to SH. Therefore if I click back now, I will go back to that netcenter page in step 3) which will again redirect me to cnet. I have to use the Go menu to get out of this loop. Is it possible to detect a redirected URl and pass in a loadType of loadRedirect, so that docshell will not add both original and redirected urls to SH. Not sure if this belongs to necko or docloader.

Hmmm... the redirection occurs in necko, but the onRedirect gets conveyed thru nsIHTTPEventSink (which I bet nobody implements) :( cc'ng danm the new leader of the HTTPEventSinkMovement (I forget the bug) Once you recv. an onRedirect it should be possible for you(/webshell) to set whatever loadattributes change that are needed.

Nav triage team: [nsbeta3+] as per Radha

Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so the queries don't get all screwed up.

->ruslan

Gagan, so what do you want me to do re: this bug? In'm confused. You said that it would be the right place for the docshell to add this attribute or you want addredirect to add it automatically? I'm not sure that's the right thing to do, cuz it can cause side effects.

ruslan, do you have any info on this? I have bugs that are waiting on this. Thanks,

I don't think there's anything to be done here in the networking layer; -> gagan to make a decision what's the right fix for that.

per PDT: P3-P5 priority bugs changed from nsbeta3+ to nsbeta3- since we have more important work to do for Seamonkey. If you disagree, please state your case in the bug report and nominate for rtm and adjust priority if this bug was mis-prioritized. Thanks.

->WORKSFORME (Linux build 2000100909) Reporter, please re-verify with latest build.

->WORKSFORME (WinNT build 2000101008)

reporter: This bug is a "futured" or "untargeted" bug which has been "resolved/works for me". Most bugs meeting this criteria are usually somewhat out of date or working in the current builds. If this bug is not happening for you in a recent build (such as the Mozilla daily build, Mozilla 0.9.3, or Netscape 6.1), please use the friendly "Mark bugs as VERIFIED" radio button to set this bug to "VERIFIED/WORKS FOR ME" If you reported the bug on a platform (e.g. Linux) and other contributors reported on another platform (e.g. Mac OS), please comment that it works for you but do not verify it yet. For these multi-platform bug reports, we need to verify all reported platforms -OR- create new "still broken on platform X" bugs when you verify.

-> history steps describe use of the "back button"