Semver not being followed correctly

[lavelle]

I just ran a bower update in my project to get new versions of the Polymer components, and when I reloaded my app I was presented with a blank screen.

All my components are specified in the Bower manifest using the Semver caret operator, which means "Compatible with" the specified version. As such, any new versions installed in this process should have the same external behaviour, the only changes being internal bugfixes. This action caused my code to stop working though, so at least one package must have implemented a breaking API change and only incremented the PATCH number.

I'm unable to diagnose which component caused the issue as several components were updated simultaneously via this process, and no errors are presented in the console.

[lavelle]

I've made sure to update all my build tools to the latest version too (I'm using grunt-vulcanize).
The Polymer global object is present, and the DOM tree is shown correctly in the Chrome element inspector.
Could this be due to an issue with one of the Polyfills? The fact that nothing is rendering at all seems to imply a more fundamental problem than one with a particular component, such as the polyfill for registering custom elements not working correctly.

[sorvell]

This is a fair point and we're sorry for the trouble. Polymer is still in alpha and there will be breaking changes. That said, we should use versioning more clearly.

In this case if you can provide a link or some info we can certainly help debug the problem.

[lavelle]

Okay, thanks. I realise that Polymer is a new project and that these sorts of growing pains are to be expected.

It's a very strange issue. As I said, the entire DOM tree is present and correct in the inspector. I can highlight some elements and they have the correct dimensions and position. However others have a size of 0x0. No elements are visible, even the ones with the correct dimensions.

Attempting to add new CSS styles in the inspector has no effect. I've even tried something as simple as adding a background colour to the body, which should be completely separate from Polymer, and nothing appears.

The code is unchanged from the version that was previously working. The only change was an update of the Bower components to (supposedly) compatible new versions.

[lavelle]

Upon further inspection it is only native elements like h1 and div that have the correct dimensions. All the custom elements, both ones I have created and the core and paper elements, have a height and width of zero.

Is this likely to be due to the polyfill for custom elements not working correctly?

[robdodson]

Hi Giles,

It's hard to say without seeing some code. Could you throw together a gist
or a jsbin?

On Wed, Aug 13, 2014 at 11:26 AM, Giles Lavelle notifications@github.com
wrote:

Upon further inspection it is only native elements like h1 and div that
have the correct dimensions. All the custom elements, both ones I have
created and the core and paper elements, have a height and width of zero.

Is this likely to be due to the polyfill for custom elements not working
correctly?

—
Reply to this email directly or view it on GitHub
#704 (comment).

[lavelle]

Sure, all the code for the app is here: https://github.com/lavelle/chromeos-filesystems/tree/s3fs/s3fs/ui

html/index.html is the main entry point that gets bundled up by Vulcanize.

[lavelle]

By going through and commenting a bunch of stuff I've isolated it to my custom element that extends paper-dialog.

[lavelle]

I've reduced it to a minimal test case. Creating a HTML file with the contents

<polymer-element name="my-foo"></polymer-element>

and importing that to the index.html with

<link rel="import" href="my-foo.html">

will trigger it. Still no console errors, just a blank screen. Presumably because the element hasn't been registered with a JS call to Polymer('my-foo', {}); That still doesn't solve my problem because my component definitely includes a script that has a call to the Polymer constructor.

[lavelle]

Okay, can confirm this is due to not registering elements correctly, will file a new issue.

[sorvell]

Hmm, here's some potentially related info. Polymer batches element registrations. The list of elements that are batched was previously determined by calls to Polymer and it's now determined by the existence of <polymer-element>'s.

Here's an example that shows extending paper-input works:

http://jsbin.com/dihigo/1/edit

So, the new behavior has some advantages but we at least need more info about what's happening when there's bad behavior.