- From: <bugzilla@jessica.w3.org>
- Date: Tue, 28 Sep 2010 09:54:12 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9767 --- Comment #27 from Henri Sivonen <hsivonen@iki.fi> 2010-09-28 09:54:11 UTC --- (In reply to comment #26) > So basically the proposal is to change this step: > > 8. If the element's Document has an active parser, and the parser's script > nesting level is non-zero, but this script element does not have the > "parser-inserted" flag set, the user agent must set the element's > "ignore-destructive-writes" flag. > > ...to: > > 8. If the element has a "src" attribute, the user agent must set the element's > "ignore-destructive-writes" flag. > > ...? That seems reasonable. (I'll probably simplify how it's specified, if we > do this, but the effect would be the same.) Can you confirm that that is what > you mean? That's not what I mean. I'm not suggesting elements to have an "ignore destructive writes" flag. I'm suggesting that documents have an "ignore destructive writes" counter. Furthermore, I'm not suggesting doing stuff at the time of the "run" algorithm but at the time of script evaluation. Under http://www.whatwg.org/specs/web-apps/current-work/#executing-a-script-block Change step 2 to: If the script is from an external file, increment the "ignore-destructive-writes" counter on the Document of the script element. Let _neutralized doc_ be that Document. Change step 4 to: Decrement the "ignore-destructive-writes" counter of _neutralized doc_ if _neutralized doc_ was defined in the earlier step. Under http://www.whatwg.org/specs/web-apps/current-work/#dom-document-write Change step 2 to: If the insertion point is undefined and the Document has the "ignore-destructive-writes" counter set to a non-zero value, then abort these steps. And then say somewhere that a Document initially has its "ignore-destructive-writes" counter set to zero. The solution described above has worked for multiple Firefox 4 betas. I really don't want to tweak it at this point without a very, very strong reason. -- 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 Tuesday, 28 September 2010 09:54:14 UTC