Closed Bug 66013 Opened 24 years ago Closed 20 years ago

document.write('<script src=something><\/script>') doesn't always work if <BODY> tag is missing

Categories

(Core :: DOM: HTML Parser, defect)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: oseberg, Assigned: harishd)

References

(
URL
)

Details

Attachments

(6 files)

HTML test case, depends on included "test.js" file
115 bytes, text/html
Details
The "test.js" file needed for the HTML test case
449 bytes, text/plain
Details
Yikes, here is the source of the HTML test case that you need
115 bytes, text/plain
Details
The "test_SIMPLE.js" file
350 bytes, text/plain
Details
Testcase
285 bytes, text/html
Details
breaks even with compliant html in Mozilla0.8.1 & NS6.01
1019 bytes, application/octet-stream
Details 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20010112
BuildID:    2001011204

Javascript code that document.write's javascript code breaks.

Reproducible: Always
Steps to Reproduce:
<script>
rnd=parseInt(Math.random()*1000);
document.write('<script src="test.js?'+rnd+'"><\/script>');
</script>

Actual Results:  The browser did nothing.
(appeard to get lost while trying to parse the page)

Expected Results:  The javascript code contained in, "test.js" should run.

http://rateme.reactor-core.org/broken/website-banners1.html
http://rateme.reactor-core.org/broken/website-banners2.html
http://rateme.reactor-core.org/broken/website-banners3.html

Are all examples that break.
Confirmed
Platform: PC
OS: Windows 98
Mozilla Build: 2001011908

Marking NEW.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Browser, not engine. Based on reporter's theory that Moz is getting 
hung up in the Parser, reassigning to Parser component. 


Steps to reproduce: 

1. Save the following HTML file to a local directory. This is the 
   HTML file I unnecessarily attached above (twice!):

<script>
rnd=parseInt(Math.random()*1000);
document.write('<script src="test.js?'+rnd+'"><\/script>');
</script>


2. In the same directory, save the "test.js" file I attached above 

3. Open the HTML file with Mozilla - it gets hung up. Repainting
   does not occur properly when you move the main window, etc.
Assignee: rogerl → harishd
Component: Javascript Engine → Parser
QA Contact: pschwartau → janc
The summary currently states

        "document.write("<script>.....</script>"); is broken."


However, here is another HTML test to try:

<script>
document.write('<script src="test_SIMPLE.js' + '"><\/script>');
</script>


Here, the included JavaScript file is simpler than "test.js" above. 
Mozilla seems to handle this testcase just fine. I will attach the 
"test_SIMPLE.js" file below - 
This is a duplicate of bug 55560 or bug 18843.


    
    

    
  
Phil, I dont't have a problem with running snap's like:

var rnd=parseInt(Math.random()*1000);
document.write('<script src="test.js?'+rnd+'"><\/script>');

I see two images after running the snap! The first image is the biggest one and
the second one is smaller. So what exactly isn't working or gets broken?

I don't belief this is a dup of those bugs because there the <script> element is
inserted using DOM functions, and this bug is using a javascript function.

Note for reporter: it's better to use quotations for string literals so this
border=1 width=468 height=10 changes into border="1" width="468" height="10"



    
    

    
  
oops pressed to soon. ..and I don't use: <script> but
<script language="JavaScript" type="text/javascript"> instead.

    
    

    
  

      
      
      
      

        Attached file
          
        Testcase
        — 
      

    


  

    
    

    
  
As you can see in the above testcase I'm using this snap:

document.write('<script
src="http://bugzilla.mozilla.org/showattachment.cgi?attach_id=23032?.......

to load the javascript file from attachment 23032 [details]. If this is working, as it
does for me, then I don't know what this is all about!


    
    

    
  
I just looked at the original HTML code. Those HTML documents are invalid as
invalid HTML can ever be! The documents are missing all the basic HTML elements.

<html><head><title></title></head><body></body></html> not to mention a valid
document DTD.

I strongly belief this bug *must* be marked invalid, this is no bug, it's an
human error. And for the reporter, his problems are solved by using valid HTML code.


    
    

    
  
H-J,

This, "invalid" code works in every other browser I can find.
Netscape Communicator 4.72 for Windows
Netscape Communicator 4.61 for Mac
Internet Explorer 5.0 for Windows
Internet Explorer 4.5 for Mac
Netscape Navigator 3.02 for Windows
Netscape Navigator 3.01 for Windows
 &
Opera 5.01 for Windows.

So, if you would like the browser that you are working on to break on
all the websites out there with, "invalid" HTML so that people who know
nothing about HTML who download and try out your browser find that it
doesn't work with alot of pages out there, then go ahead and mark this
bug as invalid.

Maybe you should somehow go out there and force all the people who write,
"invalid" HTML code that works great in every browser but yours to write
valid HTML.

    
    

    
  
I just belief that if developers need to invest there time to much in solving
this kind of 'bugs', then there will be no time left to get serious bugs out of
Mozilla and it never ever gets compliant! 

I feel sorry for you, but you can simply solve this problem by inserting the
missing elements into your HTML document.

    
    

    
  
I know where not living in a perfect world. I'm more eager to have a compliant
browser then a browser supporting old odd behaviors. But here's the story, it
seems that Mozilla needs at least a <body> element. This snap will work, at
least it did for me. Just give it a try, now there's only one line different
compared to *all* that other browsers. I hope you can life with that!

<body>
<script>
rnd=parseInt(Math.random()*1000);
document.write('<script
src="http://www.website-banners.com/cgi-bin/exchange/nph-adcnet.pl?exotico3&0&'+rnd+'"><\/script>');
</script>

    
    

    
  
I'm not sure what the priorities mean.
I mean, is P1 lower or higher priority than P5?

I've now tested:

-----------------------------------
<script>
document.write('<script>document.write("this is a test<br>");<\/script>');
</script>
-----------------------------------
with no <body> and it works fine in Mozilla.
It's just when you do a, "src=" that it doesn't work.

I agree that there are more important things to fix right now than
this, but this should not be marked invalid because eventually this
browser MUST work with all of the pages out there that work with all
of the browsers currently out there.
Summary: document.write("<script>.....</script>"); is broken. → document.write("<script>.....</script>"); does now work without a <body>

    
    

    
  
Priority should be left -- This is the default state for a filed bug reports.
Changing priority can be done by a person assigned to this bug for example. For
this bug that's harishd as you can see. And P1 is higher then P2 and so on.
Crashes for example might be marked P1 by that person. And assigning a value
other then -- might be changed back to it's original state by the assigned person.

Just take some time to travel bugzilla and you will see that Mozilla NEVER will
run on all site's. I belief that like all other browsers Mozilla will have some
problems. But also that all developers are working hard to make it the best
browser ever possible. I also belief that this browser will be as compliant as
it can be. But sometimes developers have to say no, and that's the price we have
to pay for all that new features and cross platform compatibility. Mozilla has
it's own minor and major problems, but still it's the best browser ever!



    
    

    
  
I feel that if a page out there doesn't work with Netscape and does with IE,
then it's OK for it to not work with Mozilla, but we should do everything we
can do make it so that it does work.

Likewise, if a page works with Netscape and doesn't work with IE, then it should
work with Mozilla, but doesn't have to.

Basically if it doesn't work with either Netscape or IE, then people will be
more likely to blame the page than the browser. But, if it works with IE AND
Netscape, it HAS to work in Mozilla. Because regardless of whether it's the
fault of the HTML code or not, people will blame Mozilla.

I know that I would, and do. But, at this point, I feel that it's OK because
Mozilla is still in beta and under development. At least it is still possible
to fix these problems and people know that they're going to have to upgrade
their browser soon anyways.

And I agree. Mozilla should and will be the best browser out there.

Terje

    
  
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.8

    
    

    
  
And there it is :)

    
    

    
  
the html file that I used contains nothing but
<script>
rnd=parseInt(Math.random()*1000);
document.write('<script src="test1.js"><\/script>');
</script>

where test1.js contains document.write("hello there");

And it seems to work. Also, replacing test1.js with test_SIMPLE.js (attachement 
id=23039) seems to work with or without a body! I'm confused now of the what the 
problem actually is. Enlighten me please. Thanx. 

Note: Either way...this does not sound like a high priority bug and therefore 
I'm setting the bug to FUTURE.
Target Milestone: mozilla0.8 → Future

    
    

    
  
Re-summarizing:


The following script works in Mozilla (depends on test.js attached above):

<script>
rnd=parseInt(Math.random()*1000);
document.write('<script src="test.js?'+rnd+'"><\/script>');
</script>
<body>
</body>


If we remove the <body> tags, however, Mozilla hangs. 
NN4.7 works fine on it without the <body> tags:


<script>
rnd=parseInt(Math.random()*1000);
document.write('<script src="test.js?'+rnd+'"><\/script>');
</script>



We experimented with a simpler included JS file ("test_SIMPLE.js").
We found that Mozilla is able to execute this HTML without <body> tags:

<script>
document.write('<script src="test_SIMPLE.js"><\/script>');
</script>



Also, document.write with no "src=" works in Mozilla with no <body> tags:


<script>
document.write('<script>document.write("this is a test<br>");<\/script>');
</script>


So the one case that is not working in Mozilla involves: 

1. omitting <BODY> tags
2. document.write('<script src=test.js><\/script>')
3. where test.js is doing this:


document.write('<p><a 
href="http://www.website-banners.com/cgi-bin/exchange/adcrdst.pl?mox&0&exotico3" 
target="_top"><img 
src="http://www.website-banners.com/exchange/banners0/mox.gif" border=0 
width=468 height=60 alt="Website Banners"></a><br><a 
href="http://www.website-banners.com/cgi-bin/exchange/adcclick.pl?exotico3" 
target="_top"><img 
src="http://www.website-banners.com/exchange/images/network0.gif" border=0 
width=468 height=10></a></p>')



Again, NN4.7 handles this without the <BODY> tags, but Mozilla doesn't.
Summary: document.write("<script>.....</script>"); does now work without a <body> → document.write('<script src=something><\/script>') doesn't always work if <BODY> tag is missing

    
  
OS: Windows NT → All

    
    

    
  
I just tested all of my original examples and then
some on build ID: 2001021304, on Windows 98.
It appears that Mozilla can handle all the cases.

(All my examples can be found here:
http://rateme.reactor-core.org/broken/website-banners.html )


    
  
QA Contact: janc → bsharma

    
    

    
  
updated qa contact.

    
    

    
  
See the file I just uploaded.

If you document.write() a compliant HTML document to another frame, and the 
HTML document contains a SCRIPT tag with a SRC element, not only is the script 
in the external file not parsed (as evidenced by the fact that the onload event 
for the body does not get called in the dynamic document), but the forms 
collection for the document is not populated, even though the page contains a 
form.

If you exclude the SCRIPT tag with the SRC attribute from the document.written 
page, the forms collection is NOT null for that page and everything is hunky-
dorey.

This occurs in NN 6.01 and Mozilla 0.8.1.

    
    

    
  
I just came up with a work-around.  Define your script in another frame, within 
a function, ala

function somescript()
{
   function x()
   {
      alert( "hi" );
   }
}

then use eval() at the top of the document.written frame to simulate "SCRIPT 
SRC=".  Loading of the script will, of course, be synchronous, but this works 
for my needs:

eval( window.top.theotherframe.somescript.toString() );

    
  
QA Contact: bsharma → moied

    
    

    
  
Just in case its useful, the following seems to be related to the issues
discussed here:

Many of the pages at the Coming Attractions website
(http://www.corona.bc.ca/films/mainFramed.html) display with black backgrounds.
 These pages work as expected by showing the default white background in
Internet Explorer.  It may be that possibly invalid HTML (there are no opening
"body" tags) is contributing to this problem so it's okay if this can't be
fixed, but it would be nice.

I'm using: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0rc3) Gecko/20020523

The problem is not always reproducible.  Sometimes a page will show the default
background color as expected (white, in my case), but on refresh will have a
black background instead.  Most of the time the background is black on the first
try.  However, if I refresh the page several times (not scientific, but usually
3 to 6 times) it will eventually load with the expected default (white) background.

I experimented a little bit, and the reason for the black background in Mozilla
appears to be a combination of their not being an opening body tag and the ad
banner code used.  When the pages at this site did display with the default
background they had two banner ads, with the black background their was always
only one.

I copied out the top part of the HTML from one page (up to the first closing
center tag), and added the closing body and html tags.  Then I tried it with the
opening body tag added back in or the "&lt;script ... /SCRIPT&gt;" block
removed. Doing either of those things resulted in their being a white rather
than black background displayed.

    
    

    
  
The original testcases in this bug work for me, and all comments after comment
23 are not about this bug.... Marking worksforme per comment 23 and my testing.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: