Last Comment Bug 799318 - [meta] Support H.264/AAC/MP3 video/audio playback on desktop Firefox
: [meta] Support H.264/AAC/MP3 video/audio playback on desktop Firefox
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Audio/Video (show other bugs)
: unspecified
: All All
: -- normal with 91 votes (vote)
: mozilla34
Assigned To: Nobody; OK to take it and work on it
: Cornel Ionce [QA] (:cornel_ionce)
Mentors:
http://areweplayingyet.org/
: 801485 815808 835386 856093 859090 1094180 (view as bug list)
Depends on: 794282 799315 801521 825153 832754 851290 861693 875573 941296 1043696 1047180 1057646 1061171 1062654 1210231
Blocks: html5test
  Show dependency treegraph
 
Reported: 2012-10-08 19:18 PDT by cajbir (:cajbir)
Modified: 2016-03-04 03:53 PST (History)
154 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description cajbir (:cajbir) 2012-10-08 19:18:16 PDT
This is a tracking bug for desktop support of H.264/AAC/MP3 playback using the HTML video and audio elements.
Comment 1 David Doukidis 2012-10-14 19:57:34 PDT
Also depends on 435298

https://bugzilla.mozilla.org/show_bug.cgi?id=435298
Comment 2 Matthew Gregan [:kinetik] 2012-10-14 20:41:56 PDT
*** Bug 801485 has been marked as a duplicate of this bug. ***
Comment 3 Matthew Gregan [:kinetik] 2012-10-14 20:43:04 PDT
Removing bug 541286, we're never going to support MPEG2 and that bug is already WONTFIXed.
Comment 4 Ben Bucksch (:BenB) 2012-10-17 10:14:29 PDT
Matthew, obviously the decision which lead to WONTFIX bug 541286 was reversed.

Thus, this is a clear dup of bug 541286.
Comment 5 Ben Bucksch (:BenB) 2012-10-17 10:15:49 PDT
In fact, the approach employed here to get around patent issues by using platform APIs is exactly what I proposed in bug 541286.
Comment 6 Matthew Gregan [:kinetik] 2012-10-17 14:45:07 PDT
(In reply to Ben Bucksch (:BenB) from comment #4)
> Thus, this is a clear dup of bug 541286.

No, this is a tracking bug for actual work.  Bug 541286 turned in to a discussion bug and covers unrelated topics such as codecs we won't be supporting.  Let's keep this bug clean and use it for things that matter, please.
Comment 7 Ben Bucksch (:BenB) 2012-10-17 15:45:14 PDT
Matthew, we don't re-file bugs that we already have, but we use the older bug. The discussion there is actually useful. This is an open source project, not your personal desktop.
Comment 8 Ralph Giles (:rillian) needinfo me 2012-11-27 14:37:52 PST
*** Bug 815808 has been marked as a duplicate of this bug. ***
Comment 9 Ted Mielczarek [:ted.mielczarek] 2012-12-21 11:24:20 PST
(In reply to Ben Bucksch (:BenB) from comment #7)
> Matthew, we don't re-file bugs that we already have, but we use the older
> bug. The discussion there is actually useful. This is an open source
> project, not your personal desktop.

FWIW, we re-file bugs *all the time* when the old bug has turned into a flame war and a developer wants to get actual work done without dealing with unproductive discussion. Bugs are cheap, and if people are doing actual work then bugzilla pedantry is counterproductive.
Comment 10 Ben Bucksch (:BenB) 2012-12-21 13:01:38 PST
> if people are doing actual work then bugzilla pedantry is counterproductive.

Can I take that to mean that if somebody did "actual work" to allow MPEG2, that work would be accepted?
Comment 11 Ralph Giles (:rillian) needinfo me 2012-12-21 13:25:12 PST
(In reply to Ben Bucksch (:BenB) from comment #10)

> Can I take that to mean that if somebody did "actual work" to allow MPEG2,
> that work would be accepted?

I don't think that's what ted meant at all.
Comment 12 Matthias Versen [:Matti] 2013-01-28 10:11:45 PST
*** Bug 835386 has been marked as a duplicate of this bug. ***
Comment 13 John Schoenick [:johns] 2013-03-31 15:29:46 PDT
*** Bug 856093 has been marked as a duplicate of this bug. ***
Comment 14 Mardeg 2013-04-07 06:45:22 PDT
*** Bug 859090 has been marked as a duplicate of this bug. ***
Comment 15 kkostas_2006 2013-04-07 08:55:50 PDT
Any idea when will the linux version be capable of such playback?
Comment 16 cajbir (:cajbir) 2013-04-07 15:49:46 PDT
(In reply to kkostas_2006 from comment #15)
> Any idea when will the linux version be capable of such playback?

If you build Firefox with the "--enable-gstreamer" option it should work. There's still some things to be ironed out which is why it's not on by default.
Comment 17 Dave Garrett 2013-04-07 18:43:35 PDT
Well, when? Linux and Mac don't have this yet but Windows has already made release, though disabled for now. Is this being prioritized yet? Will all tier 1 platforms get it on by default at the same time? I'm aware Windows has most of the users, but Mac and Linux aren't feeling like tier 1 platforms at this rate.
Comment 18 John Schoenick [:johns] 2013-04-08 13:08:57 PDT
(In reply to Dave Garrett from comment #17)
> Well, when? Linux and Mac don't have this yet but Windows has already made
> release, though disabled for now. Is this being prioritized yet? Will all
> tier 1 platforms get it on by default at the same time? I'm aware Windows
> has most of the users, but Mac and Linux aren't feeling like tier 1
> platforms at this rate.

You'll want to follow bug 794282 and bug 851290. AFAIK the plan is still to support this on all platforms in the same release.
Comment 19 Markus Popp 2013-04-08 14:31:07 PDT
(In reply to Chris Double (:doublec) from comment #16)
> (In reply to kkostas_2006 from comment #15)
> > Any idea when will the linux version be capable of such playback?
> 
> If you build Firefox with the "--enable-gstreamer" option it should work.
> There's still some things to be ironed out which is why it's not on by
> default.

I finally managed to build a Linux64 Firefox from source with gstreamer enabled. Running it right here, right now, works well, much better than I expected really.

See no reason why Nightly builds can't be compiled with --enable-gstreamer option, you can still pref it off by default (I see there is a media.gstreamer.enabled option in about:config). Turning on a flag in about:config is definitely done a few hours more quickly than compiling a Firefox build from source.
Comment 20 Dave Garrett 2013-04-08 15:39:52 PDT
(In reply to Markus Popp from comment #19)
> See no reason why Nightly builds can't be compiled with --enable-gstreamer
> option, you can still pref it off by default

There are issues related to what version(s) of gstreamer happen to be installed at runtime that haven't yet been resolved. That's what I was a little worried about, but bug 859199 just showed up with a patch in progress that aims to get this in working order. :)

(In reply to John Schoenick [:johns] from comment #18)
> AFAIK the plan is still to support this on all platforms in the same release.

Thank you for that clarification.
Comment 21 Masatoshi Kimura [:emk] 2013-04-08 16:25:00 PDT
(In reply to John Schoenick [:johns] from comment #18)
> You'll want to follow bug 794282 and bug 851290. AFAIK the plan is still to
> support this on all platforms in the same release.

WMF backend is still enabled on beta.
https://mxr.mozilla.org/mozilla-beta/search?string=media.windows-media-foundation.enabled
Are you saying bug 837859 will be reverted? (Because it's very unlikely that GStreamer support will be enabled on Linux and Mac OS X and backported to beta in 5 weeks.)
Comment 22 PTO until Sep 5 NZ time; Chris Pearce (:cpearce) 2013-04-08 16:28:13 PDT
(In reply to Masatoshi Kimura [:emk] from comment #21)
> (In reply to John Schoenick [:johns] from comment #18)
> > You'll want to follow bug 794282 and bug 851290. AFAIK the plan is still to
> > support this on all platforms in the same release.

No, we're going to ship H.264/AAC/MP3 support on platforms as we implement them, we're not waiting for them all to be ready to ship at the same time. We've already done this by shipping H.264/AAC/MP3 on Firefox for Android for example.
Comment 23 John Schoenick [:johns] 2013-04-08 16:36:04 PDT
(In reply to Masatoshi Kimura [:emk] from comment #21)
> WMF backend is still enabled on beta.
> https://mxr.mozilla.org/mozilla-beta/search?string=media.windows-media-
> foundation.enabled
> Are you saying bug 837859 will be reverted? (Because it's very unlikely that
> GStreamer support will be enabled on Linux and Mac OS X and backported to
> beta in 5 weeks.)

(In reply to Chris Pearce (:cpearce) from comment #22)
> No, we're going to ship H.264/AAC/MP3 support on platforms as we implement
> them, we're not waiting for them all to be ready to ship at the same time.
> We've already done this by shipping H.264/AAC/MP3 on Firefox for Android for
> example.

I stand corrected! Apologies for the misinformation
Comment 24 Dave Garrett 2013-04-08 16:54:35 PDT
(In reply to Chris Pearce (:cpearce) from comment #22)
> No, we're going to ship H.264/AAC/MP3 support on platforms as we implement
> them, we're not waiting for them all to be ready to ship at the same time.
> We've already done this by shipping H.264/AAC/MP3 on Firefox for Android for
> example.

Mobile and desktop are two very different things. All the tier 1 desktop platforms really should end up with it on by default in the same release, otherwise you're inviting sites to code just for Firefox for Windows, probably with bad UA sniffing. You're also basically saying that Mac and Linux aren't really tier 1 supported anymore, seeing as feature parity will go away in a noticeable way, which is not a great message. :/

Is there the possibility of getting things backported to Aurora (or next Beta) so they're only a release apart? Or, is the current plan to be separated 2 or 3 cycles?
Comment 25 PTO until Sep 5 NZ time; Chris Pearce (:cpearce) 2013-04-08 16:59:14 PDT
Web developers should use the HTMLMediaElement.canPlayType() function to determine whether a user agent can play different formats, they shouldn't sniff user agents.

We are actively working on Linux and Mac support, H.264/AAC/MP3 on all tier-1 platforms is a priority for the media team at the moment.
Comment 26 Chris Adams 2013-04-08 17:11:56 PDT
(In reply to Dave Garrett from comment #24)
> Mobile and desktop are two very different things. All the tier 1 desktop
> platforms really should end up with it on by default in the same release,
> otherwise you're inviting sites to code just for Firefox for Windows,
> probably with bad UA sniffing. You're also basically saying that Mac and
> Linux aren't really tier 1 supported anymore

As someone who has used only a Linux or Mac desktop since before Firefox existed, I respectfully disagree. <video> has a great canPlayType format detection feature – which is what I use to serve H.264 and fall back to Flash for Firefox and IE8 – and I think it's critically important to start make Firefox competitive, particularly since the Windows port is both the most widely used and very popular in enterprise shops as an alternative to legacy IE. Getting those users off of Flash is a bigger win for the web than coaxing a much smaller number of Mac users like me away from browsers like Chrome/Safari which already support H.264 <video>.
Comment 27 Dave Garrett 2013-04-08 17:44:33 PDT
I was not aware of HTMLMediaElement.canPlayType() and do hope it is as widely used as it should be. It still bugs me that support is landing inconsistently, nonetheless.

Anyway, thanks for clarifying the official position on the topic.
Comment 28 Markus Popp 2013-04-08 18:54:36 PDT
My 2 cents:

I agree that the advantage that the majority of Firefox users on Windows get H.264/AAC/MP3 ASAP outweighs the disadvantage that not all platforms get support at the same time. But to avoid that users on Linux and OS X feel like 2nd class citizens it would certainly be helpful if by the time when H.264/AAC/MP3 support becomes available in a final Firefox for Windows release (i.e. 21.0 as it looks), support for H.264/AAC/MP3 would at least be available in development builds for Linux and OS X. So you can say: "sorry, we're late on Linux & OS X, but if this is important to you, we can offer you something".

To accomplish that, gstreamer support would have to be enabled before Firefox 21 gets released, which means during the current development cycle. So H.264/AAC/MP3 playback would be available for Linux and OS X in the Aurora channel by the end of the week of the Firefox 21.0 release.

Given that my self compiled Linux64 build with --enable-gstreamer looks very good in terms of H.264/AAC/MP3 playback (actually I can't find a difference to Firefox Beta on Windows), maybe this is a realistic goal to target.
Comment 29 Robert Kaiser 2013-04-09 04:52:56 PDT
People need to use .canPlayType() (or other fallback-based solutions) in any case as we only support those types if they're present on the system. I'm not sure if you can even uninstall them on Windows or Mac, but I know for sure that not all Linux installations will have them available, and I guess the same can be true on Android, esp. as we blocklist this functionality on some devices. So, people can never take for granted that some version of Firefox can play those files for sure, UA detection is useless here. Only .canPlayType() can determine if we really can play it.
Comment 30 Mardeg 2013-05-10 17:27:55 PDT
I added http://areweplayingyet.org/ to the URL field showing examples of .canPlayType()
(In reply to Dave Garrett from comment #17)
> Mac and Linux aren't feeling like tier 1 platforms at this rate.
(In reply to Markus Popp from comment #28)
> So you can say: "sorry, we're late on Linux & OS X
Please note that Windows Vista support is also late (Firefox 22), see bug 825153, and Windows XP is likely to only get .mp3 support at a yet to be determined version, see bug 861693. Support landing inconsistently was known and used initially as an argument to not support patent encumbered formats in any way back before that stance was reversed, see http://robert.ocallahan.org/2009/06/directshow-and-platform-media_23.html
Comment 31 Markus Popp 2013-05-10 18:47:19 PDT
(In reply to Mardeg from comment #30)
> I added http://areweplayingyet.org/ to the URL field showing examples of
> .canPlayType()
> (In reply to Dave Garrett from comment #17)
> > Mac and Linux aren't feeling like tier 1 platforms at this rate.
> (In reply to Markus Popp from comment #28)
> > So you can say: "sorry, we're late on Linux & OS X
> Please note that Windows Vista support is also late (Firefox 22), see bug
> 825153, and Windows XP is likely to only get .mp3 support at a yet to be
> determined version, see bug 861693. Support landing inconsistently was known
> and used initially as an argument to not support patent encumbered formats
> in any way back before that stance was reversed, see
> http://robert.ocallahan.org/2009/06/directshow-and-platform-media_23.html

My point is that for the most part (actually I haven't encountered any issues at all), it works (on Linux), but in order to get a copy with gstreamer, I have to compile Firefox on my own which is time consuming and annoying.

I can't see why Nightlies aren't built with --enable-gstreamer already, and if really necessary, preffed off.

And if things aren't 100 % matured and stable yet, that's why Nightlies are Nightlies, and not final releases.
Comment 32 Dave Garrett 2013-05-11 13:28:03 PDT
(In reply to Markus Popp from comment #31)
> I can't see why Nightlies aren't built with --enable-gstreamer already, and
> if really necessary, preffed off.

Currently, if you don't have gstreamer installed or have a different version than it was built for then Firefox won't start at all. This is being fixed in bug 859199 after which point it'll be added to Nightly builds in some form.

(In reply to Mardeg from comment #30)
> Please note that Windows Vista support is also late (Firefox 22), see bug
> 825153, and Windows XP is likely to only get .mp3 support at a yet to be
> determined version, see bug 861693.

Those are old operating systems. Technically, nobody should be running them anymore (though obviously people do in droves; my gaming OS is still XP). The high-priced OS plus paid upgrade model just forces people into old, out of date, and insecure OSes, which is sad. Also, every other MS OS release sucks.

Is no effort being made to get h.264 support on XP through DirectShow? I can understand not wanting to. You'd be relying on whatever 3rd party codecs were installed to do it, but it would at least give them feature parity. I'm wondering if it would be possible to have this sort of thing in an addon so XP users could at least have the hoops to jump through if they knew what they were doing.
Comment 33 Mark Straver 2013-05-11 13:34:58 PDT
Directshow as a back-end, even if possible (and even already having a patch for it) was made a WONTFIX. It's a pity since it's a nice framework to use, although it does have a few drawbacks, of course.

Bug 435339 - DirectShow backend for HTML5 video element
Comment 34 PTO until Sep 5 NZ time; Chris Pearce (:cpearce) 2013-05-11 14:10:04 PDT
I am currently resurrecting the DirectShow backend for MP3 playback only in bug 861693.
Comment 35 Mark Straver 2013-05-11 14:34:50 PDT
Why not use DirectShow for more than just MP3 audio on XP/Vista? I mean, if the capability is there to use the code for video as well, might as well use it...
Comment 36 Masatoshi Kimura [:emk] 2013-05-11 15:14:44 PDT
WinXP does not contain H.264 codec.
Roc suggested it may be possible to use H.264 decoder from Flash Player.
Comment 37 Mark Straver 2013-05-12 01:10:42 PDT
DirectShow is a framework that allows you to use any installed codec - including e.g. ffdshow and others that most definitely do support H.264 and other decoders to play just about any format available.
Comment 38 Masatoshi Kimura [:emk] 2013-05-12 21:12:58 PDT
We won't support any random format which may or may not be installed on users' system. H.264 is an exception because of the patent restriction.
Comment 39 Ben Bucksch (:BenB) 2013-05-13 03:54:47 PDT
emk, nobody said that. We can use DirectShow and whitelist the formats. Even if they are not coming by default with the OS release, the user can still install them (via MediaCenter, ffdshow, DVD player software, whatever), and we use them, and only those.
Comment 40 STUNGMEBAS 2013-05-24 21:13:23 PDT
Patents suck.
Comment 41 vova.kravets 2013-07-16 03:17:51 PDT
Guys, I noticed that Firefox nightly (25.0a1) when uses gstreamer have a big performance during playing of mp4 stream. 

I use ArchLinux Gstreamer 0.10 and 1.0 was installed, also vaapi plugin for 0.10 and 1.0 was installed also.

If try to play file via below command (for 0.10 and 1.0 version) I see that vaapi is used and performance is low.

gst-launch playbin2 <url>

Should I open a defect for this or working in this area is performing now?

Best Regards,
Vladimir
Comment 42 Ben Bucksch (:BenB) 2013-07-16 03:44:44 PDT
> Should I open a defect for this

Yes, please open a new bug. You can mention the bug number here as reference for others.
Comment 43 vova.kravets 2013-07-16 06:29:38 PDT
Done, 894372 was open.
Comment 44 jcready 2013-08-06 12:37:54 PDT
Firefox 21 was released on 2013-05-14. I'm currently using Firefox Aurora 24.0a2 (2013-08-05) for Mac and I've got my homepage set to "about:config" so that I can check if anything like "media.windows-media-foundation.enabled" got added. It's been almost three months now since Win7+ had support for this enabled by default in a stable release. The last update for getting H.264/AAC/MP3 support for Mac: bug 851290 was back in June, yet the last update for supporting WinXP: bug 861693 was... Yesterday.

Why is Windows XP (now 4 generations old) getting more attention than the current generation of Mac OSX?
Comment 45 Dave Garrett 2013-08-06 13:06:43 PDT
(In reply to jcready from comment #44)
> Why is Windows XP (now 4 generations old) getting more attention than the
> current generation of Mac OSX?

Because it has five times as many users, obviously.
Comment 46 Peter Henkel [:Terepin] 2013-08-06 13:42:27 PDT
(In reply to Dave Garrett from comment #45)
> (In reply to jcready from comment #44)
> > Why is Windows XP (now 4 generations old) getting more attention than the
> > current generation of Mac OSX?
> 
> Because it has five times as many users, unfortunately.

Fixed.
Comment 47 antistress 2013-08-13 17:42:11 PDT
There is that bug on vimeo where some html5 H264 videos are not displayed within Firefox. It seems to be a bug common to GNU/Linux & Firefox OS : https://bugzilla.mozilla.org/show_bug.cgi?id=884558#c1
Is it related to Bug 875573 (Add support for m4v as 'video/x-m4v' MIME type) ? Or shall we update the dependance tree of this bug ?
Comment 48 Axel Hecht 2013-11-20 07:57:39 PST
Does the http://www.openh264.org/ effort have an impact on what we're doing here? Notably, on platforms where we're not done yet, like mac? (i know, still nothing but "soon" there, but still)
Comment 49 sjw 2013-11-22 11:16:26 PST
*** Bug 942130 has been marked as a duplicate of this bug. ***
Comment 50 gavenkoa 2013-12-14 09:56:40 PST
To enable H.264 in Debian Firefox 24/25 (Iceweasel) build you must install

apt-get install gstreamer0.10-plugins-good gstreamer0.10-ffmpeg

and enable gstream support in about:config  "media.gstreamer.enabled" according to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=682917
Comment 51 Frederic Bezies 2013-12-14 10:00:36 PST
But what about gstreamer 1.x which is spread more and more on distributions ? Like in bug #921714 ?
Comment 52 gavenkoa 2013-12-14 10:06:03 PST
Debian package maintainer just add --enable-gstreamer to ./configure. If 1.x compatible with 0.10.x I see no problem...
Comment 53 Florian Bender 2013-12-14 11:59:57 PST
(In reply to Frederic Bezies from comment #51)
> But what about gstreamer 1.x which is spread more and more on distributions
> ? Like in bug #921714 ?

GStreamer 1.0 support is Bug 806917.
Comment 54 Frank Yan (:fryn) 2014-08-31 11:49:49 PDT
Now that Bug 1043696 is fixed, can this bug be closed out?
Bug 875573 is still open but may be nonessential.
Comment 55 Ralph Giles (:rillian) needinfo me 2014-09-02 10:35:00 PDT
I think so. We've covered all the desktop systems with platform decoders.
Comment 56 Masatoshi Kimura [:emk] 2014-09-06 01:14:02 PDT
We will never add H.264 support for WinXP and OS X 10.6, then? At least bug 1062654 considers adding support for OS X 10.6.
Comment 57 Ralph Giles (:rillian) needinfo me 2014-09-08 11:00:31 PDT
We'd like to, but it won't happen immediately. We've been implementing support for using the operating system's decoders when they're available. WinXP doesn't have built-in support for mp4, and not all MacOS X 10.6 machines do either.

We could use the OpenH264 add-on to decode mp4 in the <video> tag, but it needs support for main and high profile before it's very useful in HTML <video> tags. Right now development is focussed on its use in WebRTC, so that will have to wait unless someone steps up to contibute the work. Even when that's resovled, we'll still need a way to play back the AAC audio on WinXP and other systems without native support.
Comment 58 Lily Rose 2014-09-08 11:10:13 PDT
(In reply to Ralph Giles (:rillian) from comment #57)
> We'd like to, but it won't happen immediately. We've been implementing...

A part of me understands why you want to support XP, but another part of me asks: why?
Why can't we just let Windows XP die out, instead of holding it on life support, and use resources on XP that could be used better elsewhere?
Comment 59 Robert Kaiser 2014-09-08 11:24:36 PDT
(In reply to Daniel from comment #58)
> A part of me understands why you want to support XP, but another part of me
> asks: why?

While commercial vendors concentrate on selling more software, we concentrate on delivering software to the most amount of people (where we can). And there is a really huge amount of people still on WinXP. We just do not want to abandon those people unless really necessary.
Comment 60 bugzilla 2014-09-08 11:46:10 PDT
Is it not one of mozillas goals to give the user a safer place in the internet?
How could mozilla support a operating-system longer, if they are no security fixes from the 
manufacturer? I love XP also, but the world should change to ohter OS like linux or newer Windows systems.
Comment 61 Dave Garrett 2014-09-08 11:53:43 PDT
(In reply to Daniel from comment #58)
> Why can't we just let Windows XP die out, instead of holding it on life
> support, and use resources on XP that could be used better elsewhere?

Because Microsoft charges quite a bit for major upgrades and there are people who can't afford that cost, let alone the cost of a new computer that might be needed to run them. There are millions of people who will be using Windows XP until their current computer physically breaks and they're forced to buy a new one (which in some parts of the world, still might be running Windows XP). It's "good enough" for people who can't afford new tech, and there are millions more using unlicensed installations that are not going to be getting any upgrades any time soon. (in an ideal world they'd all transition to Linux or something, but that's not likely to happen) Mozilla will probably need to continue Windows XP support in some form "forever", though eventually it should probably be downgraded to tier-2. Platform parity will still be desired; even if the computer is running some repackaged unlicensed Windows XP SP3 installation in China, they should be able to get a fully functioning and secure version of Firefox running.
Comment 62 [Baboo] 2014-09-08 13:02:36 PDT
(In reply to Dave Garrett from comment #61)
> they should be able to get a fully functioning and secure version of Firefox running.

Thinking about all the possible exploits in the OS waiting to be uncovered but never patches I don't see how security can be guaranteed under such circumstances. It's more along the lines of "as secure as possible from Firefox' side".
Comment 63 Matthias Versen [:Matti] 2014-11-05 07:44:14 PST
*** Bug 1094180 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.