Cross-frame problems

[SirPepe]

I just noticed that much of Bacon.js won't work across frame borders. Example: http://files.peterkroener.de/baconframes/a.html

The culprits are the assert functions that use instanceof, which doesn't work across browsing contexts.

I'm not really sure what a good fix would be. Maybe toString() instead of instanceof?

[raimohanska]

This is something that is not supported at the moment. The instanceof checks are are very safe way to make sure stuff works. There's also a load of global state in the internals. Not sure how it would work if you connected two separate "bacon engines" together.

I don't have the time to investigate this right now, but I'm open to suggestions.

[SirPepe]

Now that i think about it it's not really a problem; one could always let a document in an iframe use the parent document's bacon engine (var Bacon = window.parent.Bacon). Then there's only a single bacon engine and no more problems with instanceof. A line about this in the docs and we can forget this :)

[raimohanska]

I added it to the FAQ at https://github.com/baconjs/bacon.js/wiki/FAQ

[hutchike]

...or window.top.Bacon

[antris]

We hit this mine in our codebase. Would it be possible to make a better error message? Or better yet, move on to a better compatibility check than instanceof?

So why this ticket was closed... due to lack of time? :)

[raimohanska]

Added to FAQ, closed :) Maybe we need something better, @antris. If you've got ideas for better compatibility check, feel free to express them.

The check could of course be laxed a bit to allow multiple Bacons so to say. But. The internal details related to preventing glitches (duplicate events) depend on hidden global internal state that would then be different in the two Bacon instances. That might lead to some "interesting" effects and right now I don't think it's something we want to start debugging. To make sure stuff works a bunch of new automatic tests would be needed etc.

[antris]

For example Bacon tagging all EventStreams it creates with a version number/object and then comparing if the two versions are compatible?

I am being completely naive about the internals, haven't really hacked Bacon internals at all.

At the very least it would be helpful that there would be a warning if trying to mix streams from different Bacon instances. Now mixing them will produce very weird errors, and using an iframe isn't an obvious thing to check and stumble upon in the FAQ.

[raimohanska]

That won't solve the issue of having two separate instances of internal state.

[antris]

If the state problem cannot be fixed within a reasonable workload then how about giving an error message that refers to the FAQ?

[rpominov]

Maybe it could help if global state will be created not per instance of the library, but once for all instances? Something like window._baconState, or window['@baconState' + Bacon.version].

[Macil]

Making shared state depend on the exact version number could lead to frustrating issues: imagine a project uses libraries A which depends on baconjs:0.7.53 and B which depends on baconjs:^0.7.53. As long as 0.7.53 is the latest, bacon streams from A and B will interoperate fine, but once Bacon 0.7.54 is released, they'll stop interoperating.

Making shared state not depend on the exact version number restricts how future versions can change the state of course. Both ways of sharing state having problems makes that strategy not seem so great to me.

[rpominov]

Hmm, it can be window['@baconState' + lowestCompatibleVersion], but I'm also not a fan of this idea. Just a theoretical suggestion of how it can be solved :)