-
Notifications
You must be signed in to change notification settings - Fork 396
Missing features
Shumway doesn't implement all of Flash's features yet. The following is a list of missing features, their impact on our initial, banner ad-focused, release, and our plans for them.
Flash contains support for screen readers that allows authors to associate display elements with names and descriptions to be read out by screen readers and tab ordering.
Little, banner ads aren't usually accessible. (I.e., I'm not aware of a single one that is.)
Medium
We might implement this on top of browsers' accessibility support for a later release.
Worker threads with synchronous communication capabilities.
None, we haven't encountered any banners using this.
Very large to infeasible.
We don't plan to ever implement this.
Support for AS3-implemented crypto algorithms.
None, we haven't encountered any banners using this.
Small
Would be easy to implement on top of crypto.RandomSource.getRandomValues().
Support for interacting with the system clipboard.
None, banners don't (or at the very least mustn't) use the clipboard.
Small-ish for copy-only, medium for paste, large for complex, app-defined data types.
Will implement support for setting clipboard values eventually. More extensive support not currently planned.
Quite a few methods of the BitmapData class are currently just stubbed to prevent exceptions from being thrown but don't actually contain the required implementation.
Incorrect rendering for some banners: some of these are used for visual effects.
Medium for some, large for complete coverage.
We'll implement some of these before shipping and add telemetry for the others to gauge their relevance.
Object-oriented API for vector drawing.
Little, we haven't encountered banners using this.
Medium
Not currently planning to implement this in the near term. Wouldn't be all that hard, though.
Support for rendering and encoding JPEG-XR images.
Little to none, we haven't encountered these in banners.
Large to infeasible: only IE supports this format so we'd have to have our own decoder, and I'm not aware of any we could use. See Firefox bug 500500 - (JPEG-XR) Add support for JPEG-XR/HD Photo.
No support planned.
GPU shaders to be used in Stage3D and ShaderFilter.
Little to none, we're not aware of any banners using this.
Medium to large: JS implementations of this exist under amenable licenses and might be usable.
No support planned, but might change our minds.
GPU-accelerated 3D rendering, somewhat similar to WebGL.
Little to none, we're not aware of any banners using this.
Large to infeasible: JS implementations of this exist under amenable licenses and might be usable, but even that would be a lot of work.
No support planned.
Filters that can be applied to parts of the DisplayList to affect rendering.
Medium, some banners use filters we haven't implemented.
Medium to large: some filters can be implemented on top of the ones supported by SVG filters, some would have to be implemented in JS.
We plan to support some more of these and add telemetry for the rest.
2.5D transforms similar to those available in CSS.
Medium, these are used by a small but significant fraction of banners.
Medium for a partial implementation, very large for complete coverage.
Plan to implement a simple approximation of this before shipping: full support of the API in AS3, rendering only applied for z-index and rotation around a single axis and without full perspective correctness. In progress.
Framework for localizing content depending on the user's locale, similar to EcmaScript's Intl support.
Little to none, we're not aware of banners using this.
Large to infeasible, depending on how well this matches the capabilities of the Intl class.
No support planned.
Support for most advanced audio usage
Little, banners don't usually use audio, and it's not clear we'd want them to.
Medium to large, depending on coverage.
Small enhancements and bugfixes plans, but no substantial increase in functionality.
Video streaming, timeline-embedded video, advanced usage of non-streaming video.
Medium, a small but significant fraction of banners use video.
Medium to large, depending on coverage.
Plan to support timeline-embedded video and generally improve handling of video. Streaming not currently planned, but doable and interesting for video players.
VP6-encoded video playback.
Medium, largely see above.
Medium for a Flash plugin-based polyfill (exists, but needs fixes to fully work), large to infeasible for full standalone support, depending on licensing concerns.
Plan to complete Flash plugin-based polyfill before shipping.
Support for video decoded directly to a GPU surface, layered below all other content.
Medium, probably used by some ads, mostly with a fallback to normal Video, though.
Medium, mostly plumbing for the AS3-facing APIs. Our Video implementation is actually closer to StageVideo in functionality.
Unclear, we might want to implement this before release.
Microphone and Camera access.
None, not used by banners.
Medium to large, depending on coverage.
No support planned.
Support for RTMFP P2P networking.
None, not used by banners.
Large.
No support planned.
Support for streaming video
Little, we're not aware of banners using this.
Medium to large
A prototype implementation of an RTMP client library exists, but isn't production quality. Getting it there would probably be some work, still, which we don't currently plan on doing for our initial release.
Connecting to raw TCP sockets
None, not used by banners.
Medium
No support planned. Only feasible in the extension for now, as sockets aren't yet available to general content.
Support for DRM'd media playback
None, not used by banners.
Infeasible to implement.
No support planned (or possible, really).
Support for printing static or dynamically created content.
None, not used by banners.
Large
No support planned.
Access to accelerometer data.
None, not used by banners.
Medium
No support planned.
Support for interacting with the system's IME
None, not used by banners.
Unknown
No support planned. If we decide to support text input, we should do it in a way that makes the browser just handle this.
Hardened implementation of SecurityContext that we trust to properly prevent content from different sandboxes from accessing each other.
Medium, some banners load content from other domains, and hence into other SecurityDomains.
Large for a trusted implementation.
We mitigate this by enabling loading of other SWFs only if the loading SWF is allowed to also load arbitrary data from the same host. If it can do that, it could also load the child SWF as data and run it in its own domain, circumventing the SecurityDomain protections. Vague long-term plans for additional support exist.
Text input.
None, banners don't use this.
Medium
No support planned.
Sophisticated low-level text layout support.
Little to none, almost no banners use this.
Large to infeasible
No support planned. Would be required for Flex 4 applications and some games, though, notably King.com games.
Support for customizing the context menu.
Little, banners either don't use this or don't rely on it for their main functionality.
Medium
No support planned.
Support for setting the mouse cursor to a builtin one or a provided bitmap.
Very little, banners almost never use this.
Little for bultin cursors, medium to large for custom bitmaps.
No support planned.
Support for multi-touch events
None, banners don't use this.
Unknown
No support planned.
Mozilla 2019