Intent to Implement and Ship: Context-less Event Dispatch

[Hajime Morrita]

Primary eng (and PM) emails

mor...@chromium.org

Spec

http://dom.spec.whatwg.org/#dispatching-events

Summary

This change will allow DOM events to be dispatched over context-less documents, which is typically created through XHR, document.implementation object or HTML Imports.

This is rather a bug fix than a new feature but I'd like to announce it justin case, because the change affects Web-facing behavior that might be interesting for some people. After this change, this snippet http://jsfiddle.net/ta6CC/7/ should print two lines.

Motivation

In HTML Imports which I'm working on, "load" and "error" events should be dispatched on sub-imports, which is an import which is linked by another import. The events need to be fired on the linking import that doesn't have any browsing context.

Compatibility Risk

Little. This matches Blink to other browsers like IE and Firefox. It is possible for apps to depend on this (incompatible) behavior. However, I don't see any benefit to do it as this is Blink/WebKit specific.

Ongoing technical constraints

None.

Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.

OWP launch tracking bug?

http://crbug.com/275285

Row on feature dashboard?

No, and I don't think we need it.

Requesting approval to ship?

Yes.

--

morrita

[Adam Barth]

Given that this change make Blink more compatible with IE and Firefox, LGTM.  Would you be willing to file a bug with WebKit so that they're aware that their behavior doesn't match other browsers in this regard?

Adam

[Adam Barth]

One implementation detail to be careful about: we need to make sure that inline event handlers don't execute in contextless documents created by APIs like XMLHttpRequest.  Specifically, consider the following situation:

1) Goodguy.com makes a cross-origin XMLHttpRequest to badguy.com.

2) Badguy.com replies with a document that contains an inline event handler.

3) The inline event handler executes.

Now Badguy.com has executed a script of his choice in Goodguy.com's origin, which is a cross-site scripting attack.

The situation is different for HTML Imports, of course, because if goodguy.com imports HTML from badguy.com, then goodguy.com expects badguy.com to be able to execute script in the goodguy.com origin.

Adam

[Dimitri Glazkov]

LGTM.

Adam raises an important (and captured by spec
http://www.whatwg.org/specs/web-apps/current-work/multipage/webappapis.html#event-handler-attributes)
point. Please don't forget to add test coverage for this case.

:DG<

[Eric Seidel]

Is it possible right now to dispatch a custom event to a context-less document?

Curious if that behavior would change as well.

[Eric Seidel]

I see now that my question is exactly what you're doing. :) You're
enabling custom event dispatch on context-less documents.

I think it's OK to match FF/IE here, even if this is a bit odd in the
case of non-custom events. lgtm.

[Hajime Morrita]

Thanks folks, I think HTML Imports should patch the HTML standard to make event handler content attributes working, if needed.

> I think it's OK to match FF/IE here, even if this is a bit odd in the

case of non-custom events.  lgtm.

Yup. Actually, I don't think there is any existing event which is fired on context-less documents because such documents are inert. The mutation event could be an exception, but it is disabled on wild web anyway.

--
morrita