587931 - Add support for document.currentScript and script-started script-ended events

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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]

Attachment: Patch to fix

Comment 2

[Giorgio Maone [:ma1]]

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]

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]

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)]

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)]

<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]

Attachment: Patch to fix v2

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

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]

Checked in

http://hg.mozilla.org/mozilla-central/rev/406cba753445

Comment 10

[Henri Sivonen (:hsivonen)]

Should I file a follow-up bug about comment 5 or is it by design?

Comment 11

[Alex Vincent [:WeirdAl]]

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]

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]]

No, I can't.

Comment 14

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Attachment: 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]

http://hg.mozilla.org/mozilla-central/rev/6ac2d9151492

Checked in, thanks for the quick review

Comment 16

[Eric Shepherd [:sheppy]]

Is this part of any standard or specification? Just spent 10 minutes Googling around and can't find it in one.

Comment 17

[Eric Shepherd [:sheppy]]

Documented, aside from needing to add info about specifications if any:

https://developer.mozilla.org/en/DOM/document.currentScript
https://developer.mozilla.org/en/DOM/document.onafterscriptexecute
https://developer.mozilla.org/en/DOM/document.onbeforescriptexecute

Listed here as well:

https://developer.mozilla.org/en/Firefox_4_for_developers#Miscellaneous_DOM_changes

and of course:

https://developer.mozilla.org/en/DOM/document

Comment 18

[Henri Sivonen (:hsivonen)]

(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][[e-mail]]]

Uh, did we add non-prefixed events.

Comment 20

[Nickolay_Ponomarev]

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]

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]

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]]

If you want to be even more precise, it's about script elements, not tags.

Comment 24

[Juriy "kangax" Zaytsev]

(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]]

re comment 20: what email to WHATWG is that?

Comment 26

[Nickolay_Ponomarev]

It's in the URL field: http://www.mail-archive.com/[e-mail]/msg23015.html

Comment 27

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

(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)]

Has there been much developer interest in this feature?

Comment 29

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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]]

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]]

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 32

[Eric Shepherd [:sheppy]]

Documentation now complete, with example.

https://developer.mozilla.org/en/DOM/document.currentScript
https://developer.mozilla.org/en/DOM/element.onbeforescriptexecute
https://developer.mozilla.org/en/DOM/element.onafterscriptexecute

Comment 33

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Thanks Sheppy! I added some cross references as well.

Comment 34

[Hixie (not reading bugmail)]

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)]

Also currentScript:
http://html5.org/tools/web-apps-tracker?from=7550&to=7551