Hacker News new | past | comments | ask | show | jobs | submit login
Firefox Nightly now plays Amazon.com Flash videos using Shumway (mail.mozilla.org)
249 points by msujaws on Feb 13, 2015 | hide | past | favorite | 105 comments

I'm a program manager on Mozilla's Shumway team. If you have any questions, please ask! :) The name "Shumway" is derived from "Gordon Shumway", the actual name of the TV character ALF: Flash -> Flash Gordon -> Gordon Shumway -> Shumway. :)

Shumway is written in TypeScript. It has an ActionScript interpreter and a JIT that generates JavaScript, compiled using eval(). The code is on GitHub:


Do you fear that by the time shumway actually works for "most ppl stuff" flash would already be gone and the effort wasted? (its gone from YT..)

Yes and no. Shumway is in a race to stay relevant as Flash fades from the web, but there will always be a long-tail of Flash content that would/will be lost when Adobe or browsers stop supporting the Flash plugin.

Even YouTube must continue to support Flash video for at least another year because many websites embedded Flash videos using YouTube's boilerplate embedding HTML with the Flash <object> tag. Google can't magically rewrite these third-party websites' HTML. :) Maybe YouTube can use some SWF that loads or redirects people to youtube.com? Or browsers could recognize YouTube's boilerplate embedding HTML and rewrite it with YouTube's HTML5 video.

This is a serious point though.

Flash, while pretty atrocious, is part of the cultural legacy of the web.

Someday shumway may be the only way reasonable way to access this via archive.org etc.

This is indeed a major consideration: Flash will undoubtedly go away as a player, and if we don't want to lose all the legacy content with it as if it were stored on floppy disks, Shumway or something like it is the only solution.

Note that for a lot of content, it's not even required to use Shumway in the form of a browser extension or built-in system: it's perfectly possible to run SWFs with Shumway as a website-deployed player. E.g., the header on http://areweflashyet.com is deployed that way and works just fine in all modern browsers.

Well, it does not work in Chrome on iOS 7.

>browsers could recognize YouTube's boilerplate embedding HTML and rewrite it with YouTube's HTML5 video.

Browsers themselves don't need to do it. It could be a (very useful) browser extension or a user script.

Here's the user script I use (I've not allowed Flash on my computers since about 2010):


It's not gone from YT! It's certainly on its way out. But despite the announcement I still see Flash as default in Firefox and even in Chrome it sometimes falls back to Flash (happens to me when I start a video, put my laptop to sleep, and continue the video after resume).

It looks like the main change was enabling HTML5 for every video. I haven't had Flash enabled for a couple years – previously many videos (IIRC everything with ads) would display the missing plugin error page. Now it falls back to <video> but since they built it wrong, that only happens if Flash is completely unavailable — any sort of click-to-play will still result in using Flash.

Slight tangent: I've spent the past week experimenting with different kinds of bitmap caching achievable in the browser. Given that you understand both the browser and the way DisplayObjects implement bitmap caching in Flash, I was wondering if you got any clues on how to optimize DOM heavy pages? There are quite a few situations where momentarilly swapping out complex static DOM with a bitmap representation would decrease drawing calls. What I don't know is, to what extent are browsers smart about caching the renders, and when the overhead of caching by canvas would be smaller than default DOM rendering. However, I've had plenty of success in increasing performance, for instance, using canvas to resample images from original to DOM element size, so I'm optimistic about bitmap caching as well.

I'm on a friends tablet now, but I'm looking forward to digging through the implementation later. Keep up the good work!

P.s.: Did you find parts of AS3 beautiful? :-)

I think letting the browser do this kind of caching for you is best in most cases. Developers have used tricks to force browsers to layerize content for many years, and browsers have become better at that over time. Nowadays, it should be fairly simple to isolate complex but unchanging content into its own layer that's cached and composited with the rest of the page instead of being rerendered for each page update.

In Shumway, we do almost all rendering in a Canvas element, so we haven't experimented all that much with DOM-heavy constructs.

As for your last question: I used to work with AS3 on a daily basis in a previous work-life, so I have extensive experience with it. Yes, there are some parts of the language that're very nice. I think that optional static typing is the best of all worlds, for example. The details of AS3's type system leave much to be desired, but the IDE support gained through static typing and the large set of bugs that're far easier to avoid are easily worth it.

Also, declarative classes are, in my opinion much easier to deal with than, e.g., the unstructured alternatives in JS. That's part of why we moved to TypeScript, and I'd argue that it vastly improved the quality of our codebase. I'm very much looking forward to classes in ES6.

Of course there are things that I don't miss about AS3 and regret having to deal with in Shumway. Namespaces are one, E4X the other. Both are good concepts in theory but hugely problematic in practice because of issues in the details.

ALF being FLA backwards obviously. Lovely twisted porte-manteau.

Clever, I didn't pick that up.

That's not a portmanteau though is it? I thought a that was when you joined two words, eg hungry + angry = hangry. Maybe portmanteau has different variations that I'm unaware of - though I know I probably just sound like a pedant.

You're totally right, you're a pedant. JK, I was indeed confused, I don't know how to call a long chain of parallel associations like flash,fla -> flash gordon,alf -> gordon shumway -> shumway. Maybe it's a first.

It's like stream of consciousness, I'd call it serial association rather than parallel. "Sui generis" maybe?

I'd be highly surprised if it were a new software naming method, it's definitely not a new thing of itself.

It was probably a sequence of thoughts, but the flash gordon | alf relationship is parallel, they're unrelated above the convergence point that is shumway.

There was another open-source Flash Player clone called "Gordon" (i.e. Flash Gordon). The founder of Gordon, Tobias Schneider, joined Mozilla to work on Shumway, the successor to Gordon.

Just to clarify, Shumway converts/interprets/executes Flash files as HTML/HTML5?

That is very cool, if so.

Google Swiffy (https://www.google.com/doubleclick/studio/swiffy/) does this too.

That is correct.

Why Typescript, out of curiosity?

In part, the team just wanted to experiment with TypeScript. Also, the language is syntactically similar to AS3 so there is a close mapping from the AS3 library APIs to Shumway's TypeScript implementation.

was there any pain point, at TypeScript side? what do the team think now about their initial decision giving TS a try?

Overall we had a good experience. There were some pain points at first with compile time, but that was greatly improved with the new TS compiler.

Have you implemented support for Real Time Media Flow Protocol?

If so, is it possible to use UDP over shumway?

Yury Delendik on the Shumway team is working on RTMP.js. It's a standalone JS library, but will eventually be used by Shumway.


AFAIK, Shumway does not support UDP sockets, but, as a Firefox extension, it could access Gecko XPCOM APIs that are not available to JS on the web.

I've been using shumway for a while now. Thank you so much for making my web browsing experience lighter and faster. It's a huge improvement.

Congratulations to the team on a promising start! There has been many attempts to implement free flash players, but none turned out to be usable in the real world. Maybe Mozilla has the perseverance to actually pull it off.

I have a question!

>Shumway needs H.264 video decoders that may not be available on Windows XP or Linux.

Is that a reason for Linux users to be annoyed, or just something that happened and will be corrected soon?

Search bugzilla & you should find open tickets. They shipped first for platforms with native support, understandably, but last time I checked the intention was to support everyone.

EDIT: It looks like Linux support shipped in FF26 as long as GStreamer supports it: https://bugzilla.mozilla.org/show_bug.cgi?id=794282#c101

Windows XP is still left out – they use DirectShow for MP3 (https://bugzilla.mozilla.org/show_bug.cgi?id=861693) but using it for H.264 would require a licensed plugin which few people have and while OpenH.264 is available, it doesn't support the Main & High profiles used for most video on the web (it's been focused on streaming): https://bugzilla.mozilla.org/show_bug.cgi?id=799318#c57

It's irritating that they're not just pushing all media through DirectShow, since that's the Windows native framework for doing it and it automatically supports whatever codecs are installed. Their excuse is that they don't have enough control over what codecs users install, which is a bit disappointing.

ffdshow has been able to play H.264 and a bunch of other codecs for a long time, and a not-insignificant number of users probably have that or some other codec that can...

Media codecs are a very common source of security holes, which is one of the main reasons for not indiscriminately using just any codec that might be installed on the system. I think most users value the decision to not unnecessarily expose them to these security holes.

Also, that wouldn't change anything about the current situation: we still can't rely on users having the right codecs installed. We're not saying that Linux and Windows XP won't be supported going forward. They most definitely will. As part of this first small step towards deployment, we opted for a conservative approach where we only enable Shumway in situations we have the maximum amount of control over. This will be broadened over time.

I understand that Prime Instant Video isn't supported (according to the announcement) because Amazon uses Silverlight for that. However, it is possible to switch to Flash as a sort of fallback (this is a required step for, say, streaming PIV to a Chromecast).

What would be required in order to get Shumway to actually play video from PIV (instead of Amazon simply demanding that the user installs Flash or Silverlight)?

The problem with PIV, as with a few other video services, is that it uses DRM. AS you're probably aware, there are some quite unfortunate laws around that which prevent anyone from just offering an alternative implementation of a DRM system. Hence, we can't even try. That's not to say that we won't ever be able to offer at least some support for services like this, there might well be ways to work out something clever.

Isn't EME supposed to address that? Or is that not adaptable to non-HTML5 video (even though this is, technically, HTML5+Javascript that happens to be able to play Flash animations)?

EME is a way to add DRM support to html5 video, but it's not compatible with Flash's DRM system, so can't directly be used to implement that.

Thanks for your hard work!

What's the easiest way to test shumway on arbitrary files? I'm running the latest nightly, but the amazon videos still use flash (tested by checking the right click menu). I've tried the extension in the past, but it never seemed to do anything.

Also, it would be nice if there was, say, a table of common flash APIs coloured by implementation status, for easy tracking of shumway completeness.

Our pleasure! :)

There are two easy ways to test Shumway on all SWF files: if you don't want to use Firefox Nightly, you can just install the extension from http://areweflashyet.com/ and should be all set. If you're using Firefox Nightly, you can simply visit about:config and change the shumway.swf.whitelist setting to "*". Note that you still need to have the Flash plugin installed for most sites to work, as I explained in another comment a few minutes ago.

Regarding the table of supported APIs: the problem with that is that we actually have most APIs implemented, but have compatibility bugs in some of them which break content. If we could easily list the broken APIs, then in most cases we could just as easily fix them. That said, there are some major API areas we don't yet support. Those are mostly related to newer and thus less-used capabilities, such as Flash's version of WebGL, called Stage3D, and a new text layout system called Text Layout Engine.

Am I correct in thinking the face on the site is supposed to be like this one: https://en.wikipedia.org/wiki/Acid2#mediaviewer/File:Acid2_r... , but maybe updated with some of Flash's capabilities?

Yes. It's a variant of Acid2 face. I don't know where that SWF is from originally.

It was designed by the Shumway team as a SWF that uses many of the Flash features. It's full of easter eggs.

Hi thanks for creating Shumway, will it replace flash for all video content or what is the goal of the Shumway project?

Eventually we hope to get to the point where we can play all SWF files and hence have Shumway be a complete drop-in replacement for the Flash plugin. Since implementing full support for all capabilities (and matching all quirks) of a two decades-old platform is a huge undertaking, we're not trying to get there in one big leap. Instead, we're gradually widening the set of supported content so we can get to something useful to end users sooner.

Have you thought of working with some of the other open source flash implementations on compatibility tests ?

I'm guessing that lightspark must already have some tests, and from your side there are probably some they could use too ?

We're looking at tests and sometimes implementation details from the other open source projects, yes. E.g., we've used the SWFDec tests extensively in our work on the older AVM1 language runtime.

Will we see it for other browsers? Soon?

The Shumway interpreter and JIT work in other browsers, but the installable extension to replace the Flash plugin as the default SWF handler is currently Firefox-only. But pull requests are welcome! :)

You can try Shumway in other browsers without the extension at the project website:


The SpiderMonkey team's "Are We Fast Yet?" website also includes some AS3 benchmarks running in Shumway on Firefox, Chrome, and Safari:


I'm one of the developers on the video player used on that page. Great work guys!

Edit: I should add in, the player is primarily Javascript with a small rendering engine for Flash fallback. Even in the Flash case, everything is controlled via JS through a flash bridge. We prioritize HTML5 video when possible across browsers and devices.

maherbeg: thanks!

Our team was uncertain how to reach at Amazon to get your blessing. :) If you (or Amazon management :) have any problems or concerns, please feel free to email me at cpeterson at mozilla dot com!

re HTML5 video: do you use it on desktop browsers? Mozilla is working hard to improve our HTML5 video implementation. Can we opt in Firefox for HTML5 video? Playing Flash videos in Shumway is just a stepping stone on the path to HTML5 video.

We do allow HTML5 video on Firefox for Windows. On Mac, we disallow it.

We feature detect everything but have been prioritizing Flash at the moment due to issues with Chrome and HTML5 video.

> * We do allow HTML5 video on Firefox for Windows. On Mac, we disallow it.*

Interesting. Is HTML5 video the default on Firefox for Windows or only used when Flash is not installed? (I only have a Mac.)

Have you found specific Firefox problems with HTML5 video on Mac? Feel free to email me if you have questions for Firefox's video team about debugging or optimization. They are friendly folks. :)

Sounds like Shumway is already further along than Gnash or Lightspark.

What versions of SWF does Shumway aim to support? 7, 8, 9, 10, all of the above?

How does Shumway interact with click-to-play and similar mechanisms to stop unwanted Flash objects from playing? Does it have that functionality built-in?

Shumway is implementing APIs as needed, not targeting a specific SWF version.

Shumway does not currently support click-to-play because it is not a real browser plugin. It hooks into Firefox's click-to-play mechanism to conditionally override the Flash plugin. This is a hack and will soon be replaced with "jsplugins", a Firefox feature that will allow browser plugins to be written in JS and run in an out-of-process sandbox:


Will this be more secure than Adobe's Flash, since that already runs in a separate process?

Since it won't be native code, they'll only be able to abuse a FF bug exposed by the JS plugin API, but should be in a very bad position to exploit a kernel bug...

Same process isolation, but the JS plugin got a vastly reduced surface to attack.

Exactly. We did a survey of Flash exploits from the last few years and almost all of them would simply have been impossible in Shumway. That doesn't mean that Shumway will automatically free of all security bugs, but the whole class of bugs that in some way is caused by memory corruption is only possible through bugs in Firefox's JS engine SpiderMonkey. Of course it's much easier to just exploit them in JS directly then, so Shumway doesn't increase the surface attackable through bugs like that.

Considering this specifically states video and not flash in general I would imagine none of the above. Please correct me if i'm wrong though.

I think you've misunderstood the context of the title. It's in reference to a milestone being reached (ie Shumway now supports playing Amazon.com videos) rather than Shumway's end goal.

From the discussion on HN, it sounds like Shumway aims to be a drop in replacement for Adobe's Flash plugin.

Cool tech, but I'm a bit sad that I can't watch Shumway[1] using Shumway.

[1]: http://www.albinoblacksheep.com/flash/shumway

You actually can; I'm doing so right now. However, you need to install the full Shumway extension from http://www.areweflashyet.com/shumway/ (the stripped-down version shipping in Nightly is limited to Amazon only).

If you use Shumway, though, don't forget to disable Adobe's Flash (I've found that having it enabled and Shumway installed results in rather brutal crashes).

Can you give steps to reproduce this crash? It should definitely not happen. In fact, until https://bugzilla.mozilla.org/show_bug.cgi?id=558184 is implemented we rely on an installed Flash plugin to make the Flash detection used by most sites work.


0) Have a Macbook Air running OS X Yosemite

1) Install Firefox

2) Install Adobe Flash

3) Install Nightly

4) Install Shumway

5) Attempt to open http://www.albinoblacksheep.com/flash/shumway

6) Watch Firefox complain that the tab crashed

7) Try to reload the tab

8) GOTO 6

Disabling Flash (via the Addons screen in Firefox/Nightly) seems to fix the issue.

How do you go from swf files to "action script"? Do you use flasm/flare for as2? How do you turn as3 abc files into action script? Did you write your own decompiler or use some other open source ones? There's a disassembler written in D for as3 that I used to use called rabcdasm, did your team ever take a look at that?

Shumway doesn't decompile ABC bytecode to ActionScript, it compiles it to JavaScript, which is then evaluated. It has a from-scratch JIT engine that analyzes the bytecode and generates JS.


I've worked a lot with Flash bytecode and contributed to Shumway a long time ago, so if you have any more questions, let me know!

> There's a disassembler written in D for as3 that I used to use called rabcdasm, did your team ever take a look at that?

RABCDAsm author here. Curious about the same, I've always thought the project might be useful to VM implementers. Also wondering if you've had trouble with obfuscators that employ control flow obfuscation, and create unreachable basic blocks with junk code.

Yes, definitely! SWF obfuscators are a problem because they rely on undocumented behavior and implementation details of the Flash plugin that the Shumway developers must debug and support to maintain compatibility. Obfuscated AS1 code can do strange things like jumping to unaligned SWF addresses in the middle of bytecodes.

> Obfuscated AS1 code can do strange things like jumping to unaligned SWF addresses in the middle of bytecodes.

Oh, I've seen much worse. The AS1 VM actually treats the entire SWF file (after decompression) as an AS program. That means it's possible to jump outside of the bytecode tag and into e.g. the metadata of a JPEG file.

Reminds me of one highly-regarded (at the time) obfuscator whose operation consisted entirely of renaming the existing bytecode tags to a reserved value, and adding a bytecode tag after it with lots of useless code including opaque predicates which eventually jumped out of the tag, backwards, into the original code. A bit of a letdown as I was looking for a challenge at the time, but that jump out of the tag was sure easy to detect and unobfuscate...

(This is something that is still not fixed in Gnash, so Shumway is certainly farther along.)

We can detect when bytecode is not well formed and fall back on interpretation, which can handle these nasty cases. This is more of a problem for AVM1 than AVM2.

Thanks for the great tool, we used it quite a bit when we first started working on Shumway.

Shumway falls back on an interpreter if the control flow is not reducible.

Does anyone have experience trying this with Firefox on PowerPC or ARMHF Linux? These platforms don't have any working Flash versions from Adobe...

I'm wondering the same. I have a PowerBook G4 running OpenBSD 5.6 that I suppose I could test with, though Firefox has traditionally been pretty slow on that particular machine.

I just tested against Firefox Nightly on the amazon pages and it doesn't appear to be even loading the Flash renderer.

We feature detect flash via the navigator.plugins object and from that thread it doesn't look like shumway is listed there.

(I'm a dev on that player)

(Shumway tech lead here)

Somewhat absurdly, you currently need Flash to use Flash without Flash in many cases. We don't yet have support for installing Shumway in navigator.plugins, so sites that detect Flash using that (i.e., most of them) currently only work in Shumway if Flash is installed, too.

This will be fixed once https://bugzilla.mozilla.org/show_bug.cgi?id=558184 lands.


The single content process is an interim step until electrolysis development is further along.

> "Note that Shumway will not play Amazon's "Instant Video" films and TV shows. Those videos use Microsoft's Silverlight plugin for DRM."

Amazon Instant Video can also use Flash. See "Player Preferences": https://smile.amazon.com/gp/video/settings

Thanks! I didn't know that. I just tested an Amazon Instant Video in Shumway, but the video fails to load because Amazon's video player uses some Flex libraries that Shumway doesn't support yet.

Tried it on Arch Linux + Firefox v35 works smoother than flash plugin. Used AUR package here: https://aur.archlinux.org/packages/firefox-extension-shumway... Can't wait for this to replace everything flash. Thank You, shumway team :-)

I'm waiting until they get JWPlayer working. So many sites still use it.

JWPlayer support is difficult because there are many JWPlayer variants and old versions out there. It's easier to test and whitelist individual websites to start.

Why bother emulating it, though? If you can recognize it, and recognize that it's not using any unusual settings, you could potentially just replace the whole thing with a native video player.

That's a good question. Video is just one use case for Shumway. This specific use case might be better supported by rewriting Flash <object> tags with an HTML5 video player, but Mozilla dislikes adding hacks to workaround site-specific quirks. The hacks are technical debt carried by Firefox on behalf of websites that don't bother to maintain themselves. Mozilla even removes moz- prefixed DOM APIs and CSS attributes when the standardized, unprefixed name is supported.

Sounds like a perfect use case for an addon then!

That might be a good pull-request for something like No Flash to test it on a larger scale:


Only somewhat related, but is there still no way to access the clipboard in a web app without flash?

Imagine a web where you could just write to the users clipboard without a plugin + requiring a click.

It would NEVER be safe to Ctrl+V again!

The requiring a click part is the only relevant implementation detail for this functionality, in my opinion. Whether or not it requires a plugin shouldn't matter.

In fact, requiring a plugin for this functionality only serves to increase the attack surface for the browser as a platform.

Flash code can read clipboard from Flash/browser i.e. it can run in background and silently and continuously collect contents of clipboard? If so then it should be rightfully classified as spyware and purged from every computer.

I think Flash only allows SWF content to access the clipboard in response to a user click.

GitHub's "copy repo URL to clipboard" button uses Flash to write to the clipboard. Shumway has implemented Flash's clipboard APIs (which it can do because it can access Gecko XPCOM APIs as a Firefox extension), but they are currently disabled because Shumway hasn't implemented the "in response to user click" bit yet.

There is a W3C spec for a web clipboard API but I don't know if any browsers have implemented it:


Thanks for pointing me to this! Glad to know it's at least something being actively considered.

This is so cool, so more need to install hal?

Verified@Twitter.com Bass word

> Shumway needs H.264 video decoders that may not be available on Windows XP or Linux.

Today I learned that Firefox still supports Windows XP.

About 25% of Firefox Windows users run Windows XP.

Is that a real number? I've seen a huge decrease in Windows XP users over the last year, from almost 20% to bellow 10%. But that was for different product, so I'm wondering if FF got it this bad.

Yes, though I don't have a public source for it. I don't know why Firefox's OS version statistics are not public. Wikipedia says 49% of computers in China run Windows XP: https://en.wikipedia.org/wiki/Windows_XP#Support_lifecycle

Microsoft added its "Genuine Windows" copy protection in XP SP3, so XP SP2 is especially common. (Firefox supports both XP SP3 and SP2.)

This is a myth actually, and I hope they can kill XP SP2 support in 2015. At least getting rid of the SHA1 cert at the download site at the end of 2015

Yes exactly and from my experience it's really the best browser available on Windows XP.

I've even seen myself a Windows XP with Firefox installed in a shop just a few days ago.

Out of curiosity, what are the options on Windows XP? IE 8, Opera 12?

In 2013, Google said they would support Chrome on Windows XP until at least April 2015:


Chrome works fine, too.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact