useNoCache: false -- Uncaught Error: Error calling method on NPObject

[nodesocket]

Using version 1.3.5 and useNoCache: false getting:

Uncaught Error: Error calling method on NPObject

Once I flip useNoCache: true the error goes away.

[JamesMGreene]

What browser? Many of them unfortunately have issues loading cached Flash objects correctly, it seems. :(

[JamesMGreene]

Namely IE and Chrome for sure. Not positive on Firefox, Safari, Opera, etc.

That's why we keep the default as cacheBust: true, and the sole reason that v1.3.5 exists: we tried to use a smarter default in v1.3.4 by only targeting IE... instantly received bug reports about ZC being broken in Chrome.

[nodesocket]

Chrome 33. Thanks.

[jonrohan]

I was experiencing this error with flash version greater than v1.3.2 I deployed ZeroClipboard v1.3.5 to my site and saw this error right away. I ended up using the 1.3.2 swf file, with the 1.3.5 library.

[JamesMGreene]

@jonrohan: O RLY? o_O

Hmm, I'll have to take a closer look at what changed for the Flash object (if anything...?).

[JamesMGreene]

I don't see any obvious issue. The only change to the SWF at all was the rudimentary attempt to only trust parameters if they were FlashVars rather than query params:

v1.3.2...v1.3.5

[mjtko]

I have further anecdotal evidence regarding this issue:

I had exactly this problem in both Chrome 36, 37 (OS X) and Firefox 31 (OS X) (although the error message differs of course) when serving the SWF from a CDN with cacheBust set to false.

Everything works fine under the following conditions:

1. SWF and application in same domain with cacheBust = true
2. SWF and application in same domain with cacheBust = false, retrieving the SWF from the browser cache
3. SWF on CDN domain with cacheBust = true

And it doesn't work with:

1. SWF on CDN domain with cacheBust = false, retrieving the SWF from the browser cache

In my case, the CDN was at <app>.storage.googleapis.com and all of the above conditions were using https for both the application and the CDN. Specifying trustedDomains had no effect at all. I have not tested with http.

My understanding is that the root cause is that the flash vars configuration is never executed when retrieving the SWF from the cache -- in the eventuality that allowInsecureDomain allows (4) above to work (I haven't gone as far as recompiling the SWF to test this out, sorry) perhaps it would be wise to do some or all of the below:

1. allow access to the allowInsecureDomain option so developers who know what they're doing can set it for condition (4)
2. set allowInsecureDomain iff the SWF is retrieved from cache (i.e. set it at the point of entry to the movie and unset it as soon as the configuration of the movie via flashVars occurs)
3. Something else.

[JamesMGreene]

@mjtko: Sorry I never responded to this but I don't see how allowInsecureDomain(...) would help in this case. It only deals with cross-protocol trust (i.e. http://-hosted page trying to access an https://-hosted SWF) but it would still need to know what domains to trust.

I guess the alternative is to put the FlashVars on the SWF URL but that stinks too as the resource will need to be re-fetched whenever any config option critical to the SWF's instantiation is changed, even though the SWF binary itself has not changed.

All that said, I think that, if anything can legitimately fix this, I think I would've covered it with my Flash changes that listen for the stage to be its initialization to be done.

[mjtko]

Hmm, I forget exactly what I was driving at now (eek, is it almost December already? 😿) but I think I felt that the appropriate code path wasn't being executed when the SWF was pulled from the cache against a cross-origin request and was wondering aloud whether setting allowInsecureDomain would allow it to be executed successfully in this situation. Perhaps not though.

While it sure is frustrating, It's not a big deal tbh -- in the end I changed the code so it always loads the SWF from the asset server by using cacheBust which, while obviously less than ideal, does the trick.

Thanks for getting back in any case!

Edit: I also wouldn't put it past Adobe to reuse allowInsecureDomain for more than just HTTP/HTTPS. :)

[JamesMGreene]

@mjtko @jonrohan: Any chance that you have tried cacheBust: false with a recent v2.x version of ZeroClipboard?

The change I was referring to is src/flash/ZeroClipboard.as#L55-62, which has been present since v2.0.0.

[JamesMGreene]

P.S. Interesting thoughts on allowInsecureDomain... not sure! Good outside-of-the-box thinking, which seems to be a requirement when working with Flash. 😉

[mjtko]

Unfortunately I haven't been able to try 2.x yet -- we incorporated ZeroClipboard in our app in May and elected to use 1.x as 2.x wasn't released at that time. I'll try to squeeze an upgrade to 2.x into a near future dev iteration and get back to you.

[JamesMGreene]

@mjtko @jonrohan @nodesocket: Can you guys take a peek at PR #521? I believe the changes I've made there would solve pretty much every caching issue possible... for better or worse. 😝