Screen does not update after calling Window.location when the HTML has identical schema

NEW
Unassigned

Status

()

Core
DOM: Core & HTML
P5
minor
17 years ago
19 days ago

People

(Reporter: Dominic Chambers, Unassigned)

Tracking

({pp})

Trunk
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

17 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9) Gecko/20020311
BuildID:    2002031104

If a window that has just loaded is set to a new location (Window.location)
without any timeout period, and if the schema (tags and attribute names) of the
new document is identical to the schema of the existing document, then the new
document will not be rendered.



Reproducible: Always
Steps to Reproduce:
I have a number of test cases that you can use to reproduce this bug. Will
attach later.

1. Create an HTML document with an onload handler that immediately reloads
itself in favour of another document with identical schema.

Actual Results:  The old page was not updated.

Expected Results:  The newly requested page should have been rendered.
(Reporter)

Comment 1

17 years ago
Created attachment 77162 [details]
Reproduction Scripts
Created attachment 79103 [details]
Frameset testcase.  Load this.  Will alert 10 times.
Created attachment 79104 [details]
Frameset testcase. Load this. Will alert 10 times.
Attachment #79103 - Attachment is obsolete: true
I see identical behavior both with local files and with the testcase I attached.
 The file _does_ change, but takes a while to do it (wait for about 5 seconds
after each alert to see this).  Linux build 2002-04-12-21 here.
(Reporter)

Comment 7

17 years ago
I have just rechecked the test on Windows build 2002031104 (0.99) and it never
updates no matter how long I leave it.
Dominic, just checking -- you see that with the testcase I attached to this bug 
as well?
Email from Dominic:

Yes, I used the test case you posted on Bugzilla.
 
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: pp
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs
Is this still an issue in current builds?  I still cannot reproduce this...
Assignee: general → nobody
QA Contact: desale → general
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.