When navigating through a frame set back work initially, but after a while I get: JavaScript error: line 0: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebNavigation.goBack]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://navigator/content/navigator.js :: BrowserBack :: line 530" data: no] this is the mozilla nightly build as of M20010116

Reporter that build is over 3 weeks old. Try downloading the latest nightly and create a new profile. See if that fixes the problem. Report back either way.

Same deal, I tried the 2001-01-25 nightly build and got the same thing, though line number moved a bit. I assume that's just a version difference: nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://navigator/content/navigator.js :: BrowserBack :: line 568" data: no] On www.storagereview.com I just read the first review ( about some TEAC CD driv) and after getting to the conclusion page I start going back. The first page went back ok, but then I got this error the 2nd time I hit back.

Marking NEW as per reporters comments.

reassign

I also notice "Back" not working after a while, but with some different symptoms. I don't get the error message specified in the reporter's comments, but I notice that clicking the back button in a frameset sometimes produces no results. On further investigation, I find that it is just the 2 most recent entries in the history list that it will not go back to. If I click the drop down list on the back button, I can go back, but only if I choose at least three entries back. When I do that, the two new forward entries get me nowhere. This is a consistent behavior that can be reproduced fairly easily. I most often encounter this behavior when browsing javadoc documentation.

Moving to Session History component.

Reporter: Can you provide exact steps to reproduce. I spent some time at the above site. I often got the following assertion error, but not the one you have reported. JavaScript error: line 0: uncaught exception: [Exception... "Access to property denied" code: "1 010" nsresult: "0x805303f2 (NS_ERROR_DOM_PROP_ACCESS_DENIED)" location: "http:/ /www.storagereview.com/styles/load_css.js Line: 1"]

Don't see a problem again in this site. Went to the Teac review site and it worked just fine. Marking WFM. If the problem exists in a different site, please list it and provide the steps to reproduce in those sites.

I am reopening this bug, since I have verified it on two separate computers and now have steps to reproduce. I don't get the error message the original reporter did, but like I mentioned in a previous comment, I do find that Back stops working in frames after a while. I said before that I often notice this bug while browsing the Java API javadoc. I'll use those pages as my example. To reproduce: 1) Go to http://java.sun.com/j2se/1.3/docs/api/index.html. 2) Click a classname link in the lower right navigation frame, the Boolean link for instance. 3) Click an internal link on the page (meaning one that points to another location on the same page). Continuing the example, if you've clicked the Boolean link and that page has loaded on the right, scroll down to the methods section and click, say, the toString() method link, which should move you further down the page to the information about that method. 4) Click a link that points to a different page. Again, continuing the example, you can click the String link that you find in the toString() method description. 5) After the page loads, click Back. Nothing! Summarizing the basic steps again: 1) Open a frameset page. 2) Activate a link that changes a page. 3) Activate an internal link on a page. 4) Activate a link that changes the page. 5) Click Back. It seems that this strange behavior only kicks in after a user has clicked an internal link, then an external one. If I click Back after step 3, it stills works. It requires the combination of 3 and 4. This behavior does not appear until both steps have been performed. I have seen this behavior on Windows 98 (home) and NT (work); the original reporter chose Linux, so I suggest the OS is all. I will check Linux again and report back sometime Saturday (feb 17).

confirmed on Linux using Mozilla 0.8 by following the same steps detailed in previous comment...please change OS to All.

Changing OS to all as per comments.

I can reconfirm original reporter's error message on CVS build as of 02/23/01 on Mozilla/5.0 (X11; U; Linux 2.2.18pre11-va1.8 i686; en-US; 0.9) Gecko/20010220: JavaScript error: line 0: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebNavigation.goBack]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://navigator/content/navigator.js :: BrowserBack :: line 585" data: no] It happened after browsing some time on mozilla.org, but I haven't been able to reproduce it in a deterministic way. Sorry. Will try further.

I can reproduce this bug reliably in Windows build 2001022209: 1. Go to URL http://java.sun.com/j2se/1.3/docs/api/index.html 2. Click Reload 3. Click the back button several times Expected result: The browser goes back to the previous URL. Actual result: The browser stays at the current URL at generates this error in the JavaScript console: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIWebNavigation.goBack]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://navigator/content/navigator.js :: BrowserBack :: line 571" data: no]

I've reproduced the results of the last reporter. Apparently, this bug can be reproduced by simply clicking reload in a frameset, not only by the multi-step process I described previously. I noticed, though, that by following those steps that I detailed, the same Javascript error appears in the Javascript console. Also, clicking reload in a frameset fills the history list with the same page (the frameset page).

I also find that often the "back" button is simply greyed-out when visiting pages with frames. Should this be a separate bug (or maybe already is one)?

hambone: might very well be a dupe, search for grey, gray, and disabled with 'back'. Oh, and please try to figure out specific reproducible steps. These bugs are real hard to fix w/o repro steps.

I think the bug hambone is encountering is 56062.

Aha! These symptoms are almost exactly like the ones in bug 66203 if this isnt a dup, its at least related... or a blocker... or a blockee... or something :)

I don't believe it to be a dup of that bug, since that addresses a different behavior, but I do agree it is related...other bugs also probably related include 69206 and 56062.

hmmm .... not sure if this is the same thing i'm seeing or if i should file a new bug (course maybe i missed it and it's in there already). basically there is one site in particular where back button's don't seem to work ... I think it has to do with a frame on the top where the content is rotated out (every few seconds/minutes) by JavaScript ... it's an ad banner. go to www.cinescape.com, and browse the site for a few minutes. eventually try the back button. it simply doesn't work. Works fine in IE and NS 4. again, not sure this is related, but i'm sure whatever it is impacts other sites and their frame navigation.

actually, is what i was talking about more like bug 59387?

rob, bug 59387 is a 'meta' bug used to track other bugs (such as this one) all from one convenient bug instead of having to chase them all down.

Got this very same bug when I was writing a (rather long I might add) E-Mail using my online access at www.connectfree.co.uk. You'd need my password and login name to get to the actual page unfortunately, but if its of note this site uses CGI scripts to navigate round it. I was writing out an EMail and submitted the page only to be told I'd missed out the @ in one of the EMail addresses. Tried to get back to the page and it wouldn't let me. When I hit the back button the browser flickered as if it was refreshing but never actually went anywhere. After I'd played about with it for a while I found I could get to pages before and after the "Compose the EMail" page and the "Confirmation of Send/Error Message" page but not to those two in particular. I went ahead and re-wrote the E-Mail again and this time made sure everything was OK and had been filled in, sent the EMail successfully and was able to get to the "Compose the EMail" page and the "Confirmation of Send/Error Message" page this time but could still not get to the previous instance of these two pages. Heres what came up in the Javascript window: Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIClipboard.setData]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://communicator/content/nsContextMenu.js :: anonymous :: line 614" data: no] Does anyone know if this has this one been fixed in later builds? I'm currently running Mozilla/5.0 (Windows; U; Win98; en-US; 0.8.1) Gecko/20010323 on Win98SE

This problem appears to have been around since RTM. Has there ever been any more investigation into this?

the bug has been assigned and targetted for moz 1.0 so that means not now but soon.

Note that this is a bug that stops the Zope management interface to be usable for me in Mozilla (main thing blocking my switchover to Mozilla now from Netscape 4.7). It uses frames and Mozilla's back button shows varying amounts of disfunction; sometimes it goes back too many pages, though most frequently it doesn't work at all. If people need a Zope install to test with, you can get one at www.zope.org (get the latest 2.3.2 beta 2). If so desired I can also run a Zope for you all to play with on a machine here.

I think this will get fixed once I fix bug 68847

I can't reproduce the problem in any of the urls mentioned i this report.

Assign it to someone else then please! I can reproduce this bug on any computer running Mozilla, under any OS Mozilla runs under, at any time. Other people can reproduce this bug. You can't, so you mark it WORKSFORME? I don't see the Javascript errors in the Javascript window anymore; maybe that's the symptom you can't reproduce. But on the latest build, using the very steps I described, the Back button STOPS working. This very bug turned a friend of mine off from using Mozilla. "Who's cares if it can render CSS and XML and DOM if it can't do the basics!" he told me. I agree wholeheartedly with his sentiment. I put up with Mozilla's bugs because they eventually get fixed. Please don't tell me your not going to fix this bug that impacts my browsing on a constant basis. Please fix this bug! It **does** exist.

Sorry for the rant, but this bug has to get fixed. I downloaded and tested last night's builds for Win98, WINNT, and Linux. I tested the Win98 and Linux builds on my home computer, and the WINNT build on my laptop from work. In each case, the steps I outlined previously to reproduce this bug succeeded in reproducing this bug. Once again, after following the steps, the Back button failed to work, although the Javascript error that used to appear in connection with this bug did not show up in the Javascript console window. But the most important thing is not what shows up in the Javascript window, but that the Back button fails to go back through the history. Will someone else please test and verify that this bug still exists? And will someone demonstrate this behavior to Radha, so he'll reopen this bug? It will be a crying shame if this bug makes it into Mozilla 1.0.

claudius, can you give it a try? Thanks

I've set up a step by step testcase for this that fails for me on a latest build (it is on OS/2 though) http://www.kaply.com/work/main.html Can someone else verify that this is broke or fixed on a current build?

mkaply, I see the problem in the url you have provided. Shall take a look. But I don't see the problem as described in java.sun.com

Re-openeing based on the previous comment.

One more thing that might or might not be related. If you set www.kaply.com/work.html as your homepage and run through the testcase, the back button actually never becomes enabled. After step 1, you can use Alt+left arrow to go back, but you can't actually click the back button. Once you hit the failure nothing works.

Argh. Sorry. the new page - http://www.kaply.com/work/main.html as your homepage

The back button not enabled is the bug 56062.

mkaply, When a frameset page is the first page to load in any window, the back/forward buttons don't get enabled. This is addressed in bug 56062. In this situation, however, the Go menu will have the proper entries for the frameset traversals and you can go back or forward using the Go menu. Still the back not working after the last step in your example is a bug and I'll take a look at that.

After Step 3, in the above url, DocShell wasn't saving the SH Entry for the anchor traversal in OSHE, which is crucial for later frameset navigations. The attached patch takes care of that

sr=blizzard

r=adamlock@netscape.com Radha, can you rename LSHE and OSHE for your next session history patch? They should at least start with an 'm' because they are member variables and preferably more descriptive names too.

Fix checked in.

It seems to be working fine now (Linux 2001050318). Great!

VERIFIED Fixed with every testcase listed in this bug. 2001060704 builds

Heh, probably it isn't FIXED completely. Try this: Load the URL specified in this bug and then click links on it this way: 1. Click here to display a page on right side 2. Click here to scroll the window Twice (IMPORTANT) Click here fo go to the top (it doesn't bring you to the top because there isn't any anchor with #top) 3. Click here to load another page And the back button doesn't function. :-( You can replace the step with Twice Click here fo go to the top with scroll upwards and 2. Click here to scroll the window. It is important to click twice on the same anchor. Tested with Linux nightly 2001061221, please reopen.

Re-verified Tom Mraz last comment with double click issue. Back doesn't work.

Actually it's fixed now by Radha's patch to bug 86330. Marking fixed (Linux 2001070821), please reopen if you test it with latest trunk build and it's still there.

Verified Linux 2001090608