Sdk: Reflecting on un-marked type 'HtmlElement'

[zoechi]

This might be a Polymer issue, but it fails only in Dartium but is working fine in Chrome therefore I assumed it's a Dartium issue.

When I run https://github.com/bwu-dart/bwu_datagrid/blob/69fbef15c0317ec3f0bd5474de68d79ce63a6229/example_/lib/e02_formatters/app_element.dart#L27-L27

(entry point https://github.com/bwu-dart/bwu_datagrid/blob/69fbef15c0317ec3f0bd5474de68d79ce63a6229/example_/web/e02_formatters.html)

in Dartium I get

Exception: : Unhandled exception:
Reflecting on un-marked type 'HtmlElement'
#0      _InstanceMirrorImpl._InstanceMirrorImpl (package:reflectable/src/reflectable_transformer_based.dart:213:9)
#1      ReflectableImpl.reflect (package:reflectable/src/reflectable_transformer_based.dart:2192:16)
#2      _setupLifecycleMethods.<anonymous closure>.<anonymous closure> (package:polymer/src/common/polymer_descriptor.dart:168:39)
#3      JsObject._callMethodLegacy (dart:js:1161)
#4      JsObject.callMethod (dart:js:1150)
#5      HtmlElement&PolymerMixin.polymerCreated (package:polymer/src/common/polymer_mixin.dart:23:15)
#6      PolymerElement.PolymerElement.created (package:polymer/polymer_micro.dart:23:5)
#7      AppElement.AppElement.created (package:bwu_datagrid_examples/e02_formatters/app_element.dart:28:26)
#8      Blink_Utils.setInstanceInterceptor (dart:_blink:23305)
#9      _createCustomUpgrader (dart:html:758)
#10     _VMElementUpgrader.upgrade (dart:html:47499)
#11     registerDartType.upgradeElement (package:web_components/interop.dart:38:45)
#12     JsObject._callMethodLegacy (dart:js:1161)
#13     JsObject.callMethod (dart:js:1150)
#14     registerDartType (package:web_components/interop.dart:41:8)
#15     CustomElementProxy.initialize (package:web_components/custom_element_proxy.dart:23:5)
#16     PolymerRegister.initialize (package:polymer/src/common/polymer_register.dart:21:21)
#17     loadInitializers.<anonymous closure>.<anonymous closure> (package:initialize/src/static_loader.dart:46:32)
#18     _runInitQueue (package:initialize/initialize.dart:35:24)
#19     _runInitQueue.<anonymous closure> (package:initialize/initialize.dart:38:26)
#20     _RootZone.runUnary (dart:async/zone.dart:1137)
#21     _Future._propagateToListeners.handleValueCallback (dart:async/future_impl.dart:553)
#22     _Future._propagateToListeners (dart:async/future_impl.dart:639)
#23     _Future._completeWithValue (dart:async/future_impl.dart:426)
#24     _Future._asyncComplete.<anonymous closure> (dart:async/future_impl.dart:481)
#25     _microtaskLoop (dart:async/schedule_microtask.dart:41)
#26     _startMicrotaskLoop (dart:async/schedule_microtask.dart:50)
#27     _ScheduleImmediateHelper._handleMutation (dart:html:48970)

Dart VM version: 1.16.0-edge.95f37e03afcc58ce035d5587cffc5fe57f0232ba (Wed Apr 6 16:08:39 2016) on "linux_x64"

[alan-knight]

This looks more related to Reflectable, and perhaps to Polymer's usage of it. It may be that the reflectable information needs to do something different for Dartium, or that it's not being applied somehow. e.g. if reflectable wants to rewrite the dart:html code, but that's coming from a snapshot in Dartium, it's not going to work. @jakemac53 @eernstg

[eernstg]

The 'pubspec.yaml' at https://github.com/bwu-dart/bwu_datagrid/blob/69fbef15c0317ec3f0bd5474de68d79ce63a6229/pubspec.yaml doesn't actually allow for any transformation to take place. I would expect a 'pubspec.yaml' that includes polymer as a dependency to declare its transformer (which will run the reflectable transformer internally), e.g.:

transformers:
- polymer:
    entry_points:
    - web/index.html

I wouldn't expect such a new version of polymer to be able to use the reflectable and web_components transformers directly, that was an approach that was used in older versions until the internal polymer transformer was created (which will in turn run those two other transformers as subtasks).

The next issue is that HtmlElement would probably be an un-marked class for jsProxyReflectable in any case (assuming that this is the reflector that you are trying to use for mirroring it): JsProxyReflectable has a SuperclassQuantifyCapability(HtmlElement, excludeUpperBound: true), which explicitly stops the inclusion of superclasses just before it reaches HtmlElement (I think this approach was chosen because HtmlElement itself has lots and lots of members, and it is rather costly in terms of code size to include it for reflection if you don't have to). If you really want to be able to reflect on an instance of HtmlElement you can add support for this via a metadata annotation on an import of 'reflectable.dart':

@GlobalQuantifyCapability("HtmlElement", jsProxyReflectable)
import 'package:reflectable/reflectable.dart';

You may wish to use something more like r"^dart.html.HtmlElement$" to select the right class, and nothing else.

[zoechi]

@eernstg thanks a lot for having a look!

The missing transformer was an oversight when upgrading to a newer Polymer version where the transformer polymer was introduced.

I tried with

transformers:
- polymer

and

transformers:
- web_components
- reflectable

• no entry_points because it's just a dependency with components

The main pubspec.yaml is https://github.com/bwu-dart/bwu_datagrid/blob/69fbef15c0317ec3f0bd5474de68d79ce63a6229/example_/pubspec.yaml in the example_ subdirectory.
The parent is just a dependency, thus no entry points.

I wonder why it is working in JS then, there the transformers are mandatory, in Dart it runs on mirrors anyway when no transformers are applied AFAIK.

[eernstg]

You didn't mention whether it actually helped. ;-)

Specifying that the reflectable transformer must be included with no entry points is equivalent to not including it at all; it is the 'dependencies:' entry that makes it possible to use reflectable libraries like `package:reflectable/reflectable.dart'. But I still think that the right thing to do is to specify just the polymer transformer (which is just a wrapper that will run the other two transformers internally).

Reflectable uses 'dart:mirrors' if the transformation is not performed (in that case, the implementation of the reflectable mirrors is the one in 'reflectable_mirror_based.dart'), but I don't know whether web_components will work in an untransformed state. Note that there's one combination which will not work with reflectable: untransformed code and dart2js translation. The problem is that some features that reflectable relies on have not been implemented in the 'dart:mirrors' that dart2js provides. But the vm (including dartium) and untransformed code should be fine.

Another matter is that you have chosen to use reflectable 0.5.2, which may create a conflict with polymer. Reflectable 0.5.4 has been published, and I think I saw polymer will use that as soon as possible (if it's not already doing that). If you just let polymer decide on the version of reflectable and omit it from your pubspec.yaml you would avoid the conflicts. (And even if you are using reflectable directly as well and want to list it in 'dependencies:' then you could use something like '^0.5.2' to allow for newer versions).

[zoechi]

@eernstg Sorry :-/, no, it didn't change anything.

Polymer enforces '>=0.5.0 <0.5.3'. I added the constraint because of some bug with newer reflectable versions a while ago (not this is enforced by Polymer itself)

[eernstg]

Reflectable 0.5.4 was created as a bug fix for 0.5.3 (there was a cache which was flushed when pub serve had many entry points, and this caused some additional "constant is null" situations that we did not know about and did not test for). Polymer stayed at reflectable 0.5.2 (by using this '<0.5.3' constraint that you mentioned) and analyzer 0.27.1 in order to avoid the problems arising from those nulls.

But polymer is expected to use reflectable 0.5.4 real soon now, and Jacob already confirmed that the issue seems to have been resolved (https://github.com/dart-lang/polymer-dart/issues/690). So you might as well use a more flexible constraint on reflectable (if any) to allow polymer to take that step.

[zoechi]

Thanks, I'll try with a dependency_override

Specifying that the reflectable transformer must be included with no entry points is equivalent to not including it at all; it is the 'dependencies:' entry that makes it possible to use reflectable libraries like `package:reflectable/reflectable.dart'.

It was always necessary to list a transformer in pubspec.yaml of every file where it needs to be applied because transformers can only process files from the package where they are added to pubspec.yaml

I don't know details but I run often into this issue with packages that contain Polymer elements or Angular components that were used in other packages. I also haven't heard anything about a related change.

[zoechi]

@eernstg I still get the same exception with analyzer 0.27.2 and reflectable 0.5.4

[eernstg]

Several things on the table here. ;-)

If you used a dependency_overrides section to force reflectable 0.5.4 and analyzer 0.27.2 then there may be conflicts with other packages. If polymer-dart and others are ready to use these versions you should get them if you just make your constraints on reflectable sufficiently flexible (possibly by leaving out the dependency on reflectable entirely), and if you don't get them this way then there may be conflicts with something else. My assumption is that the dependency_overrides experiment was intended to see whether it would help to use reflectable 0.5.4, "just to try it", and that didn't work. That's fine, maybe some package you're using actually isn't ready for these versions after all, and we'll just have to wait.

But did you add the GlobalQuantifyCapability? It's no surprise that you get "Reflecting on un-marked type 'HtmlElement'" if you are making an attempt to obtain a mirror for an instance of HtmlElement from jsProxyReflectable, because HtmlElement is indeed not covered by that reflector.

At this point I actually think it would be more surprising if this had worked in some other configuration. At first you said that it 'fails only in Dartium but is working fine in Chrome', but how could it work in Chrome if the same attempt to reflect on an instance of HtmlElement was made there?

Finally, the way you ask for transformers is again another topic. There is no difference between not having the reflectable transformer at all, and having it with an empty set of entry points. In both cases it will not transform any files. However, the reflectable transformer should not be specified at all with polymer, because the polymer transformer runs the reflectable transformer internally; if polymer needs to compute some additional entry points or give some extra options then specifying the reflectable transformer explicitly will just create potential inconsistencies.

[zoechi]

@eernstg

My assumption is that the dependency_overrides experiment was intended to see whether it would help to use reflectable 0.5.4, "just to try it", and that didn't work. That's fine, maybe some package you're using actually isn't ready for these versions after all, and we'll just have to wait.

exactly.

I had expected a different error if there were a compatibility problem though.
I will wait then for the update to become available.

But did you add the GlobalQuantifyCapability? It's no surprise that you get "Reflecting on un-marked type 'HtmlElement'" if you are making an attempt to obtain a mirror for an instance of HtmlElement from jsProxyReflectable, because HtmlElement is indeed not covered by that reflector.

I don't use reflectable in my code. I hope I don't have to care about adding GlobalQuantifyCapability myself.

At this point I actually think it would be more surprising if this had worked in some other configuration.

I didn't run in such issues with previous Polymer versions (>= 1.0.0-rc.xxx)

I only upgraded to the new Polymer version, newer Dart and Dartium version and fixed strong-mode hints and warnings

Finally, the way you ask for transformers is again another topic. There is no difference between not having the reflectable transformer at all, and having it with an empty set of entry points.

I'm pretty sure that's not how it works, but I leave that to @jakemac53 to explain. I don't know why, only that it is necessary to allow transformers process code of dependencies.

[jakemac53]

@eernstg the transformers discussion here is a red herring. There is a subpackage in the example_ folder, which properly lists the transformers https://github.com/bwu-dart/bwu_datagrid/blob/69fbef15c0317ec3f0bd5474de68d79ce63a6229/example_/pubspec.yaml#L38. The transformers are not required at all for libs which do not have any entry points.

[eernstg]

Exactly, if it works to have no entry points in a given 'pubspec.yaml' for the reflectable transformer then it also works to not have the transformer at all in that file. In both cases the transformer will not transform anything.

But if a client package (e.g., 'bwu_datagrid/example_') specifies the reflectable transformer with some entry points then the build or serve processing in that client package will cause the reflectable transformer to read libraries (potentially from arbitrary reachable contexts, e.g., 'dart:core', or some libraries from 'bwu_datagrid', as well as local ones from 'bwu_datagrid/example_') and use the information from there in the generation of code for the given entry point. It makes no difference that 'dart:core' is not "a library in a package whose 'pubspec.yaml' specifies that the reflectable transformer must be used", what counts is that 'bwu_datagrid/example_/pubspec.yaml' specifies it.

But this still does not elucidate why the execution behind the stack that was listed in the initial message on this issue made an attempt to obtain an instance mirror on an instance of HtmlElement.

Could it be the case that, in the newer version of Dartium, the class reported by some objects (runtimeType) has changed from a proper subclass of HtmlElement to HtmlElement itself, all other things unchanged? That could explain why it used to work: with the old Dartium, no attempt to obtain an instance mirror on an instance of HtmlElement was ever made, because it was an instance of a subclass.

[zoechi]

This is the last working version

Dart VM version: 1.16.0-edge.c2700473c49aecd48cb0ac2a73a37a38dfab979c (Mon Mar 28 18:00:17 2016) on "linux_x64"

this is the first version where I get the exception

Dart VM version: 1.16.0-edge.4b38c3dfc253aba0908611d8026a2151a78d9e9b (Thu Mar 31 21:51:56 2016) on "linux_x64"

(from the versions I created a backup before downloading an update)

[jakemac53]

It looks like we are getting a non-upgraded element for dartInstance here. This looks like elements aren't being properly upgraded, which is likely a dartium bug.

[jakemac53]

cc @terrylucas

[felipefv]

The same thing is happening here.

O.S.: Debian 8 (Jessie) - 64bits
Dart: 1.16.0-dev.5.0 (64bits)
Dartium: 45.0.2454.104 (64bits)

pubspec.yaml:

name: 'application'
version: 0.0.1
description: A web app built using polymer.dart.

author: Your Name [email protected]

homepage: https://www.example.com

environment:
sdk: '>=1.9.0 <2.0.0'

dependencies:
browser: ^0.10.0
polymer_elements: ^1.0.0-rc.8
polymer: ^1.0.0-rc.15
web_components: ^0.12.0

transformers:

• polymer:
  entry_points: web/index.html
• $dart2js:
  minify: true
  commandLineOptions:
  
  
  
  • --trust-type-annotations
  
  
  • --trust-primitives
  
  

[zoechi]

This should be fixed before 1.16
Dartium is currently unusable for Polymer

[terrylucas]

Needs to be fixed.

[terrylucas]

Two pending CLs pass all co19 custom element tests and and all Dart Polymer tests in Dartium.

WebKit CL
Dart CL

[terrylucas]

All CLs have been committed waiting for bots to run.

[terrylucas]

Two CLs have been committed to fix the Polymer problems with Dartium 1.16.
All co19 custom element tests and and all Dart Polymer tests
https://github.com/dart-lang/polymer-dart pass in Dartium.

WebKit CL https://codereview.chromium.org/1908423004/
Dart CL https://codereview.chromium.org/1914643002

On Wed, Apr 20, 2016 at 11:07 PM, Günter Zöchbauer <[email protected]

wrote:

This should be fixed before 1.16
Dartium is currently unusable for Polymer

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/dart-lang/sdk/issues/26228#issuecomment-212758415

[mit-mit]

@terrylucas is there a 1.16 merge request? @whesse FYI

[terrylucas]

William did this for me, thanks.

[mit-mit]

Closing this bug as this was fixed in bleeding edge, and #26327 tracks the merge to dev.

[zoechi]

Just confirming that this is working for me in bleeding edge

Dart VM version: 1.16.0-edge.733b6df785b6b2e0c34cbd182e3df8902ad9ad18 (Mon Apr 25 16:58:29 2016) on "linux_x64"