Created attachment 585292 [details] [diff] [review] v1 I actually wanted to implement support for EcmaScript Harmony, but as this is not really needed, I decided to attach this patch anyways. The main improvement is that we show a warning if a script hasn't been executed, because the type is unknown.
(In reply to Tom Schuster (evilpie) from comment #1) > The main > improvement is that we show a warning if a script hasn't been executed, > because the type is unknown. Note that HTML5 allows the use of non-JS script types for "data blocks" in the case of inline scripts. This is used e.g. for WebGL shaders. Do we want to warn about those?
Comment on attachment 585292 [details] [diff] [review] v1 I think Henri is right. Warning on unknown script types is not really desirable here....
Created attachment 624387 [details] [diff] [review] just some small cleanup So well ditched that part but kept some cleanup. Bug 738380 removed the way to detect the script type from the root element, but didn't update the commment.
Created attachment 624388 [details] [diff] [review] forgot refresh
Created attachment 624389 [details] [diff] [review] Wow, I am stupid
Comment on attachment 624389 [details] [diff] [review] Wow, I am stupid >+++ b/content/base/src/nsScriptLoader.cpp > // XXX - still hard-coded for JS here, even though another language > // may be specified. Should this check be made *after* we examine > // the attributes to locate the script-type? > // For now though, if JS is disabled we assume every language is > // disabled. This part of the comment can go away, right? >- // XXX is this different from the mDocument->IsScriptEnabled() call? >+ // This should not fail after we succeeded IsScriptEnabled() Which "this"? The old comment was talking about the context->GetScriptsEnabled() call below, though its placement was rather odd. >@@ -620,17 +616,17 @@ nsScriptLoader::ProcessScriptElement(nsI >- "Non-XSLT Defer script on a document without an active parser; bug 592366."); >+ "Non-XSLT Defer script on a document without an active parser; bug 592366.""); There's no way the new code here compiles.
This is not needed anymore.