To repro, On launching browser, visit several pages in sequence (home.netscape.com/ja, home.netscape.com/ko, home.netscape.com/de are tried here) and clik Back button ==> Regardless the previous page loaded, it goes to the very first page (Mozilla home). bld: 11-03-09-M11, Mac 11-03-13-M11, Linux 11-03-09-M11

This is not cache, this is session history. Re-assigning to radha.

I think the problem is in the way, these intl sites are loaded. When I go to home.netscape.com/ja, in the console , I see, FindShortcut: in='http://home.netscape.com/ja' out='null' failed to set the page title. Error loading URL http://home.netscape.com/ja Document: Done (0.771 secs) Error: Can't load: http://home.netscape.com/ja/ (804b0002) Document http://home.netscape.com/ja loaded successfully Document: Done (2.894 secs) Notice the "Error loading URL http://home.netscape.com/ja" message first and then the message "Document http://home.netscape.com/ja loaded successfully". I think this is due to the reload that is done on all pages that has non-ascii charset. Whenever a page fails to load, it is taken out of SH. So, when the first failure code comes thro' from necko, SH will remove home.netscape.com/ja from its cache thereby leaving just your default home page in its cache. This will disable both forward/back buttons. When the second success code comes from necko, SH is already in inconsistent state and thereby gets confused. I would believe that this problem existed ever since I added this "removing unsuccessful page loads from SH" feature which was on 10/5/99. This feature is needed for regular page loads. ftang knows about the relaod problem. cc'ing him. If this broke on a date later than 10/5/99. let meknow. I'll see what regressed.

add rickg and harishd to cc list since they propogate the error code I return from nsMetaCharsetObserver when we hit page w/ charset parameter in META tag. Radha: Where is the place you check the unsuccessful loading ? RickG, is there a way to tell Radha's code that the failure her code got is the one from the meta charset reload and should be ignore ?

Talking to claudius (who talked to radha) it sounds like the comment "...removing unsuccessful page loads from SH feature ... is needed for regular page loads." is wrong - sounds like pages that at least *start* loading but don't completely finish should go into session history. 1) Is that comment correct 2) Is a separate bug needed for that

ftang: The code that checks for unsuccessful loading is in xpfe/browser/src/nsBrowserInstance.cpp::OnEndDocumentLoad(). This is a necko notifications. I don't think there is a way to distinguish a real failure to a failure due to meta charset detection.

paulmac: Please look at bug http://bugzilla.mozilla.org/show_bug.cgi?id=5905 also. I think a page that fails to load s'd be out of SH. I want to make the Back/Forward buttons reflect that too. I'm workign on fixing that.

I agree with that bug. However, if *some* content loads, it should be in session history. This is how 4.x works. You shouldn't have to completely finish loading a page for it to go into SH. But for bad URL's, or down servers, it shouldn't go into SH.

This bug concerns international sites that finish loading completely. The program mistakenly believes that they did not. If this bug is not fixed, many international sites will never be included in history. Many of our international users will lose this feature, perhaps the most basic feature of the product. Does this make sense to anyone?

I discussed this with chofmann and Don Melton. Since the real solution is that the Intl pages should be calling LoadURL once but not twice, and that the intl team is aware of this situation for quite a while, it was decided that the real change in code s'd happen in intl code and not in SH. If I took back the feature that I implemented a month ago, we will be just trading bugs. There is a workaround that the intl team could do. When the first LoadURl() is called, they could pass a PR_FALSE to the aModifyHistory parameter so that the cancelled LoadURL will not get into session History. When the page is loaded again with the Reload(), it will get added to Session History.

reopen this and reassign this to ftang for M12. Won't fix is not a good answer for this bug. This is a must fix for Beta bug. I am willing to take this bug back. Radha, please do not ignore this problem. I can understand you may have problem to fix this by yourself since you don't know what our code is doing. but please don't ignore this bug. .... Ressign this bug to me is acceptable. Mark it as won't fix is not acceptable.

reassign back to myself (ftang).

clearing wontfix resolution

changing QA contact to myself.

I agree with paulmac's comment from 11/05/99 10:48. In 4.x, I frequently will click on a link before the current page completes loading. After the next page loads, I expect Back to go back to the page that did not completely load. If this happens, will the first page not be in the SH? This would be bad. Is there a way to tell if a load FAILED as opposed to did not complete?

Per Bob's comment, see bug 17430 - Radha has spoken with valeski and she will change how SH is updated once the new webshell is implemented. Currently, it is hard to tell when a file has only loaded partially.

related but not dup of 18291

But it seems like a dup of bug 17430. When we catch that the page contains a Meta charset tag (which differs from the current charset), we stop the current load and do a reload. *** This bug has been marked as a duplicate of 17430 ***

17430 is in turn a duplicate of bug 16782. Changing & verifying. *** This bug has been marked as a duplicate of 16782 ***

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

For more explanation, here is an excerpt from my 11/19 comment in bug 16782: When loading a page (w/out HTTP charset attribute), we use a fallback charset and convert to Unicode accordingly. If the parser detects any type of META tag it will use the observer interface to notify any META handlers. If the META charset handler tag specifies a charset which is different from the fallback, the page must be reloaded, so the data can be correctly converted to Unicode.