blee Reporter
	Description • 25 years ago

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

	Paul MacQuiddy
	Comment 1 • 25 years ago

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

	Radha on family leave (not reading bugmail)
	Comment 2 • 25 years ago

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.

	Frank Tang Assignee
	Comment 3 • 25 years ago

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 ?

	Paul MacQuiddy
	Comment 4 • 25 years ago

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

	Radha on family leave (not reading bugmail)
	Comment 5 • 25 years ago

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.

	Radha on family leave (not reading bugmail)
	Comment 6 • 25 years ago

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.

	Paul MacQuiddy
	Comment 7 • 25 years ago

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.

	Allan Masri
	Comment 8 • 25 years ago

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?

	Radha on family leave (not reading bugmail)
	Comment 9 • 25 years ago

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.

	Frank Tang Assignee
	Comment 10 • 25 years ago

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.

	Frank Tang Assignee
	Comment 11 • 25 years ago

reassign back to myself (ftang).

	msanz
	Comment 12 • 25 years ago

clearing wontfix resolution

	blee Reporter
	Comment 13 • 25 years ago

changing QA contact to myself.

	bobj
	Comment 14 • 25 years ago

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?

	Paul MacQuiddy
	Comment 15 • 25 years ago

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.

	Frank Tang Assignee
	Comment 16 • 25 years ago

related but not dup of 18291

	bobj
	Comment 17 • 25 years ago

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 ***

	cpratt
	Comment 18 • 25 years ago

17430 is in turn a duplicate of bug 16782. Changing & verifying.

*** This bug has been marked as a duplicate of 16782 ***

	Radha on family leave (not reading bugmail)
	Comment 19 • 25 years ago

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

	bobj
	Comment 20 • 25 years ago

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.