Polymer is Chrome-only currently

[augustf]

Polymer and its supporting Web Components are esssentially Chrome-proprietary right now. As in #19, WC support can be turned on in Firefox, but is considered highly experimental. Since the Concerto Player uses Chromium, that won't be a problem for our builds, but current users on alternative platforms updating to a future 2.3 release will need to be mindful -- particularly Raspberry Pi users in Midori.

This was helpful to me in following support for Web Components: http://jonrimmer.github.io/are-we-componentized-yet/

While I don't believe there's anything for us to do on this currently (having two parallel frontends sounds a bit crazy), I'll leave this issue here to track the fact that we're effectively Chrome-only for the time being.

[bamnet]

Polymer should work on all modern browsers, including Firefox, Safari, and IE. If that's not the behavior we're currently seeing than we're doing something wrong... By we I'm probably referring to myself.

My hunch is that we need to pull in some polyfills.

On Wed, May 6, 2015, 2:23 PM August notifications@github.com wrote:

Polymer and its supporting Web Components are esssentially Chrome-proprietary right now. As in #19 https://github.com/concerto/concerto-frontend/issues/19, WC support can be turned on in Firefox, but is considered highly experimental. Since the Concerto Player uses Chromium, that won't be a problem for our builds, but current users on alternative platforms updating to a future 2.3 release will need to be mindful -- particularly Raspberry Pi users in Midori.

This was helpful to me in following support for Web Components: http://jonrimmer.github.io/are-we-componentized-yet/

While I don't believe there's anything for us to do on this currently (having two parallel frontends sounds a bit crazy), I'll leave this issue here to track the fact that we're effectively Chrome-only for the time being.

— Reply to this email directly or view it on GitHub https://github.com/concerto/concerto-frontend/issues/20.

[augustf]

Yeah-a little while ago I found some docs with mention of polyfills, and Gabe has been working with those to get things working in other browsers, while also attempting to use a newer version of Polymer.

[gbprz]

After including webcomponentsjs in the frontend and changing the about:config setting dom.webcomponents.enabled to true, I'm able to get the template to show. This means that the concerto-screen element is able to get the template using the path in the setup.json. All of the position divs and concerto-field elements are also in the page source, along with all of the content elements in the hidden div to be inserted once contents are constructed.

Even though I have active and approved contents in my feed (they show up on the Chrome frontend), I think it's currently an issue with the specific content elements or the way concerto-field is loading contents in the queue (possibly the events that load the contents, life cycle methods or constructors?).

That's where I'm at so far, I'll continue to narrow down my search and check out some of the concerto-field and concerto-content code/events and see if anything there is getting held up.

Let me know if you guys have any other suggestions or if I'm looking at the wrong thing here.

[augustf]

As we discussed, Polyfills (https://www.polymer-project.org/0.5/docs/start/platform.html) are supposed to be the solution for the lack of any browser support (that is, turning on the experimental implementation shouldn't be necessary in Firefox). But they don't seem to work as expected with our frontend code, even when Polymer has been updated to the latest stable version.

[gbprz]

As of 2ce693a1fd53c697ba0024e8169cda9b5d0e6ebb, things seemed to be working well in Firefox

[augustf]

I figured something was phony about those early cross-browser claims in the Polymer docs. Once we get this tested, we can close this out.