Closed Bug 16342 Opened 25 years ago Closed 25 years ago

Meta-refresh and JavaScript refresh interfere

Categories

(Core :: DOM: Core & HTML, defect, P3)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: whiplash, Assigned: vidur)

References

(
URL
)

Details

(Keywords: crash) 

I'm running Mozilla M10 under Windows NT 4.0 SP 5.

The page indicated above contains a meta-refresh line redirecting to
http://www.pobox.com/~ds18/v3/index.html, and a JavaScript refresh in a <SCRIPT>
block in the <HEAD> block redirecting to v4/index.html.  Instead of refreshing
to either one or the other, it attempts to redirect to
http://www.pobox.com/~ds18/v3/v4/index.html - I'm not quite sure how it has
built this URL.
Assignee: don → vidur
Component: Browser-General → DOM Level 0
I suspect it got the location by adding to the URL in the META Refresh rather
than adding to the URL of the page.  IMO, if this happens it is clearly a bug,
since the refresh could be a really long time, with a JS interface to redirect
somewhere else before that happens.  (However, if the JS is really slow, then
the refresh could happen first, but it should stop the JS from finishing.)

Changing to DOM Level 0 and reassigning, although it could be Network-related or
something.

This works for me in yesterday's build on Linux (apprunner and viewer).  Could
it be:
 * a timing issue?
 * something that's been fixed already?
 * a platform-parity issue?
I would suspect a timing issue before a platform issue, but I think if that's
the case then Mozilla should probably do what IE4+ and Netscape 3+ appear to do
already:

if there is a javascript document.location command, perform it;
elseif there is a meta-refresh header, perform it;
else stay put.

I can try running Mozilla on a different system and see how it does, but
currently all my operational machines are running some flavour of Windoze.  (My
multiboot machine is having hardware problems.)
I would think if the time on the meta refresh is 0, then it should have
precedence since the page should never really be completely loaded (or should
it?).
Umm... maybe, but that's not how IE and Netscape do it.  This page works fine
under IE4 and later, and NS3 and later (I'm checking for at least NS4, but I
used to use this same method for NS3.)

As I understand it, their processing order has been header (non-function)
JavaScript, then meta-statements, then body JavaScript.  Admittedly, I believe
this is probably an "undocumented feature" but since IE and NS agree it seems
like a bad idea to break it now.
QA Contact: leger → desale
Resetting QA contact from leger.
In an attempt to get my bug list in order again, marking all the bugs I have
currently as ASSIGNED.
We're doing the right thing now. There is a potential timing issue here if the 
META element and the SCRIPT came in as part of different networking chunks. If 
they come in on the same one and are processed successively, the script will win 
out.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Now redirect seems fine, but I tried it with Win-95, 2000-02-14-09 builds, and 
its crashing on load of this page. I'm trying to investigate why its crashing at 
that page, but till that time I'm reopening this bug.
Status: RESOLVED → REOPENED
Keywords: crash
Resolution: FIXED → ---
Actually I investigated this one and after redirection they are having 
<APPLET></APPLET> tag which is causing crash. There is allready a bug# 8290 for 
it. so I'm marking this one fixed. and then verified.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
Verified with 2000-02-14-09.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.