[whatwg] script-related feedback

[Ian Hickson]

On Thu, 21 Aug 2008, Jonas Sicking wrote:
> 
> Here is the list of elements that we *don't* execute scripts inside of 
> in firefox:
> 
> http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsScriptElement.cpp#148
> 
> i.e. <iframe>, <noframes>, <noembed>
> 
> Everywhere else we do execute the script.
> 
> The reason these elements ended up at the list is in bugs 
> https://bugzilla.mozilla.org/show_bug.cgi?id=5847 
> https://bugzilla.mozilla.org/show_bug.cgi?id=26669

On Thu, 21 Aug 2008, João Eiras wrote:
> 
> I kind of agree with iframe and noembed, but noframes ? noframes, IMO, 
> it fairly legitimate, because you can have scripts providing fallback, 
> or redirecting to another page.

On Thu, 21 Aug 2008, Jonas Sicking wrote:
> 
> Yes, we would presumably run scripts in <noframes> if we didn't have 
> frame support. There is even a comment in the code that says that we 
> should not check for noscript if we ever add the ability to turn off 
> frame support.

On Fri, 22 Aug 2008, Simon Pieters wrote:
> 
> iframe, noframes and noembed are parsed as CDATA elements
> 
> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0D%0A%3Ciframe%3E%3Cscript%3Ealert(1)%3C%2Fscript%3E%3C%2Fiframe%3E
> 
> so there can't be any script elements as children of those in text/html. 
> In Opera and WebKit, the script executes in
> 
>    data:text/xml,<iframe xmlns='http://www.w3.org/1999/xhtml'><script>alert(1)</script></iframe>
> 
> and it hasn't caused us any problems AFAIK.

On Thu, 21 Aug 2008, Jonas Sicking wrote:
> 
> Looks like firefox doesn't parse the contents of the <iframe> as markup 
> either, but rather treat it as CDATA. Which makes me wonder why we ever 
> look for <iframe>s in the parent chain :)
> 
> I suspect it's just remnants from when things worked differently, the 
> check was put in in 1999 :)
> 
> But the effect is that even in XHTML, like the example you're providing 
> above, scripts in iframes don't execute. This was not intentional though 
> given that this code was put in in 1999, before we had xhtml support.

I have gone with the Safari/Opera behavior here rather than the Mozilla 
behavior. This means you can remove that check altogether, which should 
simplify the code a bit. :-



On Thu, 30 Oct 2008, Keryx Web wrote:
> 
> Webkit based browsers happily tries to parse scripts after the following tags:
> 
>  <script language=javascript1.6">
>  <script language=javascript1.7">
> 
> Even though neither Safari nor Chrome support those JavaScript versions. 
> And it is not a matter of bugs, but lacking implementations.
> 
> No browser runs script specified with:
> 
>  type="text/ecmascript;version=2.0"
>  type="application/ecmascript;version=2.0"
>  type="text/ecmascript;version=3.0"
>  type="application/ecmascript;version=3.0"
> 
> A. Should not the spec mandate that a browser must support a certain 
> version of JavaScript if it tries to run it?

It already does require this (though it is defined the other way around, 
in that the requirement to run the script is only reached if the script 
type is supported).


> B. Should the spec mandate that a browser must run a script that it de 
> facto supports, e.g. ecmascript 3 in Firefox?

I don't understand what this means.



On Fri, 12 Dec 2008, Ojan Vafai wrote:
> >
> > I just went ahead and specced out the 'onbeforeunload' feature that 
> > most browsers support today that handles this case.
> 
> If we're going for matching what browsers do, there's a number of cases 
> (different in each browser) where the confirm doesn't popup. In Chrome, 
> for example, if the beforeunload handler takes too long, we kill it and 
> navigate away. Similarly, in Firefox, if the beforeunload handler hits 
> the limit for script execution and the user stops the script, the 
> beforeunload handler never fires.

I've added a section that allows these behaviors.


> Not sure what the right language for that is. But developers try to do 
> things like using beforeunload/unload to release locks, make server 
> requests, etc. and it's just not a very reliable thing to do in any 
> browser. It's really just useful for the quick prompt for the user as to 
> things like unsaved changes.

I haven't mentioned this in the spec, but I agree that it should be 
mentioned in the authoring guide.


On Fri, 12 Dec 2008, Martin Atkins wrote:
> 
> Could browsers handle confirm() and friends in such a way that they only 
> block the contents of the tab, not the whole browser? In particular, the 
> "close tab" and "close window" features, ideally along with things such 
> as "Back", "Forward" and "Home" should still be available.

It'd have to block any page in the same unit of related browsing contexts, 
but otherwise yes. Chrome does this, mostly. IE8 probably too.


> This does of course create some tricky interactions where onbeforeunload 
> is concerned. If I try to close the browser/tab and the page uses 
> onbeforeunload to create a confirmation prompt, how does this interact 
> with the confirmation prompt only being tab-modal?

The spec now says you can disable scripting at any time, which somewhat 
resolves this.



On Tue, 16 Dec 2008, Calogero Alex Baldacchino wrote:
> 
> First, maybe the less relevant: in the "Script execution contexts" 
> section a request is made for some couple of terms other than 
> "with/without script". OK, let me suggest "scriptable/unscriptable" or 
> "reachable/unreachable by script", for instance. Just a simple hint, no 
> more.

I ended up using "scripting is disabled".


> The former suggests me a possible (partial) solution for the events 
> section question about events handling for non active or "browsing 
> context-less" documents: being script execution not allowed in such 
> situations, we could state that any event exclusively thought for script 
> interaction should never fire, unless any valid motivation arises to let 
> the event fire and be dispatched to the corresponding handler(s), and in 
> such a case the whole mechanism of deciding whether script execution 
> must be allowed or not should be revisited. Otherwise, if any "script 
> related" resources are thought to be kept "alive" in a somewhat "frozen" 
> state (in example, in a previously active document, a connection buffer 
> with last received, not yet elaborated content, the connection itself to 
> be re-established, or its status), then any related event could fire and 
> be frozen in a "pending" state, or just be "frozen" or "pending", 
> meaning in a "before firing state", ready to fire (and be dispatched) as 
> soon as the document enters a scriptable state (i.e. becomes active or 
> gains a browser context).

I've removed the note in question, which actually was resolved recently.


> Furthermore, the "event loop" and "task queue" definitions suggests me 
> that a somewhat user agent could implement a sort of "all-in-one" 
> mechanism to handle together (maybe for an improved interaction?) both 
> implementation-related and script-related events, i.e. queueing together 
> both types of event (or the related tasks), with a somewhat precedence 
> rule between them, or even, in some cases, the very same event/task to 
> be first handled by the underlying implementation, then passed 
> (wrapped?) to the script specific mechanism (for instance, when a 
> document, or an object inside a document, is fully loaded, a native 
> "load" event is generated to increment/complete the document rendering 
> and then it is wrapped and sent to any script related handler). In such 
> a case, the specification could establish, for clearness sake, that only 
> implementation related events must fire, if meaningful for the 
> implementation in a "non-scriptable context" (an inactive or 
> context-less document), while any script related event (even the same 
> wrapped event, after the underlying elaboration) must either be 
> discarded (it does not fire) or be frozen (if applicable) for a further 
> possible resuming. Might such a clarification be helpful for such an 
> (unrealistic? strange? possible?) implementation, in order to avoid or 
> reduce confusion or possible side effects?

I don't understand. Could you provide an example of what you mean? What is 
the problem with the current text, and how does your proposal solve it?


> For the "How do we allow non-JS event handlers?" concern, let me 
> distinguish two different cases:
> 
> 1) an event handler content attribute is set in the markup: Let's assert 
> it must conform to the ECMAScript FunctionBody production rules by 
> default, unless another language is stated elsewhere as the default 
> scripting language for the whole document or for a particular element.
> 
> As for the whole document, a meta tag could be used, such as '<meta 
> http-equiv = "Content-Script-Type" content = 
> "a_valid_scripting_mime_type" />' or the alike. If the declared 
> mime-type is not supported, it could be defaulted to the ECMAScript one.

Yeah, this is the solution HTML4 took. It requires all handlers to be the 
same type, which is suboptimal.


> For the element by itself, an attribute could be added both to the 
> markup and the DOM, either to describe a script language valid for all 
> the script content attributes (i.e. 
> 'defaultscript="appropriate_mime-type"'), or to define a list of valid 
> mime-types (i.e. 'acceptedscripts="first_mimetype;second_mimetype"'). In 
> the latter case, for each parsed script content attribute, the first 
> declared mime-type should constrain the production rules, or be skipped 
> if not supported, using the next mime-type upon failure or after 
> skipping an unsupported one; if all sequentially applied production 
> rules fail, let a SYNTAX_ERR arise (or any other appropriate 
> error/exception); if no mime type is supported, the default script 
> language rules are applied (if not listed, that is, yet tried in the 
> previous step), and if even this fails, let an appropriate 
> error/exception (maybe the SYNTAX_ERR itself) arise. For the sake of a 
> graceful degradation, the script content attribute whose production has 
> failed could be set to the empty string, and any further elaboration 
> continue normally, after the error had been notified to the user, if the 
> case.

This seems quite complicated.


> 2) an event handler attribute and/or an event handler content attribute 
> is set by a script routine:

That case is easy, since the code is already compiled by then, unless a 
string is used, and then we can just use the same mechanism as for the
declarative case.


> [...]

I haven't replied to the remainder of this message, as it seemed more 
speculative than any sort of specific feedback on the spec. Please let me 
know if I missed a specific request to change the spec. In general I 
recommend writing speculative text on your blog. :-)

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'