Error importing the app-indexeddb-mirror.html about app-storage

[abdonrd]

Any news @cdata? Right now we can't use the component without the polyfill :(

[jesusprubio]

Any news @cdata? :(

[Borjagodoy]

@cdata any news about this?

[abdonrd]

The common-worker.html error is because the document._currentScript is undefined:

var BASE_URI = document._currentScript.ownerDocument.baseURI;
var WORKER_SCOPE_URL = Polymer.ResolveUrl.resolveUrl('common-worker-scope.js', BASE_URI);

( I has tried to hardcoded the WORKER_SCOPE_URL variable, and it works. )

[skeemer]

I've been running into this and wondered why something that seems better was removed. cd26416#commitcomment-17661405

[abdonrd]

Thanks for the reference, @skeemer!

[abdonrd]

I think we need to remove the underscore. From:

var BASE_URI = document._currentScript.ownerDocument.baseURI;

To:

var BASE_URI = document.currentScript.ownerDocument.baseURI;

And the webcomponents.js make the polyfill.

(I has tried, and it seems to be working)

[neckaros]

I had the same issue. polyfill use document._currentScript but for navigator that don't need polyfill var document._currentScript does not exist.

Using var BASE_URI = document.currentScript.ownerDocument.baseURI;
works like a charm on chrome :)

[dtruffaut]

Same problem here... How can we solve this ?

I changed :

var BASE_URI = document._currentScript.ownerDocument.baseURI;

by:

var BASE_URI = document.currentScript.ownerDocument.baseURI;

It worked.

but now I have another error that remains:

app-indexeddb-mirror.html:249 Uncaught TypeError: Cannot read property 'validateSession' of undefined

          __updatePersistedData: function() {
            this._log('Updating persisted data..');
            this._enqueueTransaction(function() {
            return this.client.validateSession(this.session);    <==== Problem here
          });

UPDATE : I just unlogged from other apps that I was working on (Google Auth) and did a force refresh on my browser and it solved this last error.

[abdonrd]

Yay! 😀

[TomK]

@cdata within the last few days this seems to have reappeared on 2.0-preview. Should #66 also be applied to that branch?