Closed
Bug 84634
Opened 23 years ago
Closed 20 years ago
Mozilla does not finish downloading and displaying the page.
Categories
(Core :: DOM: Core & HTML, defect, P4)
Tracking
()
RESOLVED
DUPLICATE
of bug 114461
People
(Reporter: kd, Unassigned)
References
()
Details
(Keywords: qawanted)
Attachments
(4 files)
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
BuildID: 2001060703
Mozilla seem to download properly the page. Then it is like it gets a refresh
message and only partly draws the page again (the header) and get stuck with
message at the bottom of the Mozilla windows "Resolving host www.mbl.is".
Reproducible: Always
Steps to Reproduce:
1.Start mozilla
2.point it to http://www.mbl.is
3.Observe
Actual Results: Partially rendered page, and mozilla resolving the server.
Expected Results: Fully rendered page.
|
||
Updated•23 years ago
|
Assignee: asa → neeti
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking: HTTP
Ever confirmed: true
QA Contact: doronr → benc
|
|
||
Comment 1•23 years ago
|
||
Confirmed with win32 build 06104 on win2K. over to networking for a look.
I am getting a javascript error
JavaScript error:
http://mbl.teljari.is/kodi.js line 32: s is not defined
Reassigning to Javascript for further triage
Assignee: neeti → rogerl
Component: Networking: HTTP → Javascript Engine
QA Contact: benc → pschwartau
|
||
Comment 3•23 years ago
|
||
|
|
||
Comment 4•23 years ago
|
||
|
|
||
Comment 5•23 years ago
|
||
Here is the essential HTML for the testcase that works properly:
<HEAD>
<SCRIPT language="JavaScript">
var s = 'Hello';
function test()
{
document.write("<script language='javascript'>");
document.write("</" + "script>");
alert(s);
}
test();
</SCRIPT>
</HEAD>
<BODY>
</BODY>
|
|
||
Comment 6•23 years ago
|
||
Here is the essential HTML for the testcase that fails:
<HEAD>
<SCRIPT language="JavaScript">
var s = 'Hello';
function test()
{
document.write("<script language='javascript'>");
document.write("</" + "script>");
alert(s);
}
</SCRIPT>
</HEAD>
<BODY onLoad="test();">
</BODY>
|
|
||
Comment 7•23 years ago
|
||
Comparisons:
IE 4.7 : SUCCEEDS on both tests
NN 4.7 : FAILS on first test, SUCCEEDS on second test
Moz/N6 : FAILS on first test, SUCCEEDS on second test
The only difference between the two tests is that in the second,
the call to the test() function is in-line, whereas in the first,
it is in the onLoad handler of the <BODY> tag.
I think this means this is a issue for the JS embedding, rather
than for the JS Engine. Please reassign back if I am wrong.
I do not quite understand why the variable s should go out of scope
if test() is called from the onLoad handler rather than in-line.
Reassigning to DOM Level 0 in case this is obvious to jst; otherwise,
perhaps it is for the Parser component to analyze?
Assignee: rogerl → jst
Component: Javascript Engine → DOM Level 0
OS: Windows 2000 → All
QA Contact: pschwartau → desale
|
|
||
Comment 8•23 years ago
|
||
The "first" test is attachment id=38122 test() called from <BODY> onLoad
The "second" test is attachment id=38123 test() called in-line from <SCRIPT>
I confused things by pasting the code in the opposite order above.
Also note: both succeed if you remove the document.write('<script ...')
lines from the test() function. Of course, that is the point of this bug:
somehow this can cause the variable s, global to the parent <SCRIPT> block,
to go out of scope, depending on where test() is called from.
|
|
||
Comment 9•23 years ago
|
||
OK, I was all wrong about the importance of the document.write('<script...').
You can replace this in the examples above with document.write('XXXXX'):
<HEAD>
<SCRIPT language="JavaScript">
var s = 'Hello';
function test()
{
var s = 'Hello';
document.write("XXXXX");
alert(s);
}
</SCRIPT>
</HEAD>
<BODY onLoad="test();">
</BODY>
Once again, if we call test() from the onLoad handler, NN4.x and Moz/N6
will give a syntax error 's is not defined'. Apparently ANY document.write()
that occurs AFTER the page is loaded will REPLACE what you had in the HTML
document. So by calling test() from the onLoad handler, we end up erasing
the <SCRIPT> block that defined var s = 'Hello' as a global variable -
|
|
||
Comment 10•23 years ago
|
||
It's a little confusing, because if you define s within the test() function,
as in:
function test()
{
var s = 'Hello';
document.write("XXXXX");
alert(s);
}
then NN4.7, Moz/N6 have no trouble resolving s as 'Hello'.
So the document.write has not erased variables in the local scope.
|
|
||
Comment 11•23 years ago
|
||
OK the 's is not defined' error is not caused by what I thought.
When you get this error in the JavaScript Console:
JavaScript error:
http://mbl.teljari.is/kodi.js line 32: s is not defined
It is NOT caused by any use of an onLoad handler that I have found.
Here is the code at kodi.js:
if(run)
{
ref = escape(document.referrer);
if (ref.length>=252) ref=ref.substring(0,252)+"...";
hours=(new Date()).getTimezoneOffset();
s = screen.width;
v = navigator.appName
if (v != "Netscape") {
c = screen.colorDepth
} else {
c = screen.pixelDepth
}
j = navigator.javaEnabled ()
function prln (n) {
document.write(n,"\n");
}
jv=11;
document.write("<script language=javascript1.2>");
document.write("jv=12;");
document.write("</"+"script>");
document.write("<script language=javascript1.3>");
document.write("jv=13;");
document.write("</"+"script>");
cstring ="&size=" + s + "&colors=" + c + "&referer=" + ref + "&java=" + jv +""
prln("<img" + " border=0 width=1 height=1
src=\"http://mbl.teljari.is/teljari.php?eigandi=" + eigandi
+ "&sida=" + sida + "&hours=" + hours + cstring + "\">")
}
CONCLUSION:
The variable 's' is only defined under the if(run) block.
So whatever script calls kodi.js should set the variable "run".
Otherwise, at the end of kodi.js, when the variable "cstring" is set,
you get the error 's is not defined'.
|
|
||
Comment 12•23 years ago
|
||
|
|
||
Comment 13•23 years ago
|
||
Run the above testcase in Mozilla with the JavaScript Console open.
You get a chance to set "run" to either true or false, via a confirm.
Hit "OK", no problem. But if you hit "Cancel", then "run" does not get set.
You will then see the 's is not defined' error in the JavaScript Console.
|
|
||
Comment 14•23 years ago
|
||
That's as far as I can take the 's is not defined' error.
Here is the structure of the given site, http://www.mbl.is
<frameset framespacing="0" frameborder="0" border="false" rows="98,*">
<frame name="haus"
src="http://www2.mbl.is/frettir-ifx/?MIval=/frettir/haus.html"
scrolling="no" noresize target="main" marginwidth="0" marginheight="0">
<frame name="body"
src="http://www2.mbl.is/cache/forsida.html"
scrolling="auto" marginwidth="0" marginheight="0">
</frameset>
|
|
||
Comment 15•23 years ago
|
||
It is the second frame:
http://www2.mbl.is/cache/forsida.html
that Mozilla is having trouble with. The variable "run" seems
to get set at the bottom of this file before kodi.js is loaded.
This is done as follows:
<!-- Virk vefmæling byrjar -->
<script language="javascript"><!--
var javas=0;
//--></script>
<script language="javascript1.1"><!--
var javas=1;
//--></script>
<script language="javascript"><!--
eigandi = "29"
sida = "Forsidan"
if(javas) {
run = "1"
} else {
document.write("<img
src=http://mbl.teljari.is/teljari.php?eigandi="+eigandi+"&sida="+sida+"&java=10>
");
}
//--></script>
<script language="javascript1.1" src="http://mbl.teljari.is/kodi.js">
</script>
|
||
Comment 16•23 years ago
|
||
Doing document.write() after the document is done loading will do a
document.open() for you, this clears the document and ends up calling
JS_ClearScope() for the window context which will clear all global variables and
methods from the scope, that's why it looks like 's' is not defined in this
case. We can fix this, but it ain't gonna be trivial (we haveto use the
termaination callback in the nsJSContext code)...
|
|
||
Comment 17•23 years ago
|
||
|
|
||
Comment 18•23 years ago
|
||
I cannot explain what is going wrong here, but I have isolated a
single line in forsida.html that toggles the problem. Try the
debugging version of this file attached above in different browsers.
You get a confirm that lets you control whether this single line of HTML
will be document.written or not:
document.write('<link rel=stylesheet href="/css/win-font-fix.css"
type="text/css">');
COMPARE BROWSERS:
IE4.7: It doesn't matter whether you hit OK or Cancel. Page loads very fast.
NN4.7: It doesn't matter whether you hit OK or Cancel. Page loads very slowly.
Moz/N6: It matters: hit Cancel and the page loads successfully (slowly)
hit OK and you see the problem reported in this bug:
> Mozilla seem to download properly the page. Then it is like it gets
> a refresh message and only partly draws the page again
|
|
||
Comment 19•23 years ago
|
||
What I have shown here is that there is no bug in JavaScript Engine
that is causing the problem Moz has with this site. I believe there is
something going wrong with the many document.write's used at the site.
It seems that both the HTML and the JavaScript (e.g. the variable 's')
are getting overwritten by document.write's. That is why the 's' variable,
though it gets successfully set at one point, becomes undefined again.
Somehow it can no longer be resolved because its <SCRIPT> block has been
overwritten.
The HTML also gets overwritten after the first load, which explains the
behavior described by the reporter of this bug:
> Mozilla seem to download properly the page. Then it is like it gets
> a refresh message and only partly draws the page again
Therefore I have to send this to the component responsible for loading
including document.write. Not sure, but guessing this is Parser - ?
At any rate, this is certainly not JS Engine...
Assignee: jst → harishd
Component: DOM Level 0 → Parser
QA Contact: desale → bsharma
|
|
||
Comment 20•23 years ago
|
||
Taking back, this is a DOM problem, trying for mozilla1.0
Assignee: harishd → jst
Component: Parser → DOM Level 0
QA Contact: bsharma → desale
Target Milestone: --- → mozilla1.0
|
|
||
Comment 21•23 years ago
|
||
I have found something interesting using trunk 2001060706 WinNT.
If I bring up Mozilla from scratch and load the page I do NOT
have any problem with the site or my debugging version of forsida.html.
I get NO errors of any kind in the JavaScript Console, and Moz does NOT
try to re-draw the page.
But then if I hit Reload, all the problems reported in this bug occur.
This seems to suggest it's not a theoretical problem we have with the
way the HTML is written, but some sort of practical problem with
how we cache it - ???
|
||
Comment 22•23 years ago
|
||
Note to whoever QAs this in the end: the original site referenced in the 'URL:'
field seems to have been redesigned since this bug was filed, and the bug no
longer occurs. Attachment 38122 [details] still fails, though.
|
|
||
Comment 23•23 years ago
|
||
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1
(you can query for this string to delete spam or retrieve the list of bugs I've
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
|
||
Comment 24•23 years ago
|
||
SEVERITY = LOW [(1)No Crash, (2)performance is getting affected, (3)No Cosmetic
failure]
VISIBILITY = MEDIUM [(1)dont see real website usage that high. (2)Gets one point
of compatibility with other browsers since it works very well on IE.]
PRIORITY = VISIBILITY * SEVERITY
Hence Priority = p4
adding word "qawanted" because I'm setting this priority on available data & if
someone feels otherwise then please investigate this more & feel free to change
this priority.
Keywords: qawanted
Priority: -- → P4
|
||
Comment 25•23 years ago
|
||
dup of bug 114461 (document.open clobbers js context)?
|
|
||
Updated•22 years ago
|
Target Milestone: mozilla1.0.1 → ---
|
||
Comment 27•20 years ago
|
||
*** This bug has been marked as a duplicate of 114461 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•