really dumb error but it's stumped me

J

Joe Nine

I had a big page and I was getting an error. To make it easier to show
here and recreate I trimmed and trimmed until there was almost nothing
left but the error remains.

On IE8 and Opera 10 I get no errors. On Firefox 3.5, Safari 4 and Chrome
4 I get a different error on each. Here's the entire html page. As
you'll see I've removed tags and attributes that weren't relevant to the
problem so it's an absolute bare minimum.

<html>
<body>
<script>
document.write("<scr"+"ipt src=''><\/scr"+"ipt>");
</script>
</body>
</html>

Earlier it had a head section, the script tags had type on them and
there was a src URL for the script but none of that had anything to do
with the error so I left it out.

On XP/Firefox 3.5 I get: "invalid XML tag syntax" with an error pointing
to the first plus symbol.

On XP/Safari 4 I get: "Syntax Error: Parse Error"

On XP/Chrome 4 I get: "Uncaught SyntaxError: Unexpected token <"

In an earlier version, I had an extra line of code before the
document.write:

var abc;if(true){abc=true;}

When that's in (and remember that's trimmed and trimmed from what it
originally was, which wasn't just if(true)) instead of the errors
mentioned, I get a different error in Firefox. Instead I get "missing }
in XML expression" with an arrow pointing to the semi-colon after abc=true
 
S

Scott Sauyet

<html>
<body>
<script>
document.write("<scr"+"ipt src=''><\/scr"+"ipt>");
</script>
</body>
</html>
Click to expand...

I think the error is because of the empty src attribute in the
generated SCRIPT element.

It's requesting the current document as the source of the script
element, and when it finds HTML instead of Javascript, it chokes. If
you said "src='abc'" does the error disappear?
 
J

Joe Nine

Scott said:
I think the error is because of the empty src attribute in the
generated SCRIPT element.

It's requesting the current document as the source of the script
element, and when it finds HTML instead of Javascript, it chokes. If
you said "src='abc'" does the error disappear?
Click to expand...

No, the error was there also when I was loading a real file. But I have
to say, the file it was loading did itself also do a document.write of a
n empty script tag. The error wasn't inside the JS file though, it was
still in the parent page. Before I'd trimmed the JS file down to being
just a document.write of an empty script tag, it was trying to load a JS
file that was getting a 404. Perhaps that was the problem. Anytime you
load either a blank src, or a src that results in a 404, the parent page
exhibits a weird XML or parse error in 3 out of the top 5 browsers.
 
S

Scott Sauyet

Joe said:
Scott said:
Joe Nine wrote:
[ ... ]
document.write("<scr"+"ipt src=''><\/scr"+"ipt>");
[ ... ]
Click to expand...
Click to expand...
I think the error is because of the empty src attribute in the
generated SCRIPT element.
Click to expand...
It's requesting the current document as the source of the script
element, and when it finds HTML instead of Javascript, it chokes.  If
you said "src='abc'" does the error disappear?
Click to expand...

No, the error was there also when I was loading a real file. But I have
to say, the file it was loading did itself also do a document.write of a
n empty script tag. The error wasn't inside the JS file though, it was
still in the parent page.
Click to expand...

Don't count on the error location being reported properly when scripts
are including other scripts...
Before I'd trimmed the JS file down to being
just a document.write of an empty script tag, it was trying to load a JS
file that was getting a 404. Perhaps that was the problem. Anytime you
load either a blank src, or a src that results in a 404, the parent page
exhibits a weird XML or parse error in 3 out of the top 5 browsers.
Click to expand...

I don't think a 404 would be an issue. The issue is when the page
referenced is not proper JS. If you use a blank "src" attribute, then
it's requesting the current HTML file for the JS. That will certainly
cause problems. If you requested "myDoc.html", it would probably also
cause problems (assuming that file included HTML.)

-- Scott
 
T

Thomas 'PointedEars' Lahn

Joe said:
<script>
document.write("<scr"+"ipt src=''><\/scr"+"ipt>");
Click to expand...

You do not need to separate the start and end tag of the element,
respectively. What matters is that the `</' in the end tag is escaped.
Otherwise, by SGML parsing rules, it delimits the content of the script
element prematurely. (This has been discussed here ad nauseam, and is
also pointed out by the W3C Validator when it encounters `</' there.)

Therefore, you can use double quotes for attributes in dynamically generated
markup, too (makes it easier to make static markup dynamic and vice-versa):

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

Not that loading a script like this would be a good idea to begin with.
Earlier it had a head section, the script tags had type on them and
Click to expand...

It not logical to assume that introducing errors would remove other errors.
The `type' attribute is #REQUIRED. Furthermore, but this is not an error,
a `script' element in the `body' element may work differently than in the
`head' element, depending on the script code thus executed.


PointedEars
 
J

Joe Nine

Scott said:
I don't think a 404 would be an issue. The issue is when the page
referenced is not proper JS. If you use a blank "src" attribute, then
it's requesting the current HTML file for the JS. That will certainly
cause problems. If you requested "myDoc.html", it would probably also
cause problems (assuming that file included HTML.)

-- Scott
Click to expand...

Thanks Scott (and Thomas in his reply). I hadn't realized (and find it
quite strange) that creating a tag with a blank src attribute would
request the current HTML file for the JS. How unusual, but at least it
explains it, especially when I think now of the original larger page.

It was loading a JS file, the name of which was in a variable. I was
allowing the variable to have a blank name thinking it wouldn't do any
harm, as I expected document.write'ing a script tag with no src would
simply create a script element that had nothing in it (no harm no foul).
Clearly that's wrong. I won't be doing that again.

This place is great. I doubt the answer to this particular peculiarity
is documented anywhere on the web.
 
T

Thomas 'PointedEars' Lahn

Joe said:
Scott said:
I don't think a 404 would be an issue. The issue is when the page
referenced is not proper JS. If you use a blank "src" attribute, then
it's requesting the current HTML file for the JS. That will certainly
cause problems. If you requested "myDoc.html", it would probably also
cause problems (assuming that file included HTML.)
Click to expand...

Thanks Scott (and Thomas in his reply). I hadn't realized (and find it
quite strange) that creating a tag with a blank src attribute would
request the current HTML file for the JS. How unusual, [...]
Click to expand...

Only to the uninitiated, I am afraid. The value of the `src' attribute of
SCRIPT elements is specified to be of type URIâ½Â¹â¾, that is, a URI or URI-
reference as specified in RFC 3986â½Â²â¾ (which obsoletes RFC 2396, which
updates RFC 1738, which is therefore referred in the HTML 4.01
Specificationâ½Â³â¾).

An empty URI-reference is specified to be a same-document URI-reference.â½â´â¾
You can find that, for example, with the `action' attribute of FORM
elements, too, primarily if the document is dynamically generated by a
server-side application (like PHP).â½âµâ¾

You're welcome :)


Regards,

PointedEars
___________
â½Â¹â¾ <http://www.w3.org/TR/REC-html40/interact/scripts.html#h-18.2.1>
â½Â²â¾ <http://tools.ietf.org/html/rfc3986>
â½Â³â¾ <http://www.w3.org/TR/REC-html40/types.html#type-uri>
â½â´â¾ <http://tools.ietf.org/html/rfc3986#section-4.4>
â½âµâ¾ <http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.3>
 
D

David Mark

Joe said:
Scott said:
Joe Nine wrote:
[ ... ]
document.write("<scr"+"ipt src=''><\/scr"+"ipt>");
[ ... ]
I think the error is because of the empty src attribute in the
generated SCRIPT element.
It's requesting the current document as the source of the script
element, and when it finds HTML instead of Javascript, it chokes.  If
you said "src='abc'" does the error disappear?
Click to expand...
Click to expand...
No, the error was there also when I was loading a real file. But I have
to say, the file it was loading did itself also do a document.write of a
n empty script tag. The error wasn't inside the JS file though, it was
still in the parent page.
Click to expand...

Don't count on the error location being reported properly when scripts
are including other scripts...
Before I'd trimmed the JS file down to being
just a document.write of an empty script tag, it was trying to load a JS
file that was getting a 404. Perhaps that was the problem. Anytime you
load either a blank src, or a src that results in a 404, the parent page
exhibits a weird XML or parse error in 3 out of the top 5 browsers.
Click to expand...

I don't think a 404 would be an issue.
Click to expand...

A missing script will be problem if the server sends an error page.
 
J

Joe Nine

Thomas said:
Joe said:
Scott Sauyet wrote:
Thanks Scott (and Thomas in his reply). I hadn't realized (and find it
quite strange) that creating a tag with a blank src attribute would
request the current HTML file for the JS. How unusual, [...]
Click to expand...

Only to the uninitiated, I am afraid. The value of the `src' attribute of
SCRIPT elements is specified to be of type URIâ½Â¹â¾, that is, a URI or URI-
reference as specified in RFC 3986â½Â²â¾ (which obsoletes RFC 2396, which
updates RFC 1738, which is therefore referred in the HTML 4.01
Specificationâ½Â³â¾).

An empty URI-reference is specified to be a same-document URI-reference.â½â´â¾
You can find that, for example, with the `action' attribute of FORM
elements, too, primarily if the document is dynamically generated by a
server-side application (like PHP).â½âµâ¾

You're welcome :)

Regards,

PointedEars
Click to expand...

Wouldn't the same logic apply to an IMG tag with src="" that's being
written using document.write? As far as can be observed, it doesn't seem
to suffer from the same behavior and simply sits there waiting for
someone to come along and set it's src attribute.
 
T

Thomas 'PointedEars' Lahn

Joe said:
Wouldn't the same logic apply to an IMG tag with src="" that's being
written using document.write?
Click to expand...

IMG _element_: Yes, it would.
As far as can be observed, it doesn't seem to suffer from the same
behavior and simply sits there waiting for someone to come along and
set it's src attribute.
Click to expand...

Do not rely on that; a user agent may prune pointless requests, but it does
not need to. Do not use empty URI-references anywhere unless you mean it.


PointedEars
 
J

Joe Nine

Richard said:
Joe said:
Thomas said:
Joe Nine wrote:
Scott Sauyet wrote:
Thanks Scott (and Thomas in his reply). I hadn't realized (and
find it quite strange) that creating a tag with a blank src
attribute would request the current HTML file for the JS. How
unusual, [...]

Only to the uninitiated, I am afraid. The value of the `src'
attribute of SCRIPT elements is specified to be of type
URIâ½Â¹â¾, that is, a URI or URI- reference as specified in RFC
3986â½Â²â¾ (which obsoletes RFC 2396, which updates RFC 1738,
which is therefore referred in the HTML 4.01 Specificationâ½Â³â¾).

An empty URI-reference is specified to be a same-document
URI-reference.â½â´â¾ You can find that, for example, with the
`action' attribute of FORM elements, too, primarily if the
Click to expand...
document is dynamically generated by a server-side application
(like PHP).â½âµâ¾

You're welcome :)
Click to expand...
snip>
Wouldn't the same logic apply to an IMG tag with src="" that's
being written using document.write? As far as can be observed,
it doesn't seem to suffer from the same behavior and simply
sits there waiting for someone to come along and set it's src
attribute.
Click to expand...

What evidence do you have that an IMG element in an HTML document with
an empty SRC URL does not 'load' that HTML document into itself?
Specifically, do you have any evidence that this IMG element behaves any
differently from a similar IMG element that has its SRC element
explicitly set to refer to an HTML document.
Click to expand...


No evidence, only the lack of any observed misbehavior or warnings in
the error console.
Historically IMG elements have been exploited for their ability to
request arbitrary resources from a server and 'sink' any non-image
results they happen to be sent. An IMG directed at an HTML source can be
expected to go through the HTTP process (which will involve a request to
the server is caching does not interfere) and download the servers
response, but as the result would not be interpretable as an image the
visible behaviour would be as if nothing has been downloaded.

Richard.
Click to expand...

Well that would explain the lack of warning. Personally, I'd issue a
warning in the console that a non-image failed to load into the IMG element.
 
J

Joe Nine

Thomas said:
IMG _element_: Yes, it would.


Do not rely on that; a user agent may prune pointless requests, but it does
not need to. Do not use empty URI-references anywhere unless you mean it.

PointedEars
Click to expand...

There is a case where I deliberately create an iframe element with a
blank src and it doesn't [appear to] load the html into it. If it did,
then it would recurse ad-infinitum. A chain of iframe turtles all the
way down.
 
R

Richard Cornford

No evidence, only the lack of any observed misbehavior or
warnings in the error console.
Click to expand...

What would be misbehaviour? An element that exists to display images
displaying nothing when presented with data that cannot (and should
not, because of its Content-Type header) be interpreted as an image is
quite reasonable behaviour.
Well that would explain the lack of warning. Personally, I'd
issue a warning in the console that a non-image failed to
load into the IMG element.
Click to expand...

And get a warning every time an image failed to load for any other
reason?

Richard.
 
T

Thomas 'PointedEars' Lahn

Joe said:
Thomas said:
IMG _element_: Yes, it would.


Do not rely on that; a user agent may prune pointless requests, but it
does not need to. Do not use empty URI-references anywhere unless you
mean it.
Click to expand...

There is a case where I deliberately create an iframe element with a
blank src and it doesn't [appear to] load the html into it. If it did,
then it would recurse ad-infinitum. A chain of iframe turtles all the
way down.
Click to expand...

You realize, of course, that this a case as I described, where it makes a
lot of sense for a UA to prune the HTTP request. Still you should not rely
on that the iframe stays blank, then. So, again, do not do this.


PointedEars
 
J

Joe Nine

Thomas said:
Joe said:
Thomas said:
Joe Nine wrote:
Thomas 'PointedEars' Lahn wrote:
An empty URI-reference is specified to be a same-document
URI-reference.â½â´â¾ You can find that, for example, with the `action'
attribute of FORM elements, too, primarily if the document is
dynamically generated by a server-side application (like PHP).â½âµâ¾
Wouldn't the same logic apply to an IMG tag with src="" that's being
written using document.write?
IMG _element_: Yes, it would.

As far as can be observed, it doesn't seem to suffer from the same
behavior and simply sits there waiting for someone to come along and
set it's src attribute.
Do not rely on that; a user agent may prune pointless requests, but it
does not need to. Do not use empty URI-references anywhere unless you
mean it.
Click to expand...
There is a case where I deliberately create an iframe element with a
blank src and it doesn't [appear to] load the html into it. If it did,
then it would recurse ad-infinitum. A chain of iframe turtles all the
way down.
Click to expand...

You realize, of course, that this a case as I described, where it makes a
lot of sense for a UA to prune the HTTP request. Still you should not rely
on that the iframe stays blank, then. So, again, do not do this.

PointedEars
Click to expand...

Unfortunately I need to do this because of this 5 year old Firefox bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=279048
The known workaround is to avoid putting your desired URL into the src
attribute when creating the iframe tag via document.write. Instead,
leave it blank, and then set it after the iframe is created. Doing this
works around the bug.
 
R

Richard Cornford

Thomas 'PointedEars' Lahn wrote:


Unfortunately I need to do this because of this 5 year old Firefox
bug:https://bugzilla.mozilla.org/show_bug.cgi?id=279048
The known workaround is to avoid putting your desired URL into the
src attribute when creating the iframe tag via document.write.
Instead, leave it blank, and then set it after the iframe is created.
Doing this works around the bug.
Click to expand...

For IFRAMEs (and windows opened with - window.open) the result of an
empty URL is usually the "about:blank" URL (if that is the right name
for it), and given that there is no need to specify the SRC as empty
because "about:blank" can be used in its place.

Richard.
 
T

Thomas 'PointedEars' Lahn

Joe said:
Thomas said:
Joe said:
There is a case where I deliberately create an iframe element with a
blank src and it doesn't [appear to] load the html into it. If it did,
then it would recurse ad-infinitum. A chain of iframe turtles all the
way down.
Click to expand...

You realize, of course, that this a case as I described, where it makes a
lot of sense for a UA to prune the HTTP request. Still you should not
rely on that the iframe stays blank, then. So, again, do not do this.
Click to expand...

Unfortunately I need to do this because of this 5 year old Firefox bug:
Click to expand...

No, you don't. You have every freedom to use a proper default value.


PointedEars
 
T

Thomas 'PointedEars' Lahn

Says who? The `src' attribute of the element is #IMPLIED. Avoiding the
desired URL does not imply specifying the attribute with a zero-length
value. I do not see the workaround you propose mentioned in the bug
discussion, and I think you have misunderstood the bug.

I doubt it. If there was a workaround, this bug would not have status NEW.
For IFRAMEs (and windows opened with - window.open) the result of an
empty URL is usually the "about:blank" URL (if that is the right name
for it), and given that there is no need to specify the SRC as empty
because "about:blank" can be used in its place.
Click to expand...

It would appear to be better to refer to a default blank document instead;
`about:blank' is not supposed to be interoperable. Given that this IFRAME
element is being created with scripting, it might be a good idea to use
`javascript:'.

Then again, it is not necessary to specify the `src' attribute for this
element in the first place.


PointedEars
 
J

Joe Nine

Thomas said:
Joe said:
Thomas said:
Joe Nine wrote:
There is a case where I deliberately create an iframe element with a
blank src and it doesn't [appear to] load the html into it. If it did,
then it would recurse ad-infinitum. A chain of iframe turtles all the
way down.
You realize, of course, that this a case as I described, where it makes a
lot of sense for a UA to prune the HTTP request. Still you should not
rely on that the iframe stays blank, then. So, again, do not do this.
Click to expand...
Unfortunately I need to do this because of this 5 year old Firefox bug:
Click to expand...

No, you don't. You have every freedom to use a proper default value.

PointedEars
Click to expand...

I'd like to use a default value I really would, but the html page that
I'm loading into the iframe wants to be fully reloaded each time the
browser is refreshed, like it deserves to be. It's an entire html page
and should be treated with respect and get fully reloaded. Firefox
doesn't treat it like that though, it doesn't fully reload the iframe.

The simplest example of how to recreate this problem is to load a html
page that (itself) makes a 50/50 random decision on whether to show one
thing or another. On all browsers except Firefox, as you keep hitting
refresh (e.g. F5) then you'll see the iframe making a 50/50 choice. If
you perform that test on Firefox, you'll see that whatever the initial
50/50 choice is, that's what it will display on every single refresh.
Only a hard refresh (e.g. Ctrl-F5) will force it to bring up a new 50/50
choice and subsequent soft refreshes will repeatedly show that choice.

If an iframe is meant to be a fully-privileged html container in it's
own right, then it deserves to be re-constructed and re-parsed
completely on a refresh.
 
T

Thomas 'PointedEars' Lahn

Joe said:
Thomas said:
Joe said:
Thomas 'PointedEars' Lahn wrote:
Joe Nine wrote:
There is a case where I deliberately create an iframe element with a
blank src and it doesn't [appear to] load the html into it. If it did,
then it would recurse ad-infinitum. A chain of iframe turtles all the
way down.
You realize, of course, that this a case as I described, where it makes
a lot of sense for a UA to prune the HTTP request. Still you should
not rely on that the iframe stays blank, then. So, again, do not do
this.
Unfortunately I need to do this because of this 5 year old Firefox bug:
Click to expand...
No, you don't. You have every freedom to use a proper default value.
Click to expand...

I'd like to use a default value I really would, but the html page that
I'm loading into the iframe wants to be fully reloaded each time the
browser is refreshed, like it deserves to be. It's an entire html page
and should be treated with respect and get fully reloaded. Firefox
doesn't treat it like that though, it doesn't fully reload the iframe.
Click to expand...

That problem does not appear to exist in "Mozilla/5.0 (X11; U; Linux i686;
en-US; rv:1.9.2.3) Gecko/20100404 Iceweasel/3.6.3 (like Firefox/3.6.3)
GTB7.0" anymore. In any event, I find it unlikely that using a default
empty string is necessary or sufficient to work around this problem.

You should also stop talking about technical entities as if they were
people. It makes you look a bit naive. There is also no `html page', there
is an _HTML_ _document_.

And please stop quoting my signature.


PointedEars
 

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

Similar Threads

I need some help on a format issue that should be simple for someone here (but not me!) 0
Help me sort out this script 1
Safari parse error has me stumped 10
stumped 4
JQuery hover error 3
Old LOCKFILE warning on github repo - I cant run the app locally 1
My boss tells me to work at home 5
How can i pass the csp on this extension? 2

Members online

Total: 39 (members: 1, guests: 38)
Robots: 316

Forum statistics

Threads
473,755
Messages
2,569,536
Members
45,007
Latest member
obedient dusk

Latest Threads

Top