Start at www.mozilla.org. Go to http://www.cdmag.com/Home/home.html?article=/articles/013/064/combat_mission_fl.html Click on the first image in the right-hand frame. It will show the full-size image in that frame. Hit the (browser's) Back button. Note that we went back to mozilla.org. Hit forward. Note that we went back to the full image, but all the other frames are gone. I hit this "lost frame" thing a number of other ways at this site; this is an easily-repeatable one.

There have been times when he back button fails to work at all from within frames. Got to http://www.formula-1.co.uk/ andclick on a story. when you hit the back button nothing happens.

The problem with the original site is fixed. Still a bug with http://www.formula-1.co.uk/ - note that this may be related to internal redirects and JS code on that page (note the Go menu after loading the main page there). The site works fine with NS 4.7, not with Mozilla. Also note that in the Go menu, NS 4.7 just shows one entry; Mozilla shows 3 to 5. Changed the URL for this bug from http://www.cdmag.com/Home/home.html?article=/articles/013/064/combat_mission_fl.html to http://www.formula-1.co.uk/ Updated summary; added "on a framed site"

Win95 2000082508 I see this problem extensively with nerve.com. Go to Photography, select a gallery of pictures, click on one of the pictures to enlarge. Then hit back. Note that you don't go back to the previous page, you go back to the main photography page. Go back in and look at a picture. Hit back again, and you go out one level further than the time before. It's possible this is due to Javascript trying to manipulate the history. In any case, it works differently than in NS4.7/IE/etc. Added 'correctness'. Also now listed as all OS's. I advise looking at this soon.

The formula-1 page uses JS document.write(), which leads to a wysiwyg://url. We have not fixed this. Bug 35340 addresses that problem. Gagan and pollmann are looking at it. Marking dependency

1. Go to www.avp.ee 2. Click on the firs button in left frame (with russian flag) 3. Now click 3-7 button 4. Now click back 5. we are on main www.avp.ee, but should be at russian main page. Nominating for nsbeta3 - I saw it at many pages and it disallow to use back/forward function. You can also try to play with www.hinnavaatlus.ee.

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

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

Any attention to this bug? Mozilla is unusable on framed pages!!!!! PS marking critical since we cannot use Mozilla on many pages (is it dogfood?).

Then let's nominate it for nsbeta3 and rtm.

It already is nominated for nsbeta3, but there's been no action on it either way. Upped severity on bug 35340 (which is nsbeta3-'d and helpwanted - Eric is assigned it and can't address it for nsbeta3). Eric posted a partially-completed patch for the problem if anyone else has time to work on it.

Minus this for beta 'cause bug #35340 is now minus. So, do we RTM+ this?

I think we have to RTM+ it. This is a serious problem for usability.

Randell, MUST fix it for RTM, coz pages are not usable with this bug.

The formula-1 page seems to be behaving good. I clicked on a few stories in the right frame as well in the links in teh left frame and I could back. Is there any specific steps thatis failing in this page? Also the for www.avp.ee, please provide some specific steps to reproduce the bug. I could go back and forward in most of the links in that page. I didn't understand that "Now click 3-7 button". Please provide specific steps. Thanks,

I'd suggest rtm+, and adding mostfreq keyword, if this is the same problem as reported on www.securityfocus.com (for example) in bug 52670. That site is nearly 100% reproducable for this problem. I'm not sure if it's a duplicate or not.

Radha is not convinced there's a real bug here. Neither am I. Can we get some steps to reproduce the situation she describes?

MANY pages with frames show problems with Back. Looking through pictures at nerve.com (as noted here) causes Back to go back too far. Changing URL. I'd suggest checking some of the sites listed as dups of this bug - a bunch of those reports are recent. The bug also reproduces on www.avp.ee. Go to www.avp.ee. Click in the left frame on the entry with the flag. Right frame will reload to different data. Click on another button or two in the left frame (not the one with the flag). Note contents of right window each time. Now try Back. Note it doesn't take the right frame back to the previous data; it takes it back to the original www.avp.ee data. Works correctly on ns4.7 Removing [RTM NEED INFO]

Comment to last comment: About www.avp.ee. When clicking on the flag changes not only the right frame, also changes the left frame (look at the pic with flag - it's a different one). Also try www.hinnavaatlus.ee (there also left frame is changing).

OK. I have an idea of what the problem in many of the pages listed here. It is not just one peoblem. There are quite a few and some needs changes in other modules. Working on a fix.

For www.avp.ee, when clicked on the first link (with the flag), it retargets a new page to _parent, therefore the left and right frames change. There is a problem with setting the DocShell's LoadType when pages are retargeted to _top or _parent. mscott has a bug on this 47636. Marking dependency

I need some help. I'm trying to get a simpler test case similar to www.nerve.com. Can someone give me one? I have an idea of what's going on in other sites listed in this bug and in dupes of this bug. nerve.com looks little complex. Thanks,

Try http://start.blackplasma.net and click on one of the links in the sidebar. The page loads in the other frame, but the Back button isn't clickable (seems only if you use that as your start page however, the 2000100208-win32 build seems to work otherwise now, it was broken before) but you can press alt+left to go back. So for me, it seems to work like it should, EXCEPT for your startup page if it has frames.

In addition: Click on the number "2" on the left sidebar, click on the Slashdot link (or any of them actually). The Back button and alt+left are both non-working. But I suspect this has to do with the minimal JavaScript used for the page 1/2 sidebar links, since the links on the first page work fine.

Radha, how bad is this? Is this just an edge case that we have MOSTLY fixed?

I'm workign on a fix. Hopefully I Can get some attention from mscott

+ nsCOMPtr<nsISupports> treeItemCtxt (do_QueryInterface(treeItem)); + if (!*aRetargetedWindowContext) Why set treeItemCtxt (and declare it, even) outside the block of code governed by the if (!*aRetargetedWindowContext) test? (Also, trailing whitespace on the last line). + { + *aRetargetedWindowContext = treeItemCtxt; + // this is a bit hokey.....if we retargted this content to a different window Indentation and spelling (typo) probs here. // during GetTarget, then tweak the load attributes on the channel to set the // LOAD_RETARGETED_DOCUMENT_URI flag... - nsCOMPtr<nsISupports> retargetedWindowCtxt = do_QueryInterface(treeItem); - if (retargetedWindowCtxt && (aWindowContext != retargetedWindowCtxt.get())) + // This applies to urls targeted to named frames as well urls targeted to _top + // and _parent. + if (treeItemCtxt && (aWindowContext != treeItemCtxt.get())) { + // we must be retargeting...so set an appropriate flag on the channel nsLoadFlags loadAttribs = 0; More indentation (tabs? expand them!) problems here, all over. aChannel->GetLoadAttributes(&loadAttribs); loadAttribs |= nsIChannel::LOAD_RETARGETED_DOCUMENT_URI; aChannel->SetLoadAttributes(loadAttribs); + } My 2 cents. /be

www.nerve.com does not have any document.write(). So, removing dependancy on 35340. Most urls off of nerve.com are retargeted to _top. There was a problem with that (as reported in bug 47636). 47636 got fixed today. Please try this page out in the branch tomorrow.

Also, today's fixes by 47363 also fixed the www.avp.ee page (the link to the russian site problem).

I do not see any improvemens on www.avp.ee. Build 2000101208-Mtrunk win98se

It's getting to late for a fix to this bug to make it into N6 RTM. Sorry. Minus.

What? Are you kidding? I've saw it many times (can't remember now the URL's)!!! It is really dogfood!!! And you are planing to release ns6 with it? Who would use it? I'll try get a URL list affected with this problem.

Hey radha, I was mostly picking nits. If you can do a new patch that cleans up the variable being declared unnecessarily outside that inner block, and fix the tabs and indentation, I'll be happy to re-review. I think mscott should give an a= or not, though. /be

Restoring "need info" status.

The patch attached here is no good. mscott has fixed the underlying problem with urls retargeted to _top/_parent in 47636. I believe that should take care of most of the problem in the url listed above. This bug is now suffering from lack of QA and lack of time from me.

Here is another web site where unexpected things happen: http://www.javasoft.com/products/jdk/1.2/docs/api/index.html Tested with the M18 Release (win32), and 2000-10-12-13-MN6 (win32). Specific example: 1. Start at mozilla.org 2. Go to http://www.javasoft.com/products/jdk/1.2/docs/api/index.html 3. In the upper-left frame, click on "java.awt" under Packages 4. In the lower-left frame, click on "Canvas" under Classes 5. Click the Back Button. Four times out of five, nothing happens (for whatever reason, it worked once, after an unsuccessful attempt. Then I tried to do it again, and it didn't work again). Another site that used to break was www.news.com; same problem as the original report on www.nerve.com. If you went there, clicked on a link to an article, clicked back, clicked on the same link again, and clicked back, you'd end up at the site you were previously at before visiting news.com. It seems to be okay now.

FreeBSD 4.1 20001012xx www.nerve.com is still broken, though I think the _top/_parent changes helped some other sites. When viewing a picture gallery, the thumbnails in the right frame have target="photos". No matter how many photos you view, if you hit back you go all the way back to the root (www.nerve.com) An example on nerve.com is http://nerve.com/photography/carucci/marriage/. However, I normally test this by going to www.nerve.com, and clicking on one of the photography links, then on a picture in the (new) rightmost frame, which targets the middle ("photos") frame. I agree this is a major issue. I REALLY think we need to address this or risk getting uninstalled by people because we won't work right on heavily framed sites. This REALLY could cause problems on ecommerce sites that use frames.

Sigh. I have to minus this. There's no decent, agreed on fix in site yet. Radha will attempt to look at this on Monday ...

Is there a different bug for behavior like this in non-framed sites? I have something like this happen just browing www.mozilla.org. A typical use pattern I run into it fairly frequently is-- 1. Launch mozilla. 2. Select the link to go to tinderbox tree status. 3. Select a Guilty name. 4. In the popup box, select "changes made in last 24 hours". 5. Read the checkin comments. 6. Hit the back button. 7. Repeat from step 3. It doesn't happen all the time, but fairly regularly, hitting the back button in step 6 takes me two pages back to www.mozilla.org rather than the tinderbox page.

http://www.mozillazine.org/talkback.html?article=1678&message=7#7 Some more comments.

Added an attachment (zip file) with a test case for a Navigator 4 history within frames bug. There is a remote chance that it helps to explain unexpected behavior of Mozilla. Mozilla passes this case OK while NN4.7 still fails. Summary: On change of complete framesets, when returning to a previous frameset, NN4 loads the most forward instead of the last viewed page within the previous frameset. It's a bit tricky to explain but actually quite straight forward.

http://www.nvidia.com/ 1. Load it. 2. Press Download the latest Detonator 3 Driver. 3. Press to download driver (doesn't metter which OS) 4. Press back 5. You are on the main page. Need more? I'm marking this again [RTM need info] - there's a list of framed sites in which we cannot press BACK.

Will attach a test case where Mozilla definitely fails in a very simple history.back() situation. Simple to use case, hopefully easy to fix. CC'd people: You are probably interested in Mozilla's frames performance. Please look at http://bugzilla.mozilla.org/show_bug.cgi?id=24684 It is a high reward case where Mozilla's performance/appearance could be boosted considerably _beyond_ the performance of other browsers in the market: Your web sites will look a hell of a lot better. It is one of the rare chances where one could get something for (almost) nothing.

I am adding another test case where Mozilla fails in frames history. The browser frames history is hopefully OK after passing all 3 attached cases.

This needs to be a stop-ship. "Normal" users become VERY frustrated and end up closing/uninstalling Netscape 6 because of this problem.

And I'm sure that this shows up on a top 100 site.

another test case courtesy, wcd@CyberPortals4U.com http://CyberPortals4U.com/NS6b3_FRAMES/FrameSet-1.htm

cc'ing rpotts I think I have found the source of the problem. Here it is, When a subframe targets a page to _top(the case with nvidia, nerve.com/photography, cyberPortals4u.com), the load for it begins as usual, a SHEntry is created successfully in nsDocShell::AddToSessionHistory() and the member nsDocShell::LSHE is set for the top page. This load call is immediately followed by a call to nsDocShell::onstateChange() which clears the LSHE that just got set. When the _top's children come for loading, it enters the wrong part of code in nsDocShell::CloneAndReplace() since it can't LSHE for its parent. Thus the goof-up follows. I commented out that LSHE = nsnull in nsDocShell::OnStateChange() and I noticed that it fixed the problem. But I'm not sure that is a right thing to do, since onStateChange() is part of a document load notification. Rick Potts owns that code. I have cc'ed him and shall find him thro' other means.

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

mscott, can you please review the attached patch. rpotts and myself came up with this and this seems to fix the problems described here. Thanks,

Hmm, so removing the channel from the original load group b4 we added it to the new load group was generating a spurious on state notification change that was causing LSHE to get nulled out prematurely?

Yes. Because the channel had not been added to the parent's loadgroup yet, when the channel was removed from the child's load group, the DocLoader thought everything was done and generated a NETWORK done notification for both the child and the parent. By adding the channel to the new load group first, the DocLoader realizes that the parent is not done yet, so it only generates a NETWORK done notification for the child. The NETWORK done notification for the parent is fired after the retargeted document is finished (as expected).

Great fix. Nit: what's up with this indentation? + if(currentLoadGroup) + currentLoadGroup->RemoveChannel(aOpenedChannel, nsnull, nsnull, nsnull); /be

gotchya. Thanks for the explanation. Okay this sounds like the correct thing to do. sr=mscott Although i bet brendan will bug you about the identation. Oh wait, I see by the bug collision I just got that he already did =).

We have an r= and a sr=. Can this be moved up to rtm+?

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

Adding self to CC list

OK, "rtm+".

Just to add a bit more fuel to the fire.... Byte's rather negative review of Netscape 6 PR3 at http://www.webtools.com/story/browsers/TLS20001012S0001 specifically mentions a problem with EverQuest message boards which sounds like this bug.

This bug is highly visible to everyone who has used NS6PR3 who I've talked to (~50-75 people). Marking mostfreq on that basis and waiting for the PDT.

rtm++

Fix checked in to trunk and branch

Does not work on www.nerve.com if it is the first document that's loaded in a window; the back button will simply stay shaded. Does work with that site if another document was loaded first. Also does not work on www.avp.ee, even if it not the first site loaded in a window. Tested on 2000101908 Linux. Reopen?

The problem described in the previous comment sound an awful lot like bug 56625.

Should it be fixed in 2000101904-Mtrunk? I see it on this build on www.avp.ee, www.hinnavaatlus.ee (back button is enabled). Hmmm. But when I moved back from www.avp.ee to www.hinavaatlus.ee it works...

To my previous comment: It works until left frame is not changed...

VERIFIED Fixed with 2000102008 branch builds AND VERIFIED Fixed with 2000102009 trunk builds

But it does not work on www.avp.ee...

This is definitely NOT fixed - see for example http://www.czechcomputer.cz/ I am using Linux nightly 2000102221 from trunk.

OK. We have at least 3 sites where it does not work. I reopen it and give a site where Mozilla does have the summary. On www.hinnavaatlus.ee: 1. Open the site. 2. Press CD-ROM in the left frame (it doesn't matter which name you press actually) 3. Left frame changed 4. Press Aopen in the left frame (it doesn't matter which name you press actually) 5. Right frame changed 6. Now click on some entry in right frame I could see such a behavor: a) it takes you back (to 5), but when pressing back once more it take's you not to (4), than to main right frame and 3 in left one. Left frame will never go BACK. Even when reload the page the right frame is reloaded, but not the left one. b) back button do not work. It is highlighted, but do nothing. When this happens try to reload the page... The effect left frame is 3, but the right one is at the start page. c) pressing back moves you directly to main right frame Try to playing with thi site you'll see many intresting things.

we badly need multiple bugs filed on this one. Obviously, the patch that made it in for RTM fixed some framed pages but not other ones. The summary here is too generic. Eugene et al, can you go through the pages that do and do not work and compare in order to figure out what is different in their design? And possibly file another bug when we have better test cases?

Pushing back to need info since this re-opened. If we can close it RSN, then please restore to double plus before closing (to get qa scrutiny).

Radha, is this a brand new problem that caused this to be re-opened?

No, This is no brand new problem. This bug has now become a placeholder for all frames related problems.

I need more info on this bug if it's mostfreq, and, as jce2 says, "The summary here is too generic." If it's a placeholder bug it can't be mostfreq on its own, unless the bug is "Back doesn't work in frames." Is that it? Gerv

Gerv - I think the bug is "Back button doesn't work in *some* frames." I was able to easily reproduce this problem by following the instructions from Eugene Savitsky's comment from 2000-10-23 04:54, in a CVS build from this evening (2000/10/26).

One more. http://www.ase.ee/dict/dict.html Enter some in form. Right frame changed, but when back, then it goes to previous page. RTM, please fix this for RTM!!!!!

If this is a tracking bug now, then it's not really appropriate for it to be a "need info" bug at this time. Minusing for now ...

Do you see how many pages are suffering from it? I saw it now at http://www.grandprixgames.com/ , but could not repro it... Then I deleted the cache and it's here again! 1. Load the URL 2. Press English 3. Now press Game Info 4. Press Press 5. Press back. 6. We are on load page (1). 7. Press forward, we are on 2. 8. No more forward... Where are pages 3 and 4?

I have more comments on this test above... When pages were loaded than back works for the second time you visiting it and go back. But when you try to load pages which are not in cache and go back it does not work again... Test: 9. Press game info 10. press Press 11. Go back. 12. All works fine (9) 13. Press back 14. Fine (8) 13. Now press Reviews 14. Press Promotional 15. back works fine. 16. Press Screenshot and immediately press Game info (do not wait until screenshots were loaded!!!) 17. back moves you to Reviews 18. Go again pp. 16 and 17 19. and again 16-17 20. The result is you are taken to Reviews 21. Now go again to screenshots, wait until they all are loaded 22. Go to Game Info 23. Pressing back moves you to screenshot just as it should be... So we have a test when doesn't completely loaded (not cached?) frame does not go back. I take a risk and make this bug again [RTM need info] - there's tons of framed pages and they are unusable. This bug, bug with disabled back button and I feel the bug about cached frame is a new one... Those 3 bugs causing me to use NN 4.76 in framed pages and we cannot ship a product that fails basic dogfood.

I'm back to this bug again. I'm not sure if the underlying problem in all the problem urls listed below is the same. Some of the things I know that don't work and won't work in RTM 1) All pages created with JS document.write(). pollmann has bug on this. Needs implementation of wysiwyg:// protocol 2) JS accessible frame specific history. we decided to take out frame specific history accessible only thro' JS's history object. All subframe navigations are now tied to the back and forward buttons. 3) While debugging www.avp.ee, I found that the JS History object is not properly hooked up to the session History object in docshell. It is still wired up to webshell which no longer houses session History. I will try to fix this for RTM, since this has more visibility. Not sure if this is the cause of misbehavior in avp.ee

rtm need info means pdt wants to know about the risk of a patch, i don't see a patch [no patch keyword] i'm zapping rtm need info. radha and all i suggest you convert this bug into a meta. all: please triage these reported incidents as radha did, track down the problems. Radha should file a specific bug for the most recent discovery, marking it as blokcing this useless meta bug radha, pdt: sorry for disturbing your bug, status and fields

I have attached a patch that fixes www.hinnavaatlus.ee. I'm having trouble reproducing the problem with avp.ee and ase.ee/dict/dict.html. These 2 pages seem to work fine most of the times. The latest attachment is to a part of code that affects all frameset navigation. I have tested it to some extent. I would appreciate if someone can run this patch thro' some of the urls listed here and other ones and let me know if something regresses with this patch. The patch is based on latest trunk builds.

I have attached another patch which would be little better than the previous one. But both should work to fix the problem in www.hinnavaatlus.ee and similar pages.

Mozilla Build ID: 2000110104 Here is a simple framed test page I developed for my bug #55359 (labeled a DUP of this one). http://www.ccs.neu.edu/home/bcortez/mozilla_tests/testPage4.html Test Case #1: 1. Once loaded, click on the hyperlink "Page Number 2" in the Top Left Frame. 2. Page Number 2 will load in the Right Frame. 3. Hit the Back-Button. NOTE: Look at both the Back-Button "drop down list" and the "Go Button" to notice that the frame navigation is not listed in the browsing history) 4. You are returned to the page prior to entering this test frameset. 5. Load the URL above again, repeat step 2 for each Page Number hyperlink. You'll see the same behavior of returning to the page immediately prior to entering this URL. 6. Do the same for the links in the Right Frame....same behavior. Repeatability: 100%

This change looks good to me. (sr=rpotts) -- rick

r=pollmann. The last approach seems to be the safest and best of the three. After sitting down and talking through this with Rick and Radha, and doing some quick testing of my own, I'm convinced that this is the right thing to do.

I'm on a mission to [rtm+] bugs that the PDT might approve at this, the literal last minute. /be

Please get this in on the trunk and get some focused positive and regression testing. After that is done and the results described in the bug, please move this back to [rtm+]

Radha, is this on the trunk yet?

The latest patch got checked in to trunk last night. Please remember it is not a cure-all patch. The latest patch takes care of a particular problem with frameset navigations. I do not intend to close this bug. Once I check this in to the branch, I will clear all "rtm" in the status board and keywords section and continue to work on this until all frameset problems are take care. If anybody tries out the latest trunk bits and see any regression in frameset pages, (ie., works fine in yesterday's build and not today's), please let me know. I will also be testing these with a bunch of sites. The list of problems I had described earlier on 10/27/00 14:28 still exists.

I'm crying... I'm so happy... It seems to work now!!! But we need to test it a little bit more. PS If this get's to NS6 RTM I'll put a pop-up window for ie and other browsers with NS6 advertizing. :)))))))))))))))))))))))))))))

If ezh is happy, can this bug be rtm+'d? I know it's almost too late, but my money is on a respin. /be

I opend a new bug 58906 about not completely loaded frames. But this must be defenetly in RTM!!!

OK, let's plus it.

rtm-, too risky this late.

What risk? You've got your damn release canidates under your belt, and this fix has worked BEAUTIFULLY in the trunk. Changing back to rtm need info.

Can we get someone to go up to bat against the PDT on this one? I would, but I don't know if they would accept a phone call from me.

pasting a copy of a email I sent to PDT, PDT, I noticed that bug 46828 got minused with a comment "too risky this late". If it will be of any help, I would like to add that it got checked in to trunk last night and I have been testing several frameset pages today and I haven't found any regressions because of my changes. Infact, more of the urls listed in that bug are working now. As I have said in the bug, this is not a cure-all patch. But it is definitely one step closer to getting better behavior on frameset pages with back and forward. The changes are very contained and affects only the frameset navigation codepaths. Rick potts also mentioned that to me personally when he super-reviewed the changes. There is no guess work in the patch. So, if there is going to be a respin, please re-consider this. Thanks, Radha.

Radha: As I mentioned in internal email, we don't have time for another limbo based respin :-( . The current N6 respins are restricted to critical pull-from-the-wire bugs (defined by marketing and legal), plus a select group of high return, small size, low risk, restricted code-path (re: qa testability) changes that can be tested in time for our target dates. Your code is in a potentially dangerous area (forward and back have been fraught with perilous regressions for many months), and is certainly not small. That makes the risk too high for this late date. It might have made it into limbo 1 or 2, but it is too late now. Sorry. JCE: Please stop changing status on bugs in the way you just did. The status you changed (rtm-minus vs rtm-need-info) is meant to communicate between contributing Netscape staff. The assigned Netscape engineer (and manager) are the only persons that should typically be changing a bug from rtm-minus into rtm-need-info. You are certainly welcome to add comments, arguments, patches, testcases, etc. Please do not deliberately disrupt the handling of bugs by contributors at Netscape.

Hmmm, seems to me the RTM will be definitely piece of shit. :-( Sorry for the crude words. Unusable SSL support, not working history on 50% of frameset pages, why you release it at all???? Maybe you want to finally show to users who haven't any clue about Mozilla, but who will try NS6 that the only functional browser will be MSIE forever. :-((((

I already know - NS6 is piece of shit. I ask PDT a question: who will use it? I'll defenetly not. And I will do not anythink to promout it. There is so many bugs left that are viewvible on the first minutes of using, but they want to release it... Look at this: 46375, 58819, 57095, 57438 etc. It is basical funtionality and perf!!! And some of them have patches! Why want they release a buggy product? Release one more PR and take one more mounth to fix more bugs, but managing want a release and that's all... Managing should thing stategic, not tacktic. The first impression the main impression and on it depends will people use further releases or not. Netscape will loose they last admirers. It is stupid and will kill the all project. IE vivat forever? Sorry for the spam but I cannot just sit and look how they shitting all good things up.

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

You forgot bug 45747 in your list... that one will keep many corporate users from even thinking about using Mozilla (or even the IS Dept. approving for use). Oh ya, and then there's bug 20847/bug 32148... As much as I'd love to see NS6 released, I'd hate to see it suck. I'm begining to think that Eugene is right and we should instead do one more "feature complete" preview release. Many companies do this... in fact, I've seen a few that didn't change at all between final Beta and RTM, just because they wanted to make sure they had crossed all their T's and Dotted all their I's.

People, If you think that the user community will sit back and embrace Netscape 6 with this lack of functionality, you are SADLY MISTAKEN. This first release of Netscape 6 is your last chance to come back. Blow this one and you might as well not come out with another version. I am speaking from both a corporate standpoint and a personal standpoint. Also, knowing all of my newbie friends and AOL'ers (who regretfully ask me for advice) who are waiting just to try this "new" browser, they will drop it like a hot potato if framesets don't work properly and will go back to IE and NEVER, I repeat NEVER return. <RANT> If that's what marketing wants, then they are more ignorant of their market segment than I thought. Too bad too, I have always been a Netscape supporter since version 0.99, and if this release happens without this fix to the frameset issue, then you have lost me forever as well. Basically, you have got one last chance in this game to pull off a coup, this is reality folks, face it and get off your high horse marketing dept. </RANT>

jar: radha and rpotts testify that the patch affects only frameset back and forward navigation. If you believe them, or can verify it yourself by reading the code, then the risk is confined to frameset pages. It may still be the case that you feel the risk of any change is too high. It may be that there is no chance of a respin. I urge the PDT to reconsider one more time, if there's any chance of a respin. This bug makes Netscape unusable for people who frequent frameset sites. If Netscape had a popular frameset site among its web properties, I'm sure it would have been fixed sooner. But because home.netscape.com, my.netscape.com, etc. don't use frames, this bug was under-owned and under-valued. That's not all the PDT's fault, of course. It does hurt Netscape's reputation with users who care about frames, and it should. I hope the PDT considers that if a chance to take this fix before the next major release (which will be a while from now) arises.

JAR: I will have to disagree with your comments that back and forward have been frought with *perilous* regressions. Ever since docshell landed, Back and forward have been getting better with a)Implementation of frameset navigation b)Fix of 47636, 53708, 52670 c)Checkin of a earlier patch attached to this bug on 10/16/00 16:29 The current patch fixes a problem that could affect most frameset pages. In my opinion the fix is definitely high return, in a restricted code-path and has the most minimum code required to fix it correctly. If you look closely, the changes to nsSHEntry.h/.cpp are addition of a attribute and getter/setter for the same. The changes to docshell are to use this id instead of pointers to do an existing comparison. There is no change in logic. The element used for comparison has changed.

More comments: As far as QA testability, I understand that QA doesn't have several testcases for back and forward on frameset pages and they have been pretty much using urls provided in bugs like this. I tested what ever they have and the latest patches don't regress them. I tried to get claudius to help me in regress testing this on the trunk. But he is very busy QA'ing the RTM candidate build and the limbo build. I repeat once again that the code-path is very restricted to pages with framesets. Also, the latest patch fixes http://www.javasoft.com/products/jdk/1.2/docs/api/index.html (another url listed in this bug)

PDT discussed this at great length and decided that other stoppers have to get fixed first, but *IF* we respin, we'll consider taking this.

Well, it looks like I begin recommending to my company to drop support for Netscape 6 in the next product release. Too bad....we need robust frame support, without it, there's no point in recommending a browser to our corporate customer base. I have been fighting tooth-and-nail on this issue with my company only to have some (seemingly AOL) marketing weenies thwart all of my efforts. Goodbye Netscape. It was a nice ride while it lasted. Reality is calling guys and you are too busy deciding what wallpaper to put on the bathroom wall to answer the phone. This is a sad day indeed.

bcortez: it ain't over till it's over. I predict a respin. /be

Sorry, radha, but I don't think your patch completely fixed navigation on the Java API web site 0. Start from www.mozilla.org 1. Go to http://www.javasoft.com/products/jdk/1.2/docs/api/index.html 2. Click on java.awt (bottom left frame changes) 3. Click on Canvas (right frame changes) 4. Click on Object (right frame changes) 5. Bring up the drop-down menu on the Back button and go to 1. Notice that the forward button is now disabled, and that the right frame did not change as it should have. If you press back, going back to 0., then start pressing the forward button, things work again. The behavior also seems correct if at 5. you step backwards without using the drop-down list. I'm using 2000-11-02-06-Mtrunk. Someone please tell me that I'm wrong, and that the above works for them! Another site with odd behavior (sorry, don't have time to narrow it down) is www.motortrend.com. Click through the SEMA 2000 links and try going backwards and forwards through the pages in the articles. I had cases where the back button stopped working. It's a more complicated site, so maybe the bug here is one of the known issues that radha's bug didn't fix?

Non-Netscape people, please stop spamming this bug with rants and obscenities. You are distracting those who are actually making an effort to get this bug fixed, and you are not likely to achieve anything (except maybe revocation of your Bugzilla account). Some people are obviously unhealthily obsessed with one particular commercial distribution of one particular beta version of Mozilla. If you can't bear to watch, then remove yourself from the CC list. Thankyou.

i wish people would realize that the continuing mozilla project will survive regardless of the state of rtm. however, considering that the fix involved is of limited scope and that even this partial fix easily fits into the "high yield, low risk" category, leaving out radha's fix would be inappropriate. any element of risk has been clearly outlined above, and the trade-off of not including at least a partial coverage with a promise of eventual full coverage of this bug is worthy of the risk that has been thus far delineated. as can be seen, the failure to include this patch could ignite a strong enough negative response as to cause a serious setback to the ns6/mozilla project. thus, the risk must be weighed for both choices. assessment of the lesser risk, of course, is pdt's responsibility - but i would think it should be obvious in this case. okay, that was my two-cent lobbying effort.

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

radha, could you produce a patch that applies cleanly to the branch? I couldn't seem to get the 11/1 patch to apply cleanly to my branch tree.

I have a attached a patch that applies to the branch. The previous one was to the trunk.

pdt: marking rtm++ , please check in ASAP into the branch.

(a chorus of cheers erupts from the "future users" gallery). :-)

my last attachment is a linux-friendly version of radha's branch patch

I have checked in the fix to the branch. As discussed before, removing all "rtm" from keywords and status whiteboard to keep the bug alive for post-rtm work.

has this fix been checked in yet? I'm waiting to respin.

Yes, this was checked into the branch, as shown by bonsai. This bug should now become a META. It's already long and confusing.

I thank you all for your help and support in finding a patch *and* get it into RTM. Really appreciate it. Now, on with taking care of rest of the problems.

Hey Radha, since the initial part of this bug fix has been checked into both the branch and the mozilla tip, can we mark this fixed and move the remaining issues into a new bug? I bring this up because as long as this bug is listed as open QA is not going to specifically test for this bug fix. Ideally, they are looking for fixed rtm++ bugs on the branch to verify and this is never going to show up on their radar. The same applies for mozilla tip builds as well.

Changing URL and marking fixed so that QA can verify. I have quite a few bugs on frameset navigation. I will go thro' them and decide whether to re-open this (after QA has verified) or open a new one. I will send a email to claudius to take care of this, even though it doesn't have a rtm++ in the status board.

How many separate bugs need to be filed for frames history before we're not told to file new ones each time? Frames history is completely horked and it's getting to be a PITA to follow from bug to bug to bug to track what is going on. Should we just file a new bug for each and every site that frames navigation is broken on? I have opened a META bug 59387 in an attempt to track this.

More urls from 56625: http://www.cinescape.com http://www.olivettilexikon.com/index2.html http://www.aacpdm.org/home.html http://www.hansa.ee/ http://www.h-oda.com/

The http://www.czechcomputer.cz/ still doesn't work correctly on the trunk nightly 2000110621. Now it stores something into the history list when navigating through the site, but when I press the back button or when I even try to jump more steps back in the history it doesn't do anything. It's probably one of the things which Radha mentioned that still needs to be fixed. I think that probably something incorrect is put on the history list.

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

Verified based on comments and testing on Linux

Mass removing self from CC list.

Now I feel sumb because I have to add back. Sorry for the spam.