dart2js: compiled html apps are not forward compatible: new browsers can break deployed apps

[jmesserly]

dart2js compiled apps are not safe to be deployed long term. Browsers can break Dart apps in ways that would not break an application written purely in JavaScript.

dart2js+html's dynamic dispatch works roughly like:

1. find the target object's JS type name (see getFunctionForTypeNameOf in native_helper.dart)
2. map JS type name to corresponding Dart type
3. apply Dart semantics for that method call

Some type names like "Node" and "HTMLElement" are specified and likely to be safe to use for the foreseeable future.

However, many other type names can and do get changed by browsers between major releases. For example, Firefox renamed the type that backs ".attributes" to MozNamedAttrMap, and this broke all use of HTML attributes.
(http://code.google.com/p/dart/issues/detail?id=11879). According to Pete this happened twice with IE11 as well. I think we have seen similar issues in Blink rolls.

How do we solve this for Dart 1.0? We must have a way to deploy apps that is not going to need recompilation whenever a browser vendor releases a new version...

Other scary facts about our current dispatch:

• it relies on User Agent sniffing
• both IE and Firefox have ad hoc rename tables (see typeNameInFirefox, typeNameInIE)
• everything falls back to Object.prototype.toString. From the perspective of HTML/DOM standards, the behavior here is unspecified. Typical JavaScript programs don't depend on it except for debugging.

[dgrove]

cc @kasperl.

[blois]

Recent IE 11 issue was bug #­12744- MouseEvent went to MSPointerEvent in IE11 Preview, then PointerEvent in RTM.

Additionally, there are cases such as FireFox's window.location where it's just a JS object and we haven't figured out any good way of determining the type. We handle this with a hack where we wrap it into a Dart wrapper which implements Location, but this is expensive and even relies on a runtime exception to detect (though this could probably be improved).

Blink has been discussing shifting more implementation into JS (such as promises), I'm not sure how our type detection will handle this.

[peter-ahe-google]

My guess is that for each of these problematic objects, we have to look at how the vendor documents they can be recognized. For pointer events, I guess we have to see if there is a "pointerType" property (and the object is an instance of Event?)

[blois]

That would probably work for the IE MouseEvent->PointerEvent change, PointerEvent is just a new subclass of MouseEvent.

For the Firefox NamedNodeMap->MozNamedAttrMap change, the NamedNodeMap type no longer exists.

The list of all of the 'name differences' that we've hit so far can be found at:
https://code.google.com/p/dart/source/browse/branches/bleeding_edge/dart/tools/dom/scripts/generator.py#­89

[kasperl]

At some point we talked about allowing our "type name" code to be updated separately from compiled apps (as a separate .js file downloaded from somewhere independent of the individual apps). Not sure if anyone thought more about that.

[kasperl]

Added this to the M7 milestone.

[blois]

Is that the dartExperimentalFixupGetTag function?

It might be helpful to also provide a way to pro-actively mark the type of objects-
// To work around the FF location bug:
window.dartTypeInstance(window.location, 'Location');

// To add a type to a polyfill class:
window.dartTypePrototype(JsMutationRecord.prototype, 'MutationRecord');

Hosting the patching code on a third-party server is what would be needed for zero-maintenance of these, but it seems quite undesirable to rely on external patching to keep an existing app running. Better than the current state though.

[jmesserly]

Shipping a separate type name map sounds intriguing. I think the challenge would be ensuring it is updated fast enough, perhaps by having someone track pre-release versions of the popular web browsers. It would be bad if, for example: Firefox rolls out a new version and a popular web site is down for a few hours while we release an updated JS file :)

[rakudrama]

I am going to take on some of the pre-emptive patching.
I'll try to get some of it done by M7, but it is unlikely to be completed before M7.

---

Set owner to @rakudrama.

[kasperl]

Removed Priority-Critical label.
Added Priority-High label.

[kasperl]

Changed the title to: "dart2js: compiled html apps are not forward compatible: new browsers can break deployed apps".

[rakudrama]

Marked this as blocking #9654.

[kasperl]

Removed this from the M7 milestone.
Added this to the M8 milestone.

[rakudrama]

I have implemented the following:
A global dartNativeDispatchHooksTransformer that can be set to a function or array of functions that can replace or augment these methods:
getTag, getUnknownTag, prototypeOfTag

I have not yet implemented the idea of discriminating functions that can be patched.
I don't think this provides any functionality that is not already possible by adding code to getTag.
The discriminating logic can be added under an 'if' in getTag.
It is not clear that the extra complexity and code size (2-3k unminified) pays its way.
It is a matter of efficiency, since the discriminator can identify the subclass without the overhead of calling the more general getTag.

[kasperl]

Removed this from the M8 milestone.
Added this to the 1.6 milestone.