Unless there's some major security issue we need to address, we'll leave
them enabled on the ESR until it catches up with release.
Mike
On Wed, Oct 2, 2019 at 9:52 AM wrote:
> Hello,
>
>
>
> I’ve read some news which say that the most popular web browsers (Chrome,
> Edge, IE, Safari and
It definitely should work.
There is a problem if the cert is required on the very first page that is
loaded (we've fixed that).
And you won't see it in Firefox certificate settings, but it definitely
should work.
Could you open a bugzilla bug please and we can debug?
Mike
On Tue, Oct 1, 2019
No, there is no support for using links over to Firefox. It's based on the
Chrome legacy browser support, so it has the same feature set.
It's primary purpose is to use the legacy browser as the secondary browser.
It is open source, though, so someone could implement that.
The code to do something like this is:
Services.perms.add(NetUtil.newURI("https://www.youtube.com;),
"autoplay-media", 1);
You an add a few of these lines at the bottom of cck2.cfg with your domains
and it should work.
I'll look at adding it to policy as well.
Mike
On Wed, Oct 2, 2019 at 9:27
Hello Mike,
Thank you very much for your reply!
To be more specific, we’ve deployed, via GPO, a CA certificate in window’s
“trusted root CA” store.
And we need Firefox to use or to import this certificate in order to trust
certificates generated by this CA.
Best Regards,
Hello,
I've read some news which say that the most popular web browsers (Chrome, Edge,
IE, Safari and Firefox) should abandon TLS 1.0 and TLS 1.1 protocols during the
year 2020.
I've seen that they are already disabled in the latest nightly, and that they
should be disabled in March 2020 with
Using ESR version 68.1.0, is there any way to whitelist specific domains to
allow them to autoplay video content? I see how it can be done via the UI, but
have not found a method to allow us to programmatically address this. We want
to allow videos to autoplay from *our* domain(s), while still
Mandi! Mike Kaply
In chel di` si favelave...
> Because of how early it is in startup, I can only make it a policy on Windows.
> I'm putting together a patch for that.
Sorry. 'policy on Windows' mean 'GPO'? Or you are speaking about a
policy in generic terms (GPO, but also json and registry)
Mandi! Klaus Hartnegg
In chel di` si favelave...
> You just learned the hard way that not following rules causes problems.
> Now instead of fixing the underlying bug you want to break another rule.
> Guess what? That will cause more problems.
> Every deployment solution, every inventory tool,
Mandi! Mike Kaply
In chel di` si favelave...
> https://support.mozilla.org/en-US/kb/understanding-depth-profile-installation
As Thane say, i'm also a bit puzzled by that explanation. What i
understand is that, because profile dir name are hashad against install
dir path, i'll get different
Am 01.10.2019 um 23:00 schrieb Mike Kaply:
We're also making a change so 64 bit Firefox installs in the same
directory as 32 bit (which is causing the new profiles).
Oh, no!
You just learned the hard way that not following rules causes problems.
Now instead of fixing the underlying bug you
11 matches
Mail list logo
