event.detail is incorrect and inconsistent between dart2js and dartium #20648
Comments
|
Set owner to @efortuna. |
|
assigning to Siggi, as he talked about doing this one Set owner to @sigmundch. |
|
I started investigating how to fix the overall problem described in bug 19315, so I might fix this together with that. If we decide to keep that separate from the fix here, the issue here seems to be that dart:html for dart2js assumes that event.detail was set earlier via the initialization code in dart:html, and doesn't consider events that were initially set in JS. |
|
Removed this from the 1.7 milestone. |
|
Since this is assigned to the 1.8 milestone, I'm bumping the priority to high. Feel free to lower the priority and remove the 1.8 milestone marker. Removed Priority-Medium label. |
|
Added Accepted label. |
|
Removed this from the 1.10 milestone. |
sigmundch
added
Type-Defect
area-core-library
kevmoo
added
type-bug
matanlurey
added
the
closed-obsolete
|
Dartium is no longer supported. |
If the event contains a JSON object containing a proxy to a Dart object, the result:
- is null in dartium, but not null in JS.
- in JS it returns an map containing the JsObject for the proxy, rather than the unwrapped object.
Here is a simple example that can repro this problem:
<body>
<script>
function fire(item) {
var event = new CustomEvent('my-event', {detail: {item: item}});
document.body.dispatchEvent(event);
}
</script>
<script type="application/dart" src="index.dart"></script>
<script src="packages/browser/dart.js"></script>
index.dart:
import 'dart:html';$d, type: $ {d.runtimeType}');
import 'dart:js';
main() {
document.body.on['my-event'].listen((e) {
if (e.detail != null) {
var d = e.detail["item"];
print('0: ${d}, type: ${d.runtimeType}');
} else {
print('0: null');
}
var d = new JsObject.fromBrowserObject(e)['detail']['item'];
print('1:
});
context['fire'].apply([new _Foo()]);
}
class _Foo { int id = 3; }
In dartium, this prints '0: null', in dart2js it prints '0: [object Object], type: JSObject ', where the object happens to be the JsObject proxy for _Foo
The second line prints the same result in both:
1: Instance of '_Foo', type: \_Foo. I expect there result to always be like this line.This is related to bug 19315, but I'd like to make sure we track separately the inconsistency between the two implementations today.
The text was updated successfully, but these errors were encountered: