https://wiki.mozilla.org/NPAPI:Pepper states that
"Mozilla is not interested in or working on Pepper at this time" but given Adobe's recent Plugin roadmap (http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/flashplatform/whitepapers/flash-runtimes-roadmap.pdf) which states:
"For Flash Player releases after 11.2, the Flash Player browser plug-in for Linux will only be available via the “Pepper” API as part of the Google Chrome browser distribution and will no longer be available as a direct download from Adobe. Adobe will continue to provide security updates to non-Pepper distributions of Flash Player 11.2 on Linux for five years from its release. Flash Player will continue to support browsers using non-“Pepper” plug-in APIs on platforms other than Linux."
So without pepper support Linux users would be stuck to a specific flash plugin version at some point, with pepper they could at least get the one shipped with chrome.
It is kind of unfortunate to tie the plugin to a specific browser like this but the other alternative would be to just have leave linux users with an outdated plugin forever or force them to switch away from mozilla / firefox.
Note that the announcement says that Flash will only be available as part of Chrome, not that they will have a standalone Pepper-based plug-in you can download and use with Firefox.
So even if, hypothetically, we were to implement Pepper, it wouldn't help anyway as far as I can tell. Users would still not be able to use it.
And also note that "outdated" means "no new features", not "no security fixes". Which may or may not be a serious issue.
We are not going to do this, at least that is our decision as of right now. It isn't likely to change. I should update the wiki to more accurately reflect that. This has been discussed in multiple places, here is one conversation that reflects some of our reasoning.
(In reply to Boris Zbarsky (:bz) from comment #1)
> Note that the announcement says that Flash will only be available as part of
> Chrome, not that they will have a standalone Pepper-based plug-in you can
> download and use with Firefox.
> So even if, hypothetically, we were to implement Pepper, it wouldn't help
> anyway as far as I can tell. Users would still not be able to use it.
Well the plugin shipped with chrome could then be used if we had support for pepper plugins.
(In reply to Josh Aas (Mozilla Corporation) from comment #3)
> We are not going to do this, at least that is our decision as of right now.
> It isn't likely to change. I should update the wiki to more accurately
> reflect that. This has been discussed in multiple places, here is one
> conversation that reflects some of our reasoning.
Well that made sense back then but now at least for linux there is a reason for supporting it but oh well ...
Linux users will either have a choice of using 1) no flash 2) use an outdated version and just get security updates until adobe stops supporting it 3) move to chrome or 4) convince adobe to continue providing an NAPI plugin.
As 4) is very unlikely I suspect users will resort to 2 or 3.
> Well the plugin shipped with chrome could then be used
Are you sure? That's not a given at all...
For what it's worth, I suspect that (2) is a perfectly reasonable thing to do, since the chances of running into a site that actually needs new Flash features are pretty slim.
(In reply to Boris Zbarsky (:bz) from comment #5)
> > Well the plugin shipped with chrome could then be used
> Are you sure? That's not a given at all...
Pretty much yeah ... it is is still a plugin after all.
> For what it's worth, I suspect that (2) is a perfectly reasonable thing to
> do, since the chances of running into a site that actually needs new Flash
> features are pretty slim.
Sure but what after the the support period? Flash isn't known for having a good security track record and without updates ... . And also linux is a moving target an old flash might simply stop working in newer distributions.
There are a few more options
5) use gnash or lightspark
6) use shumway
Any time spent on implementing pepper could be spent on improving any of those.
> it is is still a plugin after all.
That really depends. For example, the plug-in could be checking for the browser having a specific private key and various other such DRM-like measures, if it wanted to.
> Sure but what after the the support period?
You mean in 5 years? I suggest talking about that in, oh, 3 years or so. Strongly depends on how Flash usage looks then.
(In reply to Mike Hommey [:glandium] from comment #7)
> There are a few more options
> 5) use gnash or lightspark
> 6) use shumway
> Any time spent on implementing pepper could be spent on improving any of
Not really no.
(In reply to Boris Zbarsky (:bz) from comment #8)
> > it is is still a plugin after all.
> That really depends. For example, the plug-in could be checking for the
> browser having a specific private key and various other such DRM-like
> measures, if it wanted to.
Sure they could but there roadmap does not state this and this is very unlikely to be there goal. They could as well go bankrupt next year ... speculating does not make much sense ;)
> > Sure but what after the the support period?
> You mean in 5 years? I suggest talking about that in, oh, 3 years or so.
> Strongly depends on how Flash usage looks then.
Unfortunately as long as the Codec and DRM issue is not solved flash isn't going anywhere.
This should not just be discussed in the context of Flash, but more generally: Pepper is a set of Google technologies that is being pushed as a replacement for many parts of the Web platform. For example, Pepper 3D vs. WebGL, etc. Pepper is the main API for Native Client. Google would probably like to see other browsers support Pepper, as a step towards seeing other browsers support Native Client. But we have no reason to like Pepper: it's a Google technology trying to replace the existing open Web platform, and largely redundant with it. We just believe that the Web platform (DOM APIs) can be made to address the real needs of users (I don't think that DRM is a real need of users, btw).
is it possible to create a “pepper2NPAPI” layer/wrapper which would simply make the new pepper-only flash work with the api mozilla supports?
that would move the implementation to e.g. the plugin package itself, the browser would still see a NPAPI plugin, and nothing more than the necessary parts of pepper would have to be implemented, all while the newest flash can still be used.
(In reply to flying sheep from comment #11)
> is it possible to create a “pepper2NPAPI” layer/wrapper which would simply
> make the new pepper-only flash work with the api mozilla supports?
There used to be an ActiveX plugin for Firefox, wasn't there? (yes, that's the league where our friends from Google themselves into).
(In reply to flying sheep from comment #11)
> is it possible to create a “pepper2NPAPI” layer/wrapper which would simply
> make the new pepper-only flash work with the api mozilla supports?
> that would move the implementation to e.g. the plugin package itself, the
> browser would still see a NPAPI plugin, and nothing more than the necessary
> parts of pepper would have to be implemented, all while the newest flash can
> still be used.
Yes, I think someone could build a Pepper support library around the Pepper Flash plugin and run future Flash versions on non-Chromium Linux browsers that way.
There is no reason for Mozilla to invest in that. Comment #10 is right on, and so is comment #5. There is a good chance that post-11.2 Flash features will simply never matter on the public Web and therefore Pepper support would be a complete waste of time.
(In reply to Matej Cepl from comment #12)
> There used to be an ActiveX plugin for Firefox, wasn't there?
Yes, however supporting ActiveX plugins was much easier than supporting Pepper would be. Implementing all the Pepper APIs (and endlessly playing catch-up as Google churns them) would be a ton of work.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) (away February 21 to March 17) from comment #13)
> Yes, however supporting ActiveX plugins was much easier than supporting
> Pepper would be. Implementing all the Pepper APIs (and endlessly playing
> catch-up as Google churns them) would be a ton of work.
OK. I am not a big fan of Pepper API (or ActiveX for that matter ;)) and I think in case it is needed investment into gnash/lightspark/swfdec/something-else would be much more profitable.
Firefox has lost 6% market share in one year. It's probably unprecedented in that browser history, can we afford to lose Flash too?
The future of the Flash plugin is high quality web games. A ton of crucial features planned for after Flash 11.2 will largely improve Flash in that area. ( https://www.adobe.com/devnet/flashplatform/whitepapers/roadmap.html )
We also have to admit that no SWF-reading plugin will ever be as good as the official one.
We DO want to support Flash. If we don't, isn't it basically like we're giving Linux to Chrome? While Linux is run by less than 2% of all web users, they know how to be grateful when you acknowledge them ^_^
Seeing Adobe's planned features, 11.2 will lack important gaming and performance related novelties before 2015 comes by. Why wait 3 freaking years to merely start re-discussing this? Shouldn't Mozilla reconsider this decision at least once a year, especially considering the time it would take to be Pepper-plugin compliant?
Or work out another plugin API standard that's not Google's, dunno, as long as we're not renouncing to penguin Flash and giving away Linux to Chrome. -_-
(In reply to Matt from comment #16)
> Seeing Adobe's planned features, 11.2 will lack important gaming and
> performance related novelties before 2015 comes by. Why wait 3 freaking
> years to merely start re-discussing this? Shouldn't Mozilla reconsider this
> decision at least once a year, especially considering the time it would take
> to be Pepper-plugin compliant?
Don't sweat the "re-evaluate in X years" stuff. That wasn't meant as a decision or policy, I think Boris meant it as an example. Obviously we'll re-evaluate any time new significant information becomes available.
> they know how to be grateful when you acknowledge them
Past interactions suggest otherwise, sadly. :(
But yes, obviously about Flash's rapid slide into irrelevance changes that would be cause for reevaluating the situation.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) (away February 21 to March 17) from comment #15)
@Josh: "Obviously we'll re-evaluate any time new significant information becomes available."
I'm glad to read that :)
However I would say that reading the link in my last post gives significant information. Now I'm guessing you also want to have information on how the Pepper&Flash marriage translates to concretely, so it makes sense to wait.
But it would be a mistake not to reconsider it once Flash "Cyril" (11.3 I guess) is released, because its features enable full fledged video games in the browser. Then Flash "Dolores" (11.4?) should vastly improve performance with, among other thing, some real support for multi-threading. Flash 12 might see the arrival of ActionScript 4, focused on major performance improvements, and will NOT work in Flash 11.2. Flash 12 seems to be scheduled sometime in 2013.
There is vast demand for hardware accelerated gaming on the Web and Flash is by far the best able to meet it. Linux will want it.
Flash 11.2 will be good already but nothing close to what's coming next. It really sounds like capitulating to Chrome if we don't do anything to support Flash on Linux. Just because the standard plugin API is initiated by Google doesn't mean we should stay on the side of the road and wait; shouldn't we instead get in touch with both Adobe, Google and whoever else is involved, and start actively participating and influencing that API or some credible alternative if there's one?
Waiting may makes sense but it's a bad move IMHO. Even I would switch to Chrome on Linux if I wasn't able to use the latest Flash gaming features. (Yet I love Fx and have a profound distrust towards Chrome; isn't that saying something?) I would keep Fx on Windows of course...
Finally, a standard API for plugins is in itself a good idea for the open world where any web browser would be able to run plugins equally well, without needing Adobe to tailor stuff explicitly to them. It would also help cross-platform and cross-browser consistency of plugins behaviour, which is good for users.
@Boris and Drago: Flash doesn't slide into irrelevance though. It has been mostly used for video and gaming for a few years already; most feature updates were video related before smartphones came in. Now it's simply official ^_^
Besides the plugin is barely ever useful in mobile browser due to existing content not fitting screen size along with full penetration of HTML 5. Gaming is done through apps instead of browser, where it's AIR that's used instead of Flash plugin. All that stuff makes it smarter to drop plugin support altogether and push **** development where it actually matters.
"All that stuff makes it smarter to drop plugin support altogether"
For mobile only, of course. Push **** the desktop plugin and on AIR for mobile and desktops.
@Comment #17: "Don't sweat the "re-evaluate in X years" stuff. That wasn't meant as a decision or policy, I think Boris meant it as an example."
It's still what's written in the whiteboard though :/
I know I'm not having as large a view as Firefox devs, but my view is fresh and closer to that of a user. I know from experience that developer's view becomes biased from knowing too much about what's going on internally. ;)
I think it could be the case right here, maybe.
(Sorry for triple post :/)
AAaaarg, quadruple post! >_<
I wanted to add that, starting from Flash 11.2, the plugin will auto-update possibly as efficiently as Firefox itself auto updates, i.e. very efficiently.
Meaning that Flash 11.3, 11.4 and 12 penetration rates will be almost instantaneous.
Currently, new Flash versions needs about 3 months to reach 80-85% I think, and one year to reach 95-98%. I thought I should mention that because it's worth considering, with the "wait&see" strategy.
(In reply to Matt from comment #16)
> We DO want to support Flash. If we don't, isn't it basically like we're
> giving Linux to Chrome?
Basically yes. I doubt Mozilla would have closed this WONTFIX if it would affect Windows or even OS X but OTOH that is their right to do so its their project.
(In reply to drago01 from comment #24)
> Basically yes. I doubt Mozilla would have closed this WONTFIX if it would
> affect Windows or even OS X but OTOH that is their right to do so its their
It's the converse: Adobe wouldn't have done that on Windows or OS X at this point, because they know it means Flash has no future on that platform. Keep in mind, this move is not just about making Flash Pepper-only, it's also about making it available only as bundled with Chrome.
(In reply to Matt from comment #20)
> It really sounds like capitulating to Chrome if we don't do anything to support
> Flash on Linux.
Would you say that Firefox capitulated to Microsoft when it didn't support ActiveX objects? Why is this situation different?
The question should be reversed. How are the situations similar? We had a working alternative to ActiveX, shared by all browsers except IE.
Now we're letting Google become the sole provider of Flash web content on Linux. Why do we let Google have its way and set a precedent?
Why not just show Adobe that they can be present in all browsers by sharing a common API for plugin support? Currently they have to update the plugin for several browsers and possibly several Linux versions too. They're not able to, considering the change of pace in development and the increasing hardware support requirements.
So Linux Flash will only be available as bundled with Chrome, because Adobe is forced to make a choice. They would certainly be happy if they could get Flash and Reader running in other browsers too. But for that we have to provide the same API. What's so wrong with that?
(In reply to Matt from comment #27)
> So Linux Flash will only be available as bundled with Chrome, because Adobe
> is forced to make a choice. They would certainly be happy if they could get
> Flash and Reader running in other browsers too.
Why do you believe that? As far as I can tell, PepperFlash won't even be available for Chromium, which also implements the Pepper API.
(In reply to Benoit Jacob [:bjacob] from comment #25)
> (In reply to drago01 from comment #24)
> > Basically yes. I doubt Mozilla would have closed this WONTFIX if it would
> > affect Windows or even OS X but OTOH that is their right to do so its their
> > project.
> It's the converse: Adobe wouldn't have done that on Windows or OS X at this
> point, because they know it means Flash has no future on that platform.
Yeah but that does not contradict what I have said.
> in mind, this move is not just about making Flash Pepper-only, it's also
> about making it available only as bundled with Chrome.
The later is not that much of a problem but no support at the API level is.
Why wouldn't they be happy to have a more widespread Flash player. They don't want to spread their resources on ensuring cross-browser compatibility for Linux. If we all shared an API they would only have to deal with that one API.
I don't understand Mozilla's decision. Even reading the link from comment #3 doesn't address the Flash issue specifically. There may be other solutions, I don't know, but what is a certitude is that doing nothing is renouncing to Flash, and renouncing to Flash means we are actively pushing Linux users to switch to Chrome.
Is the current policy resulting from our loss of market share that "we accept to lose Linux because we must focus on core market" ?
Matt, I think you're a little bit confused about Adobe's role here.
They're giving up on development on Linux, period, as far as I can tell. They're still developing Flash on Windows and Mac; Google is responsible for making the Pepper Flash plug-in work on Linux. They have the Flash source code to enable them to do that, etc.
So it's not that Adobe is making Flash on Linux Chrome-only; it's that Google is completely taking over development of Flash on Linux (and obviously only as far as Chrome is concerned).
Even if we implemented the Pepper API that wouldn't help: there would be nowhere for a user to get Flash other than a Chrome install, unless we were to get our own Flash source license and ship Flash ourselves as Google does. Or something.
Or more to the point, while "support the Pepper api" is a prereq for supporting future Flash on Linux it's not nearly sufficient. And the hard parts are legal/licensing issues, as far as I can tell.
I'm not sure what your sources are. There's nothing that states it works like that.
From what I understand, the Flash Player inside Chrome will have all feature updates directly from Adobe and Google will include them in their browser. Just like they do currently, except Adobe drops explicit support for NPAPI on Linux. It won't affect Google because Google will use Pepper API on all operating systems.
So effectively Google is going to be the only one to support Flash 11.3 and up on Linux. It will be real 11.3, 11.4 and 12 Flash Player as developed by Adobe, just like it is today. Do you have a source that says otherwise?
(In reply to Matt from comment #33)
> I'm not sure what your sources are. There's nothing that states it works
> like that.
> Do you have a source that says otherwise?
Yes, the original press release from Adobe:
"Google will begin distributing this new Pepper-based Flash Player as part of Chrome on all platforms, including Linux, later this year.
For Flash Player releases after 11.2, the Flash Player browser plugin for Linux will only be available via the “Pepper” API as part of the Google Chrome browser distribution and will no longer be available as a direct download from Adobe. Adobe will continue to provide security updates to non-Pepper distributions of Flash Player 11.2 on Linux for five years from its release."
> Do you have a source that says otherwise?
http://news.ycombinator.com/item?id=3621263 is a comment from one of the Chrome developers which sure sounds like they're the ones maintaining Flash on Linux going forward. Now maybe he misspoke, of course. But his statements seem consistent with the Adobe press releases to me, whereas the press releases make no sense if Adobe is doing the work.
@Boris: But that developer explicitly states that Chrome Flash on Linux will barely need any tweak from the Windows version, thanks to Pepper API.
In that case, either the Windows version is fully into Google hands as well, and what we have is a fork of Adobe's Flash Player...or I am right, and Google takes latest Adobe FP and just tweaks minor stuff to integrate Pepper Flash.
If we have Adobe Flash 11.3, 11.4, 12 and up on Windows Chrome, then I see no reason why the same Adobe-developed features wouldn't be in Linux Chrome as well.
And as far as I know Google don't intend to shun official Flash updates on Windows. *scratches head*
Sure. My point is that, again as far as I can tell, if we wanted to ship Pepper Flash on Linux we would need to either get source from Adobe and make whatever "tweaks" Google is making or ask Google to pretty please let us have the plug-in. Or something. That is, it doesn't sound like just implementing the Pepper api would get us anywhere by itself.
Yeah indeed I was about to post with this precision but our messages collided :)
If it's indeed Google who tweaks the official FP at each release so it fits in Pepper Chrome, Mozilla can't just support Pepper API. (unless it hacks FP :p)
But it's something that can be discussed with Adobe. Whatever we do I find this WONTFIX puzzling considering 65-85% of all Linux web users browse with Firefox. ( http://weblogs.mozillazine.org/asa/archives/2009/02/how_many_linux.html )
We risk losing them to Chrome and we'll set a sucky precedent. Something should be done to have Flash support, whatever it is, and I hope Mozilla will consider other paths to that goal since this one is apparently a no.
I wish I could propose other paths directly, but all I can do is stress the issue and hope an experienced Firefox developer agrees with me and attempts to find a solution. (If they *know* there's none I would like to hear it too, at least I'd know what to expect :) )
How much does it cost to become an Adobe Licensee?
Maybe Linux users would want to fund Mozilla so they can buy it and adapt future Flash Players to Linux NPAPI?
(In reply to Matt from comment #16)
> The future of the Flash plugin is high quality web games. A ton of crucial
> features planned for after Flash 11.2 will largely improve Flash in that
That roadmap is a lot of promises based on no data. The Flash dev team is bleeding developers heavily and there is no guarantee what's left will be able to deliver on those promises.
Even so, many of the features on the roadmap are simply catch-up to what's already shipping or nearly shipping in Web browsers (e.g. type inference, fullscreen with keys).
Frankly, reallocating a large team of developers from other important tasks to clone a bunch of Google-proprietary APIs just for the sake of supporting Linux desktop users in the unlikely event post-11.2 Flash becomes important to them *and* in the hope we can somehow obtain a non-Google Pepper Flash bundle is an incredibly stupid idea. So let's not.
I think you underestimate Flash heavily. Otherwise you'd be looking for other solutions instead of shrugging and looking elsewhere while Google strips you off.
Why are we holding a discussion in a bug? There are newsgroups/mailing lists designated for these sorts of discussions at https://lists.mozilla.org/listinfo
I wouldn't expect flash to be working properly in 5 or 3 years. If you search the Ubuntu Forums, you will see that this week flash started to act funny again, with the release of version 188.8.131.52. There are many threads complaining about crashes, videos not playing or becoming bluish with the latest updates. Most of the problems are related to hardware acceleration, which probably won't be fixed. There are also previous reports from users that contacted Adobe to try to find solutions to bugs and the standard response was that Adobe doesn't support flash on Linux anymore.
Well yes lol, that's the whole point of this bug report. Flash 11.2 does not support Linux; further updates are only accessible via Chrome, for Linux users. So use Chrome if you want Flash 11.2.
Flash 11.2 does support non-Chrome browsers in Linux, modulo bugs.
I find it amusing how people are so quick to discard Flash when there is simply no alternative for live streaming or podcasting.
Podcasting???????? (/me probably missed something, he never used Flash for podcasting)
(In reply to Eric Appleman from comment #46)
> I find it amusing how people are so quick to discard Flash when there is
> simply no alternative for live streaming or podcasting.
Not to say there's a great non-flash solution now, but WebRTC (bug 665909) will take care of this use-case well before Flash stops supporting non-PPAPI versions.
So did you guys have some discussion with Adobe about how Flash could be maintained on Linux Firefox?
Even if discussion was unproductive, at least summing it up here would inform concerned people on this issue.
I'm not particularly interested in Flash on Linux, but rather in general future of the NPAPI-based plug-ins on the web. Quite recently I've came across this blog post: http://blog.chromium.org/2012/07/npapi-plug-ins-in-windows-8-metro-mode.html, which states that:
We recently announced initial support for Chrome in Windows 8 Metro mode. One thing that early testers may have noticed is that some existing plug-ins don't work. These plug-ins are built using a technology called NPAPI, which, like ActiveX, is not compatible with Windows 8 Metro mode.
I've also read some time ago that there won't be native plug-in for IE 10 in metro mode. Initially I thought that it's only IE policy but now it really seems like a metro policy.
Will you be willing to consider adding support for pepper-driven plug-ins if it would be an only option to run plug-in in metro?
(In reply to Ted Kozak from comment #50)
> Will you be willing to consider adding support for pepper-driven plug-ins if
> it would be an only option to run plug-in in metro?
No. We are not interested in offering a binary plugin API for plugins. See earlier comments in this bug for reasoning.
Thanks for info.
I've asked this question, as most of the conversation above is is about whether the Flashplayer on Linux is something worth investing a time or not for pepper support.
Do I properly assume from your comment that in some point of time (which might be quite soon, depending on how popular the Metro UI will be and what MS will do next about it) there won't be literally any option to create a binary plug-in for Windows that be run on Firefox? Like no more Flash nor Unity for...
Also, if (as said in comment 50) Microsoft decided to kill NPAPI and ActiveX in Windows 8 Metro, that means they decided that plugins were not needed on this platform. In that case, we don't have to get out of our way to salvage binary plugins there!
Ted, we are working very hard to ensure that as soon as possible, you will be able to do in JS with DOM APIs everything that you could do in Flash and even Unity. That is the bet we're making here, the underlying reason why it's not the end of the world if plugins eventually stop working --- DOM APIs are taking over, even for full-scale 3D games. See for instance
Now I really don't want to generate more discussion here --- just wanted to make it clear that there _is_ a plan for heavy in-browser content --- it just doesn't involve plugins.
Interesting, but WebGL will not be supported by IE, not to mention consistency issues across browsers. There's still a long way to go unfortunately, but I'm glad it's getting a lot of focus from browser developers.
Also things like IndexedDB are great, but it's a Firefox-only thingy as far as I know. Is there an equivalently efficient "big storage" API in Chrome and IE ?
As for Flash content, it will be supported in IE 10 Metro if it's signed and validated properly (it has to fit with the "Metro experience" to be validated).
Otherwise non signed Flash and other plugin content will apparently be allowed a one-click switch to IE 10 Desktop mode so that the user experience is barely interrupted.
For what it's worth :)
(In reply to Matt from comment #55)
> Also things like IndexedDB are great, but it's a Firefox-only thingy as far
> as I know.
You may find https://developer.mozilla.org/en/IndexedDB/#Browser_compatibility of interest :-)
Oh thanks, pretty good news. Though IE 9 compatibility would have been better considering that XP and Vista will not get IE 10 at all, and I'm not sure Win 7 will get it.
But I was thinking I'd have to wait a year or so and even then have to use one API per browser vendor, so yeah, relatively that's good news :)
(Sorry everyone that this is off topic)
I hate to say this, but unless Firefox supports Pepper for plugins in Linux, I simply can't consider using Firefox in Linux. I understand that the web is moving more in the direction of plugin-less, standards-based content, but, at least in the short term, this is not viable on the desktop. There are simply too many things that require flash to the point that having an outdated flash version is a nuisance. At the moment, using Firefox in Linux means that I'll have to settle for a buggy, unstable version of Flash if I want to access many kinds of content. Sure, I believe that plugin-less content is the future as much as the next guy, but the reality is that I (and most users) can't live without a stable Flash plugin right now.
I don't know how much work will implementing NPAPI Pepper cost, but since the technology is considered better, why not to support it? I think this is only a matter of time.
It's only better if you're Chrome, since it's tied to Chrome internals.
Which also covers how much implementing it would cost: it requires duplication of lots of undocumented Chrome behavior.
My point is that there are a lot of plugins besides Flash. And HTML5 (the platform) still is horrible at duplicating even Flash's features, despite HTML5 being around for years.
I'm not saying you necessarily need to support Pepper, but this blase attitude about losing plugin support doesn't make sense to me.
> I'm not saying you necessarily need to support Pepper
Then how is it relevant to this bug? Please take meta-discussion on unrelated topics to the right forum? In this case, probably https://groups.google.com/forum/?fromgroups#!forum/mozilla.dev.platform or the equivalent mailing list.
pbs.org requires flash 12.3. That makes me another convert to chrome. I might advise a dialog with Google rather than a "won't fix" No matter the reasons, nobody wants a browser that won't show flash video on some sites when a working alternative browser is available.
There is no Adobe Flash Player 12.3 that I'm aware of. Video on pbs.org looked fine nice on Firefox today.
Typo, thank you - 11.3, and it seems PBS finally fixed their site as it did not work on more than one computer running 11.2 a couple days ago. As I prefer firefox, this is great news. I sincerely hope that my previous comments will continue to be proven incorrect. However, I fear it may only be a matter of time before incompatible sites turn up.
Yet another browser war.
We will see which gun is better our old NPAPI or their MS/Adobe/Google brand new one - Pepper!
I think it's obvious - old vs new, but whatever!
For me this is a total showstopper for using Firefox.
I have a complete "Linux Shop" at home (my Netbook and several older laptops) and even today there are a lot of pages (mainly flash games my son likes to play) that don't work at all with Forefox / Flash 11.2, or have such a sluggish performance that they are unusable (e.g. myvideo.de, the only noteworthy source for free TV / video content in German).
If you don't find a way to support current Flash under Linux, this will drive lots of users away from Firefox to Google Chrome, or even worse, back to Windows and Internet Explorer (new versions of IE are not THAT bad anymore, that an average user would feel the need to install another browser).
I know it's unfair and it's not your fault but nobody else will fix it, so you have to.
How about Mozilla/Shumway project?
Finally i found that thread too. As user i should say you are about to loose essential part of market because of that Adobe/Google/ whatever agressive attack. Firstly i thought about bridge pepper API -> NPAPI too but i agree with #13 that it's not Mozilla work at all. But... For today shumway is not case. First best video from youtube just fails. While many other essential for me sites become invalid for firefox+adobe flash under linux, one-by-one. Other old bugs (like well-known about inverting of your webcamera) appear again and noone will suppot it anymore.
The work for Mozilla is to just concetrate on shumway/whatever else there. You have no choise.
*** Bug 835018 has been marked as a duplicate of this bug. ***
Even though, inside me, I just wish there was no plugins, I think that this latest news my lead to reconsidering the question:
Before it is too late. We already got ***** over by H264.
Hub: Please take discussion to mozilla.dev.platform
With Pipelight 0.2 you can run the Windows Flash plugin through a special WINE version - maybe not the most elegant solution, but it works much better than it sounds, and is IMHO a decent workaround for compatibility and Performance issues that come with being stuck on Flash 11.2
This seems silly that firefox still uses the antiquated NPAPI.
Say what you would like, flash isn't going anywhere soon and makes up quite a bit of the browsable internet to disregard. As well, I'm sure there are other uses I'm completely unaware of.
PPAPI seems like a viable replacement; I believe the license is BSD or MIT or something like that. Especially since Opera 24+ supports it, the argument that it's just for chrome is silly. I'm sure google really wouldn't have an issue packaging it separately if the demand was there. As well, some linux distros are starting to package it separately to use with chromium. See Debian's package page:
(In reply to alexjnewt from comment #74)
> This seems silly that firefox still uses the antiquated NPAPI.
> Say what you would like, flash isn't going anywhere soon and makes up quite
> a bit of the browsable internet to disregard. As well, I'm sure there are
> other uses I'm completely unaware of.
> PPAPI seems like a viable replacement; I believe the license is BSD or MIT
> or something like that. Especially since Opera 24+ supports it, the argument
> that it's just for chrome is silly. I'm sure google really wouldn't have an
> issue packaging it separately if the demand was there. As well, some linux
> distros are starting to package it separately to use with chromium. See
> Debian's package page:
I think it's because Opera24 use Blink like Chrome, it should be modified to "it's just for Blink".
I remembered a developer from Google said that even if Firefox supports Pepper Plugin, Adobe should also provide an another Flash Pepper Plugin for Firefox. I don't know whether it is really right.
Someone is working on a NPAPI to Pepper plugin for Linux: https://github.com/i-rinat/freshplayerplugin
Sucks that it's not for other platforms, as its clear that Adobe is phoning it in on the NPAPI plugin. Stupid thing leaks memory, and hangs Firefox when it starts up. I'm also pretty sure it's the reason why Firefox jitters so much, as it only happens after I've loaded Flash content at some point.
+1 for Pepper support in Firefox.
This bug has been marked as WONTFIX, which means we have explicitly decided not to fix it. Commenting in this bug is extremely unlikely to change that decision.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #78)
> This bug has been marked as WONTFIX, which means we have explicitly decided
> not to fix it. Commenting in this bug is extremely unlikely to change that
Sure are a lot of devs still subscribed to a bug that you don't plan on revisiting.
And, I'll point out, most of the logic claimed here still hasn't come to pass. You still cannot completely replace Flash with HTML5. New Flash content is being created all the time, and a lot of it requires higher than Flash 11.2.
It would be nice if Mozilla would question their decisions instead of dogmatically sticking to them in the fact of all facts. You still don't even have MIDI support in the web platforms.
You can always add a vote for the bug. https://bugzilla.mozilla.org/page.cgi?id=voting/user.html&bug_id=729481#vote_729481
And voting on this bug is likely to help with anything? (see comment 78)
(In reply to Nuno Silva from comment #81)
> And voting on this bug is likely to help with anything? (see comment 78)
It does register your support for the feature request and it is better than asking and getting rejected over and over again.
Otherwise, it might be better to post in the mailing lists for technical discussions where more than 57 people are subscribed and you will get more exposure there.
This has been discussed to death on the technical discussion mailing list. Let me summarize the most salient points of that discussion, for those not willing to go read it themselves:
1) There is no actual clear definition of the Pepper API. It's basically defined by Google's implementation. There's API documentation, but that doesn't cover edge cases, and it's quite likely that actual plugins written against the API rely on the edge cases.
2) Google's implementation is very much tied to Blink and is not designed to work with any other rendering engine.
3) The Flash plugin in particular uses a ton of non-public Pepper APIs that are not even mentioned in the Pepper API documentation.
Anyone commenting on this bug who hasn't bothered to go read those discussions and understand these points and their implications is wasting not only their own time but also that of everyone cced on this bug.
Given the number of people who seem to be intent on doing that, at least 7 people (counting myself as of this comment) have removed themselves from the cc list of this bug in the last few days, because we don't particularly like having our time wasted. The end result here is likely a "why isn't Mozilla adding support for Pepper?" echo chamber, because I doubt new people showing up here will bother to read either this comment or the mailing list discussion....
Restricting comments. See comment 83 for why this isn't going to be implemented.
*** Bug 1096803 has been marked as a duplicate of this bug. ***
*** Bug 1111211 has been marked as a duplicate of this bug. ***
*** Bug 1158962 has been marked as a duplicate of this bug. ***