Javascript in dynamically generated window

J

jiverbean

Hi group,

I thought of writing to this group earlier to see my problem fixed,
but I have tried a few techniques, and browsers, and here are my
findings. Comments on other browsers are welcome.

My script generates a new document loaded into a new window based on
the contents of a form. Of the form content, there is a checkbox to
include a javascript generated quote from another site.
So:
var newPage = "<html><body>";
newPage += '<img src="logo.gif">';
if (form.quote.checked) { newPage += '<script type="text/javascript"
src="http://www.brainyquote.com/quote.js"></script>' }
newPage += "</body></html>

create new Window
write to newWindow

I tested the script with Mozilla 2.0.0.4, IE 7, Safari 3.0.2, and
Netscape 9.0b1 on WinXP

Netscape and Mozilla execute the script in the new window, but refuse
to display the rest of the generated page.
Internet Explorer barks on the </script> tag, so I included <script
src=... />, and only Safari executes the script as expected.

The scripted page is available at http://www.aibiver.com/html/start.html

Ta
jiverbean
Luxembourg
 
D

d d

jiverbean said:
var newPage = "<html><body>";
newPage += '<img src="logo.gif">';
if (form.quote.checked) { newPage += '<script type="text/javascript"

I suspect the script tag. It's always a good idea to
break the string up to avoid the script keyword causing
the parser to be fooled into thinking it's already
found the end of the current script block it's executing.

Instead of:

newpage += '<script bla bla bla> some code </script>';

do this:

newpage += '<scr'+'ipt bla bla bla> some code </scr'+'ipt>';

~dd
 
R

RobG

Hi group,

I thought of writing to this group earlier to see my problem fixed,
but I have tried a few techniques, and browsers, and here are my
findings. Comments on other browsers are welcome.

My script generates a new document loaded into a new window based on
the contents of a form. Of the form content, there is a checkbox to
include a javascript generated quote from another site.
So:
var newPage = "<html><body>";
newPage += '<img src="logo.gif">';
if (form.quote.checked) { newPage += '<script type="text/javascript"
src="http://www.brainyquote.com/quote.js"></script>' }

Try:

..."><\/script>' }

The character sequence </ is likely causing the script element to be
closed; quote the forward slash with a backslash.

[...]
Internet Explorer barks on the </script> tag, so I included <script
src=... />, and only Safari executes the script as expected.

That is invalid HTML, you need a closing script tag.
 
R

Richard Cornford

d said:
I suspect the script tag. It's always a good idea to
break the string up to avoid the script keyword causing
the parser to be fooled into thinking it's already
found the end of the current script block it's executing.

Instead of:

newpage += '<script bla bla bla> some code </script>';

do this:

newpage += '<scr'+'ipt bla bla bla> some code </scr'+'ipt>';

The first of these is utterly redundant as there are no issues resulting
form opening script tags appearing inside string literals inside the
contents of script elements. It is pure mystical incantation, propagated
because it does not do any of the manifest harm that might otherwise
have it weeded out of the folklore, by people who are not interested in
understanding why they are doing what they are doing.

The latter is a poor scheme for addressing the issue. It does break up
the problematic closing scrip tag, but it does it at the cost of a
string concatenation operation, and fails to address the formal issue,
and so should not be expected to be 100% successful in all browser
environments.

The alternative proposal of escaping the forward slash in the closing
script element (i.e. '<\/script>') has the advantages of breaking up
both the '</script>', which is the demonstrable cause of the issue, and
the '</' sequence which is formally specified as representing the end of
a CDATA section in HTML (though, rather unexpectedly, not in SGML, where
the specification states that the '</' sequences will all be examined.
but only to see if they are followed by the tag name of the element with
the CDATA content. That is, in SGML only '</script> would be an issue,
while in HTML '</' alone could be. An unusual case where the reality of
web browser is more in tune with SGML than HTML). Escaping the forward
slash achieves this at no runtime expense (in concatenation operations)
as the string literal, with its escape sequence, has been transformed
into the internal sequence of 16 bit Unicode code points by the end of
its tokenisation.

Richard.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top