really dumb error but it's stumped me

Discussion in 'Javascript' started by Joe Nine, Jun 2, 2010.

  1. Joe Nine

    Joe Nine Guest

    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
     
    Joe Nine, Jun 2, 2010
    #1
    1. Advertising

  2. Joe Nine

    Scott Sauyet Guest

    On Jun 2, 3:00 pm, Joe Nine <> wrote:
    > <html>
    > <body>
    > <script>
    > document.write("<scr"+"ipt src=''><\/scr"+"ipt>");
    > </script>
    > </body>
    > </html>


    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?

    --
    Scott
     
    Scott Sauyet, Jun 2, 2010
    #2
    1. Advertising

  3. Joe Nine

    Joe Nine Guest

    Scott Sauyet wrote:
    > On Jun 2, 3:00 pm, Joe Nine <> wrote:
    >> <html>
    >> <body>
    >> <script>
    >> document.write("<scr"+"ipt src=''><\/scr"+"ipt>");
    >> </script>
    >> </body>
    >> </html>

    >
    > 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?
    >
    > --
    > Scott


    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.
     
    Joe Nine, Jun 2, 2010
    #3
  4. Joe Nine

    Scott Sauyet Guest

    Joe Nine wrote:
    > Scott Sauyet wrote:
    >> 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?

    >
    > 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.


    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.


    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
     
    Scott Sauyet, Jun 2, 2010
    #4
  5. Joe Nine wrote:

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


    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


    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
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
     
    Thomas 'PointedEars' Lahn, Jun 2, 2010
    #5
  6. Joe Nine

    Joe Nine Guest

    Scott Sauyet wrote:
    > Joe Nine wrote:
    >> Scott Sauyet wrote:
    >>> Joe Nine wrote:

    >> 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.

    >
    > 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


    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.
     
    Joe Nine, Jun 2, 2010
    #6
  7. Joe Nine wrote:

    > Scott Sauyet wrote:
    >> 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.)

    >
    > 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 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>
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
     
    Thomas 'PointedEars' Lahn, Jun 2, 2010
    #7
  8. Joe Nine

    David Mark Guest

    On Jun 2, 3:40 pm, Scott Sauyet <> wrote:
    > Joe Nine wrote:
    > > Scott Sauyet wrote:
    > >> 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?

    >
    > > 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.

    >
    > 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.

    >
    > I don't think a 404 would be an issue.


    A missing script will be problem if the server sends an error page.
     
    David Mark, Jun 2, 2010
    #8
  9. Joe Nine

    Joe Nine Guest

    Thomas 'PointedEars' Lahn wrote:
    > 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 document is dynamically generated by a
    > server-side application (like PHP).â½âµâ¾
    >
    > You're welcome :)
    >
    > Regards,
    >
    > PointedEars


    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.
     
    Joe Nine, Jun 3, 2010
    #9
  10. 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.


    PointedEars
    --
    Use any version of Microsoft Frontpage to create your site.
    (This won't prevent people from viewing your source, but no one
    will want to steal it.)
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
     
    Thomas 'PointedEars' Lahn, Jun 3, 2010
    #10
  11. Joe Nine

    Joe Nine Guest

    Richard Cornford wrote:
    > Joe Nine wrote:
    >> Thomas 'PointedEars' Lahn wrote:
    >>> 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

    >> document is dynamically generated by a server-side application
    >>> (like PHP).â½âµâ¾
    >>>
    >>> You're welcome :)

    >> 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.

    >
    > 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.



    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.


    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.
     
    Joe Nine, Jun 3, 2010
    #11
  12. Joe Nine

    Joe Nine Guest

    Thomas 'PointedEars' Lahn wrote:
    > 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.
    >
    > PointedEars


    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.
     
    Joe Nine, Jun 3, 2010
    #12
  13. On Jun 3, 1:55 pm, Joe Nine wrote:
    > Richard Cornford wrote:
    >> Joe Nine wrote:

    <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.

    >
    >> 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.

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


    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.

    >> 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.

    >
    > 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.


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

    Richard.
     
    Richard Cornford, Jun 3, 2010
    #13
  14. Joe Nine wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> 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.

    >
    > 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.


    PointedEars
    --
    Use any version of Microsoft Frontpage to create your site.
    (This won't prevent people from viewing your source, but no one
    will want to steal it.)
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
     
    Thomas 'PointedEars' Lahn, Jun 3, 2010
    #14
  15. Joe Nine

    Joe Nine Guest

    Thomas 'PointedEars' Lahn wrote:
    > Joe Nine wrote:
    >
    >> Thomas 'PointedEars' Lahn wrote:
    >>> 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.

    >> 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.
    >
    > PointedEars


    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.
     
    Joe Nine, Jun 3, 2010
    #15
  16. On Jun 3, 3:17 pm, Joe Nine wrote:
    > Thomas 'PointedEars' Lahn wrote:

    <snip>
    >> 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

    >
    > 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.


    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.
     
    Richard Cornford, Jun 3, 2010
    #16
  17. Joe Nine wrote:

    > 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:


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


    PointedEars
    --
    Prototype.js was written by people who don't know javascript for people
    who don't know javascript. People who don't know javascript are not
    the best source of advice on designing systems that use javascript.
    -- Richard Cornford, cljs, <f806at$ail$1$>
     
    Thomas 'PointedEars' Lahn, Jun 3, 2010
    #17
  18. Richard Cornford wrote:

    > On Jun 3, 3:17 pm, Joe Nine wrote:
    >> Thomas 'PointedEars' Lahn wrote:
    >>> 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: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.


    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.

    >> Doing this works around 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.


    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
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
     
    Thomas 'PointedEars' Lahn, Jun 3, 2010
    #18
  19. Joe Nine

    Joe Nine Guest

    Thomas 'PointedEars' Lahn wrote:
    > Joe Nine wrote:
    >
    >> 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:

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


    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.
     
    Joe Nine, Jun 3, 2010
    #19
  20. Joe Nine wrote:

    > Thomas 'PointedEars' Lahn wrote:
    >> Joe Nine wrote:
    >>> 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:

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

    >
    > 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.


    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
    --
    Danny Goodman's books are out of date and teach practices that are
    positively harmful for cross-browser scripting.
    -- Richard Cornford, cljs, <cife6q$253$1$> (2004)
     
    Thomas 'PointedEars' Lahn, Jun 3, 2010
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rod
    Replies:
    2
    Views:
    1,376
  2. Replies:
    1
    Views:
    258
    Mark A. Odell
    Jul 16, 2004
  3. middletree

    really stumped by this

    middletree, Jan 18, 2009, in forum: ASP General
    Replies:
    1
    Views:
    112
    Mike Brind
    Jan 18, 2009
  4. Jerry C.
    Replies:
    8
    Views:
    256
    Uri Guttman
    Nov 23, 2003
  5. blnukem

    Really Stumped hour routine

    blnukem, Jan 17, 2004, in forum: Perl Misc
    Replies:
    23
    Views:
    194
    Joe Smith
    Jan 20, 2004
Loading...

Share This Page