urth-import fails in Safari 8.0.7 and Firefox about declarativewidgets HOT 5 CLOSED

Seems to be broken on safari and firefox for me. Its due to the redirect being done on the server. Polymer is getting initialized more than once. I have some code that fixes the issue but need to run through all the possible scenarios before I'm confident in it.

from declarativewidgets.

The root of this issue is that it is possible for the browser to be given different urls to load polymer.html. If the url used to load polymer at initialization is not the same as the url that gets resolved when loading an HTML Import in a cell, then the browser will assume that it is a different resource and polymer will get initialized multiple times.

This could be mitigated by the Polymer library but Polymer itself does not prevent multiple initialization (unlike almost every other library out there). Doesn't appear that there is strong motivation from the Polymer developers to prevent this on their end as the following issue mentions "architectural issues" and an assumption that everyone should be using the bower dependency layout.

Element (re)registration errors when loading polymer.html more than once

Not sure how to properly fix this on our end without mandating the path that users must specify to reference a bower dependency. My proposal would be to always specify the link href with a relative path like urth_components/paper-slider/paper-slider.html. That way the reference is always relative to the notebook and the dependencies loaded at initialization of the notebook can also be loaded with the same dependency. So, the browser would see the same url for the polymer reference both by initialization and by any other link tags specified in the cells. This will of course have impacts on the dashboard as well.

@parente @lbustelo thoughts?

from declarativewidgets.

In the tour notebook, are two different paths used, absolute and relative? If not, I'm assuming it means the redirect from ./urth_components to /urth_components is what's busting it?

A thought I had earlier was to change from doing a redirect to having a file handler that simply returns the requested file directly from whatever URL is used instead of using HTTP redirects back to the browser. Would that help? That way, the constraint is purely on the user to make sure a single path scheme is used in the notebook be it ./urth_components or /urth_components (if I'm understanding the problem correctly.)

from declarativewidgets.

Has to do with the difference in URL at initialization of the notebook (init.js) and url used by elements imported into notebook via the cell.

Firefox and Safari apparently handle the redirect different then Chrome and reinvoke the script when the originating url is different, even if the redirect url is the same. In my local fork I have switched to using just a file handler and got rid of the redirect but that alone does not solve the problem globally since different urls are still assumed by the browser to be different resources.

You can see my changes in commit 45444eb

However, even after those changes, I'm noticing that on the tour example, the paper-dropdown-menu is not working correctly.

from declarativewidgets.

We discovered today that the WebComponent polyfill will load all links before and independently of whether they have our urth-core-import extension. This means that on Safari and Firefox, there is no way to intercept the attempt to load the initial value of the href provided by the user.

In Chrome, we are actually able to modify href within our Polymer extension and effectively prevent an unnecessary network request.

from declarativewidgets.