Last Comment Bug 587931 - Add support for document.currentScript and script-started script-ended events
: Add support for document.currentScript and script-started script-ended events
Status: RESOLVED FIXED
: dev-doc-complete
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: x86 Mac OS X
: -- normal with 1 vote (vote)
: ---
Assigned To: Jonas Sicking (:sicking) No longer reading bugmail consistently
:
:
Mentors:
http://www.mail-archive.com/whatwg@li...
Depends on: 609555
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-16 21:03 PDT by Jonas Sicking (:sicking) No longer reading bugmail consistently
Modified: 2012-12-24 04:05 PST (History)
17 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Patch to fix (3.64 KB, patch)
2010-08-16 21:07 PDT, Jonas Sicking (:sicking) No longer reading bugmail consistently
no flags Details | Diff | Splinter Review
Patch to fix v2 (18.93 KB, patch)
2010-09-16 00:54 PDT, Jonas Sicking (:sicking) No longer reading bugmail consistently
mrbkap: review+
jonas: approval2.0+
Details | Diff | Splinter Review
Don't fire error if script is canceled (2.38 KB, patch)
2010-09-16 17:16 PDT, Jonas Sicking (:sicking) No longer reading bugmail consistently
jonas: review+
jst: approval2.0+
Details | Diff | Splinter Review

Description Jonas Sicking (:sicking) No longer reading bugmail consistently 2010-08-16 21:03:35 PDT
Add support for getting the currently executing <script>.

Also add ability to know when a <script> is about to run and when it has finished running. This makes it possible to modify the world such a script is seeing by setting global properties and overriding DOM methods.
Comment 1 Jonas Sicking (:sicking) No longer reading bugmail consistently 2010-08-16 21:07:22 PDT
Created attachment 466551 [details] [diff] [review]
Patch to fix
Comment 2 Giorgio Maone [:mao] 2010-08-16 23:14:29 PDT
These would be great additions, thanks.

Notice that Opera has a richer set of events of this kind (exposed to "privileged" User Scripts, though, AFAIK), allowing for much more control over the executing scripts, no matter if from script elements, event handlers or URLs:
http://www.opera.com/docs/userjs/specs/#evlistener

I'd really like to see them implemented and, even better, standardized, if possible.
Comment 3 John J. Barton 2010-08-17 12:13:20 PDT
I'd like advice on the appropriate place to discuss this feature. It seems very problematic to me, since their is no such thing as an 'executing <script>'. I think you must have something else in mind.
Comment 4 John J. Barton 2010-08-17 15:26:40 PDT
See also
Bug 531395 - APIs for tracking JavaScript compilation
Bug 449464 - Implement jsdICompilationHook to extend jsd to include information on the compilation unit structure
Comment 5 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-10-03) 2010-08-25 02:33:22 PDT
Is it intentional that during the added events, document.currentScript isn't (by code inspection) the script the events relate to?
Comment 6 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-10-03) 2010-09-01 05:56:00 PDT
<bikeshed>The event names look more like Netscape-internal API names than public Web platform names. I suggest calling the events "beforescript" and "afterscript".</bikeshed>
Comment 7 Jonas Sicking (:sicking) No longer reading bugmail consistently 2010-09-16 00:54:55 PDT
Created attachment 475780 [details] [diff] [review]
Patch to fix v2
Comment 8 Blake Kaplan (:mrbkap) 2010-09-16 01:01:12 PDT
Comment on attachment 475780 [details] [diff] [review]
Patch to fix v2

It seems like we should send onerror instead of onload for the script if we didn't actually run the script. r=me with that fixed & tested.
Comment 9 Jonas Sicking (:sicking) No longer reading bugmail consistently 2010-09-16 02:44:35 PDT
Checked in

http://hg.mozilla.org/mozilla-central/rev/406cba753445
Comment 10 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-10-03) 2010-09-16 07:46:32 PDT
Should I file a follow-up bug about comment 5 or is it by design?
Comment 11 Alex Vincent [:WeirdAl] 2010-09-16 10:39:01 PDT
I think there's a potential problem with this patch:

<script id="evilscript">
document.addEventListener("beforescriptexecute", function(evt) {
  if (evt.target != document.getElementById("evilscript") {
    evt.preventDefault();
    // do something nasty instead
  }
}, true);
</script>
<script name="goodscript">
// Help!  I don't execute!
</script>

Now, what if evilscript was injected into the page (cross-site scripting)...

I know there's been some reworking of script execution order recently, so maybe this isn't a valid concern.
Comment 12 Jonas Sicking (:sicking) No longer reading bugmail consistently 2010-09-16 11:02:26 PDT
If you already have an XSS injection you've already lost. It's like if you've been able to run binary code on a users computer, then that code can prevent and replace attempts to execute other programs.

Can you give a more concrete example of what you are worried that the script could do that it couldn't already do?
Comment 13 Alex Vincent [:WeirdAl] 2010-09-16 11:03:45 PDT
No, I can't.
Comment 14 Jonas Sicking (:sicking) No longer reading bugmail consistently 2010-09-16 17:16:12 PDT
Created attachment 476109 [details] [diff] [review]
Don't fire error if script is canceled

Chatted with blake and concluded that it would in fact be better not to fire an error if a script is canceled. Got r=mrbkap over irl.
Comment 15 Jonas Sicking (:sicking) No longer reading bugmail consistently 2010-09-17 17:31:49 PDT
http://hg.mozilla.org/mozilla-central/rev/6ac2d9151492

Checked in, thanks for the quick review
Comment 16 Eric Shepherd [:sheppy] 2010-11-03 13:25:32 PDT
Is this part of any standard or specification? Just spent 10 minutes Googling around and can't find it in one.
Comment 18 Henri Sivonen (:hsivonen) (Not reading bugmail or doing reviews until 2016-10-03) 2010-11-03 15:27:17 PDT
(In reply to comment #16)
> Is this part of any standard or specification? Just spent 10 minutes Googling
> around and can't find it in one.

It isn't. (It's been proposed on the WHATWG list. That's all.)
Comment 19 Olli Pettay [:smaug] (way behind * queues, especially ni? queue) 2010-11-04 00:39:11 PDT
Uh, did we add non-prefixed events.
Comment 20 Nickolay_Ponomarev 2010-11-05 15:34:07 PDT
This needs more documentation:
-rationale (from Jonas' mail to whatwg),
-details on events (see the tests; seems like the events fire at the <script> element, so it's not really "document.*", the 'before' event can be prevented to cancel script execution),
-the status (experimental non-standard feature, implemented only by Gecko),
-link back to this bug
Comment 21 Nickolay_Ponomarev 2010-11-05 15:39:56 PDT
BTW, Jonas, you didn't answer comments 3 and 5 and these issues should also be clarified in the docs.

I'll try to rephrase comment 3: what happens after the page loaded? What's the 'currently executed script' when JS is running off event handlers? Do the before/after events fire?
Comment 22 John J. Barton 2010-11-06 10:55:13 PDT
Since the feature here is only about <script> tags not JavaScript generally, better names would be:
document.currentScriptTag
document.onafterscripttagexecute
document.onbeforescripttagexecute
Comment 23 [Baboo] 2010-11-06 12:06:33 PDT
If you want to be even more precise, it's about script elements, not tags.
Comment 24 Juriy "kangax" Zaytsev 2010-11-06 12:34:33 PDT
(In reply to comment #22)
> Since the feature here is only about <script> tags not JavaScript generally,
> better names would be:
> document.currentScriptTag
> document.onafterscripttagexecute
> document.onbeforescripttagexecute

Tag is more of a lexical term (and — if we're talking about <script> element — there are *2* of them: "<script>" and "</script>"), so wouldn't it be better to use "element" here?

See also http://perfectionkills.com/tag-is-not-an-element-or-is-it/
Comment 25 Eric Shepherd [:sheppy] 2010-12-23 08:49:35 PST
re comment 20: what email to WHATWG is that?
Comment 26 Nickolay_Ponomarev 2010-12-23 09:28:45 PST
It's in the URL field: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23015.html
Comment 27 Jonas Sicking (:sicking) No longer reading bugmail consistently 2010-12-23 17:13:05 PST
(In reply to comment #20)
> This needs more documentation:
> -rationale (from Jonas' mail to whatwg),
> -link back to this bug

For what it's worth, i'm not sure that these are required in the documentation. But I'll leave that up to Sheppy who has much more experience writing these types of docs.

> -details on events (see the tests; seems like the events fire at the <script>
> element, so it's not really "document.*", the 'before' event can be prevented
> to cancel script execution),

Indeed, they're not really document.on* properties, even though they work there too. Can we simply document them as onbeforescriptexecute/onafterscriptexecute? How do we document things like onclick?

> -the status (experimental non-standard feature, implemented only by Gecko),

Yes, please do include this.

(In reply to comment #3)
> I'd like advice on the appropriate place to discuss this feature. It seems
> very problematic to me, since their is no such thing as an
> 'executing <script>'. I think you must have something else in mind.

I'm fairly sure I've answered this elsewhere. I've never heard this opinion expressed by anyone else. I frequently talk about "executing <script>" both in standards settings and when talking to developers. My impression is that most developers think of <script>s as being executed.

Similarly, I've mentioned elsewhere (on the whatwg list iirc) that events that execute before/after all javascript execution would be a dramatically different feature so should be discussed separately from the features this bug is about.

The WHATWG list is probably the best place to discuss this feature.

(In reply to comment #5)
> Is it intentional that during the added events, document.currentScript isn't
> (by code inspection) the script the events relate to?

Yes. The document.currentScript is set while the <script> element is executed. The event handlers for these events are generally not part of the <script>.

If you want to get at the script element which the events are fired for, use event.target.

(In reply to comment #21)
> I'll try to rephrase comment 3: what happens after the page loaded? What's the
> 'currently executed script' when JS is running off event handlers? Do the
> before/after events fire?

The document.currentScript property is only set as part of the steps for processing <script> elements. This remains true both before and after the document is done loading. So it can be non-null after document loading if a <script> created using the DOM and inserted in a document.
Comment 28 Hixie (not reading bugmail) 2011-01-25 20:07:10 PST
Has there been much developer interest in this feature?
Comment 29 Jonas Sicking (:sicking) No longer reading bugmail consistently 2011-01-26 00:52:14 PST
We haven't really publicized it yet, so I don't think we have good data. Thanks for the ping though, we should reach out and at least let people know it's there.
Comment 30 Eric Shepherd [:sheppy] 2011-02-04 11:30:40 PST
Question: with the testing I'm doing in preparation for finishing up the docs for this, I find that these events only fire when the <script> element is first executed, not when you call back into it from event handlers.  Is this correct behavior? It seems not all that useful to me if these events are only called once...
Comment 31 Eric Shepherd [:sheppy] 2011-02-04 11:48:13 PST
Still working on the examples for this, but the reference documentation has been corrected somewhat, with document.onbeforescriptexecute/onafterscriptexecute moved to element.* where they belong, as well as the pointers to them. Some phrasing fixes have been made as well.

I'll continue to work on the examples.
Comment 33 Jonas Sicking (:sicking) No longer reading bugmail consistently 2011-03-01 10:25:46 PST
Thanks Sheppy! I added some cross references as well.
Comment 34 Hixie (not reading bugmail) 2012-02-03 22:41:12 PST
Spec updated to have beforescriptexecute and afterscriptexecute (though not yet the attribute event handlers):
http://html5.org/tools/web-apps-tracker?from=6963&to=6964
Comment 35 Hixie (not reading bugmail) 2012-11-28 17:34:18 PST
Also currentScript:
http://html5.org/tools/web-apps-tracker?from=7550&to=7551

Note You need to log in before you can comment on or make changes to this bug.