fix for depending on css context as same than javascript context #234
Conversation
…ded new option 'document'
|
I realise I changed the position of a few things, as it was a pain to get around some stuff. Hope it is all clear (also tried to keep your coding style), but if there are some things I did completely wrong, let me know. |
|
I need to give it a try. |
| @@ -18,17 +18,19 @@ | |||
|
|
|||
| var prefixes = ['webkit', 'Moz', 'ms', 'O'] /* Vendor prefixes */ | |||
| , animations = {} /* Animation rules keyed by their name */ | |||
| , useCssAnimations /* Whether to use CSS animations or setTimeout */ | |||
There was a problem hiding this comment.
This variable was only used in the spin function, when declaring a new Spinner. Depending on the document you load it in, this could change, so you can better check it when initialising the instance, not when loading the code.
There was a problem hiding this comment.
Not really. This can only change if the browser changes, which is not possible.
|
Tested! It just works as expected! |
|
You should look at the update. I changed the animations name cache. I had a bug, where the spinner would stop working when the front document was reloaded, without reloading the background document. The update looks at the animations names for the spinner, and removes them from the global Spinner names array, so they will be readded when a new Spinner is created. |
|
spin.js v3.0 no longer injects a CSS sheet into the document head, so this should no longer be an issue. |
Added a new option "document". The current version 2.0.1 has a problem, where loading the spin.js javascript code from another frame, added the css rules to that other frame. Basically it came down to wrongly relying on the "document" where the javascript is running as the default setting.
I added this for use of spin.js in a chrome extension, but I'm sure this bug also happens when using iframes, multiple frames, or other stuff like that.