After reporting bugs 4117 and 4120 I decided to replace the frameset document that I existed at this URL. In doing so I decided to implement a Javascript command to weed out browser version since Netscape 4 and IE 3 and below cannot read the normal document correctly. Anyhow, IE5 is always redirected, NS 4.51 most of the time. But Aprunner and Viewer (21 Mar 99) load one version of the page, then switch to the other version and just keep doin this until they crash. NS 4.51 sometimes does this too, but most of the time it seems to work. I am no Javascript expert, this is the first time I used it. Thanks Kevin Berkheiser

Added Summary and forwarded to DOM groupl

The problem originates from the <META HTTP-EQUIV="Refresh"...> tag in the document. I presume it exists for compatibility with NOSCRIPT browsers. The error occurs for two reasons: 1) The CONTENT attribute is malformed. I believe it should be "2; URL=http://members.tripod.com/KBerk/oldhtml.htm" (note the missing "URL="). In the case of a malformed HTTP refresh header, we seem to be setting the refresh URL to that of the containing page, which seems like a losing proposition from the start. Gagan, this should be changed in netlib. 2) When we load the new page as a result of the window.location.replace, we're not destroying the refresh timer. As a result, the new page starts to load, but the refresh timer eventually fires and reloads the index page. Nisheeth or Rick, this needs to change.

Accepting bug...

Setting milestone to M4...

FYI: The timer is not stopped or reset when the stop button is pressed either. This timer problem also existed in Navigator 4.51. It should be noted that I fixed the URL= issue but that had not effect. It does not sound like this is a JavaScript problem to me anymore. But I will not change the component.

Moving bug to M5...

Setting component to Embedding APIs for now. Once I've checked in the fix to the webshell for deleting the refresh timers when a new document is created, I'll set the component to Networking and assign this bug to Gagan.

Moving bugs of lower priority to M6...

Moving non-crashing layout and webshell component bugs to M8... I already have enough blockers and crashers for M6. If I fix them in time for M6, I'll move some of these bugs back to the M6 milestone. I'm keeping the M7 milestone for fixing XML bugs.

I got tired of getting the wrong page with Netscape 4.51 every time I brought up my home page. So, I changed the original page (http://members.tripod.com/KBerk/index.html) to use Netscape's ultimate Sniffer and took out the Refresh stuff. Non Javascript browsers may have problems now, but at least I won't. Anyhow, the old file that this bug applies to has been renamed 4128.htm (http://members.tripod.com/KBerk/4128.htm). I will keep the file here until the bug has been resolved. Oh, the tree is closed for M6 as I write this. FYI: The bug still exists.

I attached the original HTML as a test case. To insure a patch fixes the problem, do the following: 1. Browse the attached file or the original URL. 2. Javascript will redirect you to a different page. 3. If the new page stays up for 10 seconds, you fixed the problem. If the REFRESH timer kicks in and redirects the page again, then the problem still exists.

Renaming this from REFRESH URL problems to somthing more descriptive.

window.location.replace ends up calling nsWebShell::DoLoadURL() which does reset the refresh timers. The problem here is that when the HTML content sink notifies netlib of the <META HTTP-EQUIV="Refresh"...> tag, netlib sets the refresh timer on the webshell asynchronously via the callback FE_SetRefreshURLTimer(). This callback occurs *after* the window.location.replace has executed and the refresh timers have been cancelled. So, the timer gets set on the new document rather than on the old one. Once Necko lands, we should make it set refresh timers synchronously. Warren, Gagan, and Rick? Updating summary to reflect the dependency on Necko and setting target milestone to M9.

Moving bugs blocked by Necko to M10...

Judson has taken upon him the great task of getting META refreshes to work correctly... Looks like we may have this fixed by M9. cc'ing him.

I still need to parse out the url content. the continuous refresh problem should be gone, but we don't refresh to the specified url yet.

fix checked in 7/4/99 around 6:00pm pac time

Marking verified.