Internet Archive enables Ruffle on SWF pages

[Mæstro]

One could regard this as a sequel to the resolved matter wherein the Archive would automatically substitute Ruffle on websites. The problem seems separately to occur when one accesses in the Archive pages ending in .swf. The measure described in the other thread simply causes the page to appear blank. How can I disable Ruffle on these pages also, so I can play normally?

[Moonchild]

I think you'll have to ask archive.org to allow standard plugin embedding in that case; they are literally replacing the swf with a web page so there won't be an easy way to directly get the swf at the source of it then.

[Mæstro]

In fact, there is an easy way. Credit is again to my sister for discovering how: a regular expression in URL Redirector, including https://web.archive.org/web/(.*)if_/(.*).swf(.*) and redirecting to https://web.archive.org/web/$1oe_/$2.swf$3. This complements the measures in the original post to restore SWF function. I will add this to the relevant tutorial.

[craniumcadoo]

Fun fact, Ruffle works on Pale Moon nowadays. The problem is the Internet Archive uses an outdated version of Ruffle from before https://github.com/ruffle-rs/ruffle/pull/15377.

Still, it would be better if this page didn't use Ruffle on Flash-enabled browsers. I'd think https://github.com/ruffle-rs/ruffle/pull/11407 would have covered that, but the Internet Archive does some very funky stuff to make itself work with Ruffle, so something they're doing must affect this.

[craniumcadoo]

I'd think https://github.com/ruffle-rs/ruffle/pull/11407 would have covered that, but the Internet Archive does some very funky stuff to make itself work with Ruffle, so something they're doing must affect this.

Ah, it's a very simple reason. They replace the SWF with a page that uses the Ruffle API. That PR only affected polyfill usages of Ruffle. If you use the API, Ruffle ignores Flash support for obvious reasons. It would technically be possible for Ruffle to create a normal embed when the API is used on a browser with Flash support, but it's generally been considered not worth the effort, as if you use the Ruffle API it's assumed you want to use Ruffle itself.

[Moonchild]

but it's generally been considered not worth the effort, as if you use the Ruffle API it's assumed you want to use Ruffle itself.

It's ultimately because they want people to use their tech and not what they are trying to emulate. Never mind that Ruffle is incomplete.

[craniumcadoo]

It's ultimately because they want people to use their tech and not what they are trying to emulate.

Well I opened https://github.com/ruffle-rs/ruffle/pull/16523 to fix this. We'll see what the general opinion is on it. It admittedly is a bit awkward to add that much code just to do something under these circumstances:

Code: Select all

this.loadedConfig.favorFlash && isFlashEnabledBrowser() && "url" in options

The this.loadedConfig.favorFlash ensures that there is a way for a developer who wants to specifically use Ruffle to use it even in browsers with Flash support (I have spoken with a few developers in the Ruffle Discord server who have stated that their new games are faster with Ruffle because they used more of the things Ruffle handles better than Flash and less of the things Flash handles better than Ruffle when designing those new games).

The Ruffle API has two ways to load Flash content with the load function, by url or by data stream. There's no equivalent for Flash Player to loading by data stream, so if that's the option you use in the API, Ruffle has to use its own emulator.

isFlashEnabledBrowser() is the same function used to stop the polyfill on Flash-enabled browsers. It checks this, and on a Linux browser with Flash such as Pale Moon this returns true since libflashplayer.so !== "ruffle.js":

Code: Select all

(navigator.plugins.namedItem("Shockwave Flash")?.filename ??
            "ruffle.js") !== "ruffle.js"

[craniumcadoo]

Code: Select all

Never mind that Ruffle is incomplete.

You're welcome to contribute. It's very hard to emulate Flash using just modern web APIs without access to NPAPI, so imo it's amazing how far Ruffle has already come.

[Moonchild]

You're welcome to contribute. It's very hard to emulate Flash using just modern web APIs

I''m sorry but I have no interest in contributing to it. It's only necessary because the powers that be unilaterally decided to short a huge flash community instead of keeping native binary plugin support. My support for the Flash community is there in maintaining NPAPI plugins in UXP/Pale Moon. The modern Web APIs have their limits. However, as far as I understood this has more to do with actionscript than with using Web APIs, so I'm not even sure what your point is here.

[craniumcadoo]

as far as I understood this has more to do with actionscript than with using Web APIs

It's a few things really. One is that it's hard to reverse-engineer Flash to make sure everything works properly and the official documentation lies frequently and the closest we have to source code to analyze is avmplus which is not a complete implementation detail. The source code for Flash has probably leaked but using that would get us in legal trouble. But another issue is reimplementing everything in Rust with backend code to handle functionality as identically as possible on desktop on Windows, Mac, and Linux, web with WebAssembly, and even the new Android backend.

A few issues encountered due to needing to support web are XMLSocket support, which on desktop we can and do support automatically but since browsers don't allow direct socket connection to support this on web we need to ask webmasters to configure a WebSocket proxy using something like websockify to support (https://github.com/ruffle-rs/ruffle/wik ... om-the-web), supporting system fonts, which on desktop we can support natively but on web since the Local Font Access API was only ever implemented by desktop Chrome we need to ask webmasters to configure the page to pull fonts from a new SWF made just to embed fonts not directly embedded by the original SWF (https://github.com/ruffle-rs/ruffle/wik ... my-website), and there's another more recent issue that has been encountered and there is a recent PR and other local code changes that aim to address it: Support for H.264 video, which is still under several patents. To support that on Desktop, we are planning to use OpenH264, as seen in https://github.com/ruffle-rs/ruffle/pull/14654, while on web there is a plan to support it with the brand new VideoDecoder API using WebCodecs, but since that's unsupported on Firefox (for now) and on http pages, there is a plan to fallback to a hack with video and canvas elements (that plan is to remux NALU to fMP4, attach the MediaSource to a <video>, draw that <video> onto a <canvas>, capture that <canvas> into imageData, and copy the data out of the image)

[moonbat]

craniumcadoo, use the quote button, not the code block one when quoting someone. It's the 4th button from the left in the post editor.

[craniumcadoo]

Well I opened https://github.com/ruffle-rs/ruffle/pull/16523 to fix this.

Things seem to be leaning towards not landing this PR. I can't say I necessarily disagree. The Ruffle API already has a few bits of functionality that differ from Flash. For example, you can do

Code: Select all

player.volume = 0.5;

to set the volume of the SWF to half its initial value (on a logarithmic scale akin to human hearing). Another example is that when Ruffle is done loading an SWF it fires the loadeddata event, and some webmasters therefore wait for that event before doing something else. Additionally, there are plans to version the API and add even more QOL functionality that did not exist for Flash Player. If we fell back to a Flash embed some of a webmaster's code may not do anything if they used the API for functionality that didn't exist in Flash. Also, there is a Ruffle configuration option, playerRuntime, which when set to "air" is meant to allow you to embed an AIR SWF in the browser (even on mobile browsers, since Ruffle uses technologies that work on mobile). Currently, Ruffle still doesn't support most AIR APIs, but there are plans to improve that support, and if someone used the Ruffle API to load an AIR swf in the future, even Flash-enabled browsers wouldn't be able to load it without Ruffle.

Instead, we should just emphasize that webmasters should use the embed/object elements with the polyfill if their only purpose in using Ruffle is to embed Flash, which we already mention as the preferred method for non-advanced users. The same applies here. Nothing the Internet Archive does here required the use of the API, but for some reason they used it, and this is just the unfortunate result.

[Moonchild]

Nothing the Internet Archive does here required the use of the API, but for some reason they used it, and this is just the unfortunate result.

Unfortunately it is also true that most people consume flash content through the internet archive. So, as I said before, the internet archive should allow NPAPI plugin use. I'm not really sure who is in the best position to convince them of this.