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

RESOLVED FIXED

Status

()

Core
DOM
RESOLVED FIXED
7 years ago
4 years ago

People

(Reporter: sicking, Assigned: sicking)

Tracking

({dev-doc-complete})

Trunk
x86
Mac OS X
dev-doc-complete
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments, 1 obsolete attachment)

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.
Created attachment 466551 [details] [diff] [review]
Patch to fix
Attachment #466551 - Flags: review?(jst)
Assignee: nobody → jonas

Comment 2

7 years ago
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

7 years ago
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

7 years ago
See also
Bug 531395 - APIs for tracking JavaScript compilation
Bug 449464 - Implement jsdICompilationHook to extend jsd to include information on the compilation unit structure
Is it intentional that during the added events, document.currentScript isn't (by code inspection) the script the events relate to?
<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>
Created attachment 475780 [details] [diff] [review]
Patch to fix v2
Attachment #466551 - Attachment is obsolete: true
Attachment #475780 - Flags: review?(mrbkap)
Attachment #466551 - Flags: review?(jst)
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.
Attachment #475780 - Flags: review?(mrbkap) → review+
Attachment #475780 - Flags: approval2.0+
Checked in

http://hg.mozilla.org/mozilla-central/rev/406cba753445
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Keywords: dev-doc-needed
Should I file a follow-up bug about comment 5 or is it by design?
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.
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?
No, I can't.
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.
Attachment #476109 - Flags: review+
Attachment #476109 - Flags: approval2.0+
Attachment #476109 - Flags: approval2.0+
Attachment #476109 - Flags: approval2.0?

Updated

7 years ago
Attachment #476109 - Flags: approval2.0? → approval2.0+
http://hg.mozilla.org/mozilla-central/rev/6ac2d9151492

Checked in, thanks for the quick review
Is this part of any standard or specification? Just spent 10 minutes Googling around and can't find it in one.
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
Keywords: dev-doc-needed → dev-doc-complete
(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.)
Uh, did we add non-prefixed events.

Updated

7 years ago
Depends on: 609555

Comment 20

7 years ago
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
Keywords: dev-doc-complete → dev-doc-needed

Comment 21

7 years ago
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

7 years ago
Since the feature here is only about <script> tags not JavaScript generally, better names would be:
document.currentScriptTag
document.onafterscripttagexecute
document.onbeforescripttagexecute

Comment 23

7 years ago
If you want to be even more precise, it's about script elements, not tags.
(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/
re comment 20: what email to WHATWG is that?

Comment 26

6 years ago
It's in the URL field: http://www.mail-archive.com/whatwg@lists.whatwg.org/msg23015.html
(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.
Has there been much developer interest in this feature?
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.
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...
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.
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
Keywords: dev-doc-needed → dev-doc-complete
Thanks Sheppy! I added some cross references as well.
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
Also currentScript:
http://html5.org/tools/web-apps-tracker?from=7550&to=7551
You need to log in before you can comment on or make changes to this bug.