We are using Vaadin 14 in compatibility and every thing was working fine until I decided to upgrade my Chrome to version 80. Now the application shows just black page. I cross checked it on Firefox and everything seems to be working on it.
Looks like some issue with html-imports pollyfill. After initial debugging I found out that WebComponentReady event is not being triggered, I believe Vaadin is dependent on this event to render components/views on the page.
how are you. We just updated our Chromes and tested vaadin.com with the latest version and … it still works. Have you tried updating to at least v14.1.5 (that’s the version vaadin.com is using)?
Paul Römer:
how are you. We just updated our Chromes and tested vaadin.com with the latest version and … it still works. Have you tried updating to at least v14.1.5 (that’s the version vaadin.com is using)?
Note: vaadin.com uses custom webcomponents polyfill instead of one bundled with Vaadin 14
I am great. How are you doing? We have catch up sometime.
I just updated Vaadin to 14.1.16 and still the same issue. I am not sure if its issue with webcomponents pollyfill, vaadin compatibility mode or the way gradle plugin bundles frontend resources.
Paul Römer:
how are you. We just updated our Chromes and tested vaadin.com with the latest version and … it still works. Have you tried updating to at least v14.1.5 (that’s the version vaadin.com is using)?
Note: vaadin.com uses custom webcomponents polyfill instead of one bundled with Vaadin 14
We also have problems with Chrome 80 and an application in Vaadin 14 compatibility mode (still on 14.0.0).
It works but the styling is off. The styles in “custom-style” from the imported shared-styles.html are not applied anymore.
Is there way to load custom webcomponents polyfill and not one which comes with Vaadin 14.
You can do it in a BootstrapListener. I think, however, that it would make more sense to load html-imports polyfill directly, as Chrome doesn’t need any webcomponent polyfills otherwise.
I updated the old bookstore starter and from v13 to v14 by using the compatibility mode as you did. Just wanted to know if it is reproducible but it starts up normally and the login view is show as expected. Of course, that is still far away from your setup. Neither Gradle nor Polymer views are used.
Do I understand correctly that the webcomponents-loader script is loaded as expected or does the injection fail already?
You can do it in a BootstrapListener. I think, however, that it would make more sense to load html-imports polyfill directly, as Chrome doesn’t need any webcomponent polyfills otherwise.
Thanks Artem, I tried loading html-imports polyfill using both BootstrapListener and JavaScript annotation. It did fix the page load problem, but created another when were user can’t navigate between pages as the new imports were getting blocked. That means the newer version of html-imports also has same bug.
Paul Römer:
Do I understand correctly that the webcomponents-loader script is loaded as expected or does the injection fail already?
Yes, webcomponents-loader was loaded and it also triggered html-imports. But html-imports was parsing one of our svg template wrongly.
We decided to remove all html-imports from page and just load bare minimum view, and surprisingly it worked. After adding back imports one by one we discovered that the issue was with our svg-icons. It had content something like following,
html-imports was treating the style tag inside svg as another import dependency and was waiting till browser downloads the file. This stopped the polyfill from triggering HtmlImportsReady event, which in turn blocked Vaadin from loading page.
After updating the content of svg-icons, it fixed the problem. This is known bug on html-imports polyfill V1.
