W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > July 2010

[Bug 9767] Consider ignoring document.write() when IE ignores it if comes from the network task source

From: <bugzilla@jessica.w3.org>
Date: Thu, 15 Jul 2010 11:57:55 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1OZN4d-0006fe-7c@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9767


Henri Sivonen <hsivonen@iki.fi> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




--- Comment #20 from Henri Sivonen <hsivonen@iki.fi>  2010-07-15 11:57:54 ---
(In reply to comment #17)
> The solution in comment 8 seems to make document.write()s in timeouts act
> differently based on whether the parser has finished or not, which seems bad.

How so? What I suggested in comment 8 (and just landed, btw) doesn't change
document.write() behavior from timeouts. With comment 8, a document.write()
from a timeout still blows away the document, always.

> The solution in comment 16 makes the resulting document depend on the network.
> It's bad enough that we let script load order depend on the network, but having
> it change the resulting source document seems excessively bad. It also seems
> like this would still cause the page to go blank in the case of the scripts
> taking longer to load than the page (i.e. nothing seems to prevent the scripts
> from being read after the EOF is consumed). In fact I don't really follow how
> you're preventing the EOF from being consumed at all... surely as soon as you
> know there's an EOF, it's consumed? Are you just appending it at random points
> in the stream (i.e. after whatever you happen to have received from the network
> so far)?

FWIW, I think we shouldn't stuff right before EOF. There's really no point in
having that kind of complexity when the offending scripts are ads or analytics
anyway, so ignoring the writes doesn't degrade the user-perceived browser
behavior at all. Ignoring a write from an analytics script doesn't make end
users reject a browser upgrade, so changing behavior towards sanity should be
safe in terms of market share.

> EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
> satisfied with this response, please change the state of this bug to CLOSED. If
> you have additional information and would like the editor to reconsider, please
> reopen this bug. If you would like to escalate the issue to the full HTML
> Working Group, please add the TrackerRequest keyword to this bug, and suggest
> title and text for the tracker issue; or you may create a tracker issue
> yourself, if you are able to do so. For more details, see this document:
>    http://dev.w3.org/html5/decision-policy/decision-policy.html
> 
> Status: Accepted
> Change Description: see diff given below
> Rationale: The problem is real; I've gone with the solution in comment 10 for
> now.

I'm unhappy with the specced solution. Write-neutralization depends on there
being an active parser, which makes write-neutralization racy with the end of
the parse. I still think we should go with comment 8, which I believe Hixie
misunderstood, given the comment above talking about timeouts when comment 8
had no effect on timeouts.

Comment 8 basically write-neutralizes all external scripts that
 1) Aren't parser-inserted
AND
 2) have the same owner document as the document that write is being called on

This still leaves the implied open() for cases where one document overwrites
another and where an external script overwrites its own document later from an
event handler or timeout (as opposed to triggering write() as a side effect of
the evaluation of the script when the script completes loading).

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Thursday, 15 July 2010 11:57:57 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:30:52 UTC