Running locally with polymer serve works fine. But if I deploy and check out the version on firebase hosting, when I click sign in, it opens the OAuth window (which is blank), sits there for a little while, then closes the OAuth window and logs:
polymer-micro.html:1 Uncaught TypeError: Cannot read property 'instanceCount' of undefinedcreatedCallback @ polymer-micro.html:1
firebase.js:3 Uncaught Error: Network Error
Only way to fix it is to go into the Applications panel in DevTools and set Bypass for network to tell the SW to not intercept requests on the page.
My suspicion is when the OAuth window opens, the SW is jumping in and trying to handle things. I've actually randomly seen the site get served into the window that was spawned to display the OAuth sign in
@notwaldorf was this the issue you all mentioned yesterday with service workers and the 1 line fix? (crosses fingers...)
indeed. The fix is to add navigateFallbackWhitelist: [/^(?!\/__)/] to sw-precache-config.js. This prevents the service worker from getting all up in the way of the OAuth window which starts with a /__ in its url
ugh, that's rough. We should think about how we could catch issues like these, or at the very least document them somewhere in the README as they come up.
yeah it took a decent afternoon of debugging and honestly we only arrived at this point by reverse engineering a SW one of the firebase folks had written and just deleting stuff till it worked :P
Which readme do you think would be the best place for this?
I'm not sure yet, the CLI README gets the most traffic but its an issue for polymer-build as well.
For now I would quickly mention that this kind of thing might need to be configured somewhere in the polymer-build README, and then do a better job of linking into the polymer-build README in the build section of the CLI. I'm working on rewriting the CLI README already to do this better.
@robdodson wdyt? Can you help describe the fix in the polymer-build README?
sure i'll send a PR
I just noticed the polymer-build readme doesn't mention sw-precache-config.js and I can't recall if it should or not... I think that's only for CLI builds right?
Catching up -- yes, that's the one liner. The problem is that auth on accounts.google.com happens as a redirect from a private Firebase page at /__/auth/.... That page doesn't exist, so the SW serves back the fallback index.html, which of course doesn't work.
If there is a "How to add Firebase to your project" section, that's a good place for it since it's very Firebase specific
Gotcha. In that case we should add a more specific "working with service workers" or "working with the polymer cli" section to the polymerfire README that calls out this problem & solution specifically. Then we could add the more general "hey you may need to whitelist some URLs for third-parties" to the polymer-build README.
@robdodson you're right, it takes the config as a property in its polymer.json options object instead of reading from another file directly. We're going to need to address that when we standardize on what goes into polymer.json.
@FredKSchott ok so sw-precache-config.js is for CLI builds, and an options object is used for polymer-build builds... yeah?
you got it. And both take the exact same data / format.
I sent a PR for the firebase-auth docs.
So should sw-precache-config.js for Firebase Hosting look like this?
module.exports = {
staticFileGlobs: [
'/index.html',
'/manifest.json',
'/bower_components/webcomponentsjs/webcomponents-lite.min.js'
],
navigateFallback: '/index.html',
navigateFallbackWhitelist: [/^(?!\/__)/]
};
yep
I use this to work:
navigateFallbackWhitelist: [ /^\/home\//, /^\/other\// ]
Fixed via 6d1755119896012a3a2291973b48c4b1f0e2553a & https://github.com/firebase/polymerfire/pull/113
Thanks for sharing @rof20004!
Most helpful comment
So should
sw-precache-config.jsfor Firebase Hosting look like this?sw-precache-config.js