Please don't die: collection of typos

[ivanpopelyshev]

I know that project is not maintained, I'd like to adopt it.

[ROBERT-MCDOWELL]

I think it's a good initiative yes, and for sure dozen of developers will join if there is a good dynamic...

[ivanpopelyshev]

I've already ported it to latest TS with no-implicit-any settings in a different branch.

[TriMoon]

Keep up the good efforts, just letting you know i also keep an eye on this 😉

[ivanpopelyshev]

@TriMoon here's branch typescript 2.6, just conversion that somehow breaks 1 test: https://github.com/ivanpopelyshev/shumway/tree/ts2

I have more branches but they're for heavy refactoring.

[ComFreek]

@ivanpopelyshev Thank you for your continued effort in this project! Since I am personally interested in the future of it as well, I hope for it to attract many developers. In my opinion, one necessary condition for this are good commit messages, which are consistent (e.g. I quite like Angular's (chore), (doc), ... style guide), serious and helpful 😄 (Yeah, I know the feel - sometimes thinking of a good commit message takes longer that the code fix itself.)

@mbebenita @yurydelendik (I hope you are the maintainers, judging from your contributions): Are there any plans to (continuously) accept PRs or would it be better - in your opinion - to move all the work onto a fork (i.e. @ivanpopelyshev's fork)?

[ExE-Boss]

I’m building a WebExtension in my own fork (see issue #2435 for details), but it’s unfortunately somewhat blocked by bugs that block bug 1451083.

[ivanpopelyshev]

@ComFreek

https://github.com/pixijs/pixi-swf http://pixijs.io/pixi-swf/demos/ninja-cat.html http://pixijs.io/pixi-swf/demos/ninja-cat.js https://github.com/open-source-flash/open-source-flash/issues/107

And I'm cooperating with @yurydelendik

@ExE-Boss

Wow, that's good!

[WeanedVitriolic]

@ivanpopelyshev

Hey dude, I'm a big fan of flash and have been bummed out over these big companies deciding that everybody should just drop flash in 2020. But you give me hope for flash to remain on the web! What's important is not the flash plugin itself after all, it's the flash format.

Will Pixi-SWF be able to play unmodified .swf files as they are? Or do you need to convert the .swf files to something else before they can be played?

@ExE-Boss

A WebExtension version of the flash plugin also sounds awesome, is it correct to assume that the plan is to be able to playback unmodified .swf files with it?

[ivanpopelyshev]

@WeanedVitriolic Thank you!

I removed AVM for now, it'll be and option later (for debug purposes). That means it cant use the ABC blocks from SWF, and you need to port your AS3 code to typescript, Shumway Flash API is almost the same. All SWF files should be loaded dynamically through good old flash.display.Loader mechanism.

The project goal is to help to migrate projects to TypeScript, without extra difficulties like convert your SWF to our awesome json format, convert shapes to shitty SVG, and, my favorite, convert all vector to shitty raster and put inside an engine with completely different API

There's also commercial part that helps to convert HUGE applications.

[ExE-Boss]

@WeanedVitriolic

A WebExtension version of the flash plugin also sounds awesome, is it correct to assume that the plan is to be able to playback unmodified .swf files with it?

The goal is to provide a fully compatible replacement for the legacy Shumway extension, which installs itself as a plugin that can play unmodified Flash files (currently only .swf, not .spl, which is a FutureSplash Movie, and isn’t widely used or known about, might be DRM) with a higher priority than Adobe Flash Player, which works by loading an HTML document into the <object> or <embed> element and asynchronously passing it a reference to the Flash file and <param> data to load.

Since I can’t currently do that (unless bug 1451983 (duplicate of bug 1356397) gets implemented), I need to create an <iframe> that points to the Shumway extension’s main file and pass it the same information, but since <iframe>s leak the extension UUID through the src attribute (see bug 1372288), I have to use closed Shadow DOM to hide the <iframe> from the web page (since the reference to the ShadowRoot is inside the extension script scope, the webpage can’t access it), another issue is that extension pages loaded in <iframe>s only get content script scope/permissions (see bug 1443253).

Since I’m using Shadow DOM, I might possibly end up using the Custom Elements <shumway‑object> and <shumway‑embed> that provide a compatible API with <object> and <embed>, but I would prefer to see bug 1356397 fixed.

[ComFreek]

The project goal is to help to migrate projects to TypeScript

Actually, I wished for a drop-in JS tool for Flash to run SWFs (and eventually Java applets as well) seamlessly on the many sites which either provide valuable information/simulations not easily found somewhere else (usually with academic background) or have some nostalgic games. In both cases, the SWFs are usually not maintained anymore meaning there is no one to port it to TypeScript - except me. If it's not an on-the-fly converter, then I am not sure if it is worth for me to convert these SWFs at all.

It might well be the case that your user audience is different, namely customers wishing to port their old SWFs with minimum effort.

[ivanpopelyshev]

Ok, got it.

1. I'm gonna patch original shumway anyway
2. My fork has optional AVM3, no support of AVM2

If you dont want to rewrite code to Javascript/Typescript, 1st option is still available. But I certainly would not work on optimizing virtual machine, only the renderer and stage.

[ROBERT-MCDOWELL]

I think it's better for you all to invest your time, brain and imagination to webassembly git which will become the standard of binary on the web to run any kind of compiled application, Flash included. Also you have apache as-js which is the last version of flex

[ivanpopelyshev]

@ROBERT-MCDOWELL.

The longer is the toolchain, the more problems it introduces. Its not clear to me how is it supposed to solve fundamental problems of flash runtimes.

Our main problem is a runtime and API's, not the language nor VM.

[ROBERT-MCDOWELL]

• ivanpopelyshev
• Our main problem is a runtime and API's, not the language nor VM runtime and API won't change with webassembly... If Adobe, Google, Mozilla abandonned shumway that's because webassembly will be much more efficient and easy to compile in one bucket.

[WeanedVitriolic]

@ivanpopelyshev

Sounds like Pixi-SWF won't be able to play unmodified .swf files as they are, thanks for clearing it up and good luck with your convert tool!

@ExE-Boss

Your WebExtension project does on the other hand sound like it will be able to play unmodified .swf as they are. Looking forward to it!

@ROBERT-MCDOWELL

As long as people will be able to play old .swf files in their browser somehow I'm happy. There's 100s of thousands of .swf files and I don't think anybody will put the energy into converting them all so I really want there to be a way to play the original unmodified flashes in the browser.

No classic animation or game should be lost, they all helped make the web what it is today and deserve to stay online forever. Doesn't matter if it's through WebExtension, JavaScript or WebAssembly as long as it works without conversion. :)

[WeanedVitriolic]

@ExE-Boss

I saw that https://bugzilla.mozilla.org/show_bug.cgi?id=1356397 was updated a day ago:

The request to support content handling through registerContentHandler has been denied because this API was only limited to feeds, and it has been removed. Content handling as a feature was accepted, and its implementation is tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1457500 All feedback from this bug and its related duplicates are taken into account.

Since there was both a deny and an accept in there would you mind clarifying what this means for your WebExtension? Does this mean you're able to continue the project or was it bad news?

[ExE-Boss]

Since there was both a deny and an accept in there would you mind clarifying what this means for your WebExtension? Does this mean you're able to continue the project or was it bad news?

Based on my understanding, Mozilla intends to implement a better API than what would essentially just be an alias for registerContentHandler(…), which was already removed from the Firefox codebase anyway.

[WeanedVitriolic]

@ExE-Boss

So good news then? :)

[ExE-Boss]

@WeanedVitriolic Yes:

(In reply to Rob Wu [:robwu] from bug 1457500 comment #3)

(In reply to ExE Boss from bug 1457500 comment #2)

Will this be implemented in a way that would allow for WebExtensions to act as plugins (like what I outlined in bug 1451983)?

Yes. The extension should be able to handle content, regardless of whether they are directly loaded in a tab, or embedded through <embed>, <object>, <frame> or <iframe>.

[WeanedVitriolic]

@ExE-Boss

Awesome! I'll keep an eye on your project over at https://github.com/ExE-Boss/mozilla-shumway/tree/web-extension/extension/webext

I hope you'll be able to pull it off!