Re: [whatwg] script element onerror event

[John J. Barton]

On 5/29/2011 5:42 AM, Mike Wilson wrote:

Hi John,

This event is actually already speced, see #14 "fire a simple event
named error at the element" in:
http://www.whatwg.org/specs/web-apps/current-work/#prepare-a-script
(and the onerror attribute is valid for all elements)

Thanks. I stopped before I got that far. Step 12.5:

"Ifeventis not anASCII case-insensitive 
<http://www.whatwg.org/specs/web-apps/current-work/#ascii-case-insensitive>match 
for either the string "|onload|" or the string "|onload()|", then the 
user agent must abort these steps at this point. The script is not 
executed."


Now I see I missed the *and* in the predicate for step 12, "If 
the|script 
<http://www.whatwg.org/specs/web-apps/current-work/#the-script-element>|element 
has an|event 
<http://www.whatwg.org/specs/web-apps/current-work/#attr-script-event>|attribute 
and a|for 
<http://www.whatwg.org/specs/web-apps/current-work/#attr-script-for>|attribute..."


(I've not seen a "for" attribute on a script element. Is there any 
documentation on what it does?)


Step 14 is unclear or incomplete however:
" If the|src 
<http://www.whatwg.org/specs/web-apps/current-work/#attr-script-src>|attribute's 
value is the empty string or if it could not be resolved,..."


Does this mean the error handler will be called in the case of 4XX, 5XX, 
and syntax errors?


jjb


Best regards
Mike Wilson

John J. Barton wrote:

To allow optional JavaScript download, some widely used JavaScript
libraries, such as jQuery and requireJS, use script elements added to
the document dynamically by JavaScript. (Of course this
feature is also
used by applications directly as well).   For normal deployment this
approach works well in practice. At development time however,
or in the
presence of network or server problems, the approach gives poor error
recovery information. Fundamentally the problem is that the insertion
mechanism has no error return path.

The script element does support one event, 'onload' which fires after
the script has finished loading. I suggest the addition of one new
event, 'onerror', which fires in every other case. For examples, a
network error (4XX, 5XX) or JavaScript parse error would
trigger onerror
but not onload.  On the other hand, a runtime error for the
outer-function of the script element would trigger onload (I
guess), but
the developer can handle this with try/catch.

Very long load times would still have poor error recovery
information,
but developers could implement UI to signal "loading..." once
they know
they will get some update event eventually.

jjb

[whatwg] script element onerror event

[John J. Barton]

To allow optional JavaScript download, some widely used JavaScript 
libraries, such as jQuery and requireJS, use script elements added to 
the document dynamically by JavaScript. (Of course this feature is also 
used by applications directly as well).   For normal deployment this 
approach works well in practice. At development time however, or in the 
presence of network or server problems, the approach gives poor error 
recovery information. Fundamentally the problem is that the insertion 
mechanism has no error return path.


The script element does support one event, 'onload' which fires after 
the script has finished loading. I suggest the addition of one new 
event, 'onerror', which fires in every other case. For examples, a 
network error (4XX, 5XX) or JavaScript parse error would trigger onerror 
but not onload.  On the other hand, a runtime error for the 
outer-function of the script element would trigger onload (I guess), but 
the developer can handle this with try/catch.


Very long load times would still have poor error recovery information, 
but developers could implement UI to signal "loading..." once they know 
they will get some update event eventually.


jjb

Re: [whatwg]

[John J. Barton]

 On 8/17/2010 11:52 PM, Jonas Sicking wrote:

On Tue, Aug 17, 2010 at 9:45 PM, John J. Barton
  wrote:

(though I'm not sure which environment is compiled in other than
the global object, which you can't replace anyway, at least not for
now).


Well if I intercept the event and change the source to
   with(browserShim) {
  ... script tag contents here
   }
Then I compile into another environment. Otherwise how can I achieve your
goal?

These events in and of themselves doesn't allow you to modify the
script source. This does seem like a neat idea, if you have ideas for
how this would be done please do suggest them here.

For example,
myWillExecuteHandler = function(event)
{
var elt = event.target;
var adulterate = "with(shim){\n"+elt.innerHTML+"}\n";
eval(adulterate);
return false; // need some way to abort the script tag in progress.
}

This doesn't work for external scripts. I.e. ones with a src attribute.
I think is it appropriate for the proposed event to have a property 
pointing to the source.

What I was thinking was simply allowing the event handler to do things
like:

var oldWrite;
myWillExecuteHandler(event) {
   oldWrite = document.write;
   document.write = myWriteOverride;
}
myDidExecuteHandler(event) {
   document.write = oldWrite;
}

But I guess you don't need events to modify and restore the environment, why
not just put a script before and after:

oldWrite = document.write;
document.write = function(msg) { console.log(msg); }


document.write("I command you!");


document.write = oldWrite;


This doesn't work if the script whose evironment you want to modify is
an asynchronous script. It also is significantly more cumbersome,
Similarly 

Re: [whatwg]

[John J. Barton]

 On 8/17/2010 6:43 PM, Jonas Sicking wrote:

...
[1] http://www.whatwg.org/specs/web-apps/current-work/#executing-a-script-block


Ok so I see where "executing a script block" becomes "executing ".