selfhosted web build vs Firefox extension

[ousia]

I have the Firefox extension from https://addons.mozilla.org/en-US/firefox/addon/ruffle_rs/ (automatically updated).

Firefox uses for https://ruffle.rs/demo the remote selfhosted build, instead of using the local one (to my computer, not to the site).

Both versions are from 2022-07-29, but I think that it is faster to check which version is newer and to download the remote selfhosted build if and only if this is newer than the local (Firefox, in this case) extension.

Or what is the rationale for the current behavior?

Many thanks for your help.

[ousia]

Even with https://www.free-culture.tk/ (which hosts version from 2022-07-26), the remote version is loaded, instead of using the newer local extension.

In some cases, the remote build is loaded when the page is first loaded.

But if I refresh page loading (F5), the remote build is always loaded.

I’m using Fedora 35 and Firefox 102. And again, an older remote version is being used instead a newer one (in this case).

Could anyone be so kind to explain me what is the reasoning behind the current behavior?

Many thanks for your help again.

[n0samu]

According to the current code of ruffle.js, selfhosted builds of Ruffle are supposed to override any installed extension:
window.RufflePlayer = PublicAPI.negotiate(window.RufflePlayer, "local");
"local" here means local to the website. Although this behavior may not be the one desired by end-users, it is at least predictable. And because of another limitation, this behavior may be the only one that makes sense. Specifically, there is currently no code for negotiating between and merging selfhosted and extension Ruffle configs. So when the Ruffle extension is injected onto a page that has its own Ruffle config, that config will always be used, and the extension's own config will be ignored.
The above describes how things are supposed to work, but making matters worse is that this is not how Ruffle actually behaves. Ruffle's PublicAPI.negotiate depends on all available Ruffle versions actually being listed in the window.RufflePlayer.sources object. But for some reason I cannot determine, only one of the available Ruffle versions is ever added to this object - either the extension source or the selfhosted source. Also, Ruffle's version negotiation assumes that Ruffle is using semantic versioning (major.minor.patch version numbers), but Ruffle's version numbers currently look like this: 0.1.0.547, with only the last number ever being incremented. Maybe this causes every version of Ruffle to count as the same version and contributes to the problem, but I'm not sure. Even weirder is that the Ruffle source listed in window.RufflePlayer.sources may not actually correspond to the Ruffle version that gets loaded. In testing, I've seen the local source listed as the only Ruffle source, even when the Ruffle extension is what was actually loaded (as seen in the game's right-click menu). This behavior is extremely inconsistent because it depends on whether the extension or selfhosted Ruffle build is first to load, which is a race condition depending on network or cache speed as well as how quickly the Ruffle extension can read its own config and decide whether to load.
In short, the whole thing is a big mess!

[n0samu]

The first thing to understand is that selfhosted builds of Ruffle are properly called selfhosted web builds, not "selfhosted extension."
To answer your original question, the Ruffle Web Demo is actually a bit of a special case because it uses the ruffle-core web build of Ruffle directly, rather than using the selfhosted build or the extension. ruffle-core doesn't know that extensions or selfhosted builds exist at all, so we'd have to add a version negotiation feature to the Ruffle Web Demo from scratch. Right now the Ruffle Web Demo's HTML is marked with data-ruffle-optout, which tells the extension not to run on it. This is just in case someone happens to be using an outdated extension. Like I said, a more complicated version negotiation would need to be coded from scratch, and is prone to errors as I'll try to explain in my followup reply.

[ousia]

Many thanks for your reply, @n0samu.