Note, this effort is already being reported in the tech press based on this
thread. For example:
https://www.theregister.co.uk/AMP/2018/03/20/mozilla_firefox_test_of_privacy_mechanism_prompts_privacy_worries/
A blog post does sound like a good idea.
On Mon, Mar 19, 2018, 11:33 PM Dave Townsend
On 20/03/2018 20:50, gwhi...@gmail.com wrote:
Will 61 bring support for font-optical-sizing as well?
Yes; it's behind the same pref as font-variation-settings, so the two
properties will be enabled together.
___
dev-platform mailing list
dev-platf
On Tuesday, March 20, 2018 at 4:39:36 AM UTC-7, Jonathan Kew wrote:
> On 19/03/2018 22:42, L. David Baron wrote:
>
> > Is there something with a little more detail about how our (a)
> > feature set and (b) platform support compares with what other
> > engines are shipping?
>
> That sounds like i
On Tue, Mar 20, 2018 at 3:02 AM, Henri Sivonen wrote:
> I understand that the goal is better privacy. But it's likely that
> people get outraged if a browser sends information about what is
> browser to an off-path destination without explicit consent regardless
> of intention, nightliness or pro
On Tue, Mar 20, 2018 at 11:43:13AM +0100, Frederik Braun wrote:
On 20.03.2018 04:33, Dave Townsend wrote:
The DoH service
we're using is likely more private than anything the user is currently
using.
This is only true for some parts of the world.
I'd like us not to regress for our user base
On 03/20/2018 06:49 AM, Henri Sivonen wrote:
On Tue, Mar 20, 2018 at 12:44 PM, Henri Sivonen wrote:
On Tue, Mar 20, 2018 at 11:12 AM, Henri Sivonen wrote:
OK. I'll leave the UTF-16 case unchanged and will make the minimal
changes on the UTF-8 side to retain the existing outward behavior
witho
We intend to ship a process-level sandbox for the NPAPI Flash plugin on
macOS in 61. This will provide a degree of process isolation at the expense
of some lesser-used Flash functionality[1]. You can enable the sandbox now
on Nightly, globally for all sites, by setting
dom.ipc.plugins.sandbox-level
On 2018-03-19 11:33 PM, Dave Townsend wrote:
As one of the folks who brought up the initial concern let me be clear that
at this point my only real concern here is one of optics. The DoH service
we're using is likely more private than anything the user is currently
using.
It isn't explicit ri
On Tue, Mar 20, 2018 at 12:44 PM, Henri Sivonen wrote:
> On Tue, Mar 20, 2018 at 11:12 AM, Henri Sivonen wrote:
>> OK. I'll leave the UTF-16 case unchanged and will make the minimal
>> changes on the UTF-8 side to retain the existing outward behavior
>> without burning the tree. Hopefully I can m
On 19/03/2018 22:42, L. David Baron wrote:
Is there something with a little more detail about how our (a)
feature set and (b) platform support compares with what other
engines are shipping?
That sounds like it could be a worthwhile blog post somewhere
In brief: everyone supports font-var
On 20/03/2018 10:40, Emilio Cobos Álvarez wrote:
On 03/20/2018 11:22 AM, Jonathan Kew wrote:> There are a handful of
tests now in
web-platform/tests/css/css-fonts/variations, and there a bunch more
currently in preparation (e.g. see
https://bugzilla.mozilla.org/show_bug.cgi?id=1436588).
There'
In bug 1446954 I'm removing those platforms from our automation in
preparation to removing the old code, now that stylo is enabled everywhere.
This mostly affects you if you're hacking on the style system itself, or
in Shadow DOM stuff, which only works on the new style system.
There's probably a
On Tue, Mar 20, 2018 at 11:12 AM, Henri Sivonen wrote:
> OK. I'll leave the UTF-16 case unchanged and will make the minimal
> changes on the UTF-8 side to retain the existing outward behavior
> without burning the tree. Hopefully I can make the UTF-8 case faster
> while at it. It depended on not-s
On 20.03.2018 04:33, Dave Townsend wrote:
> The DoH service
> we're using is likely more private than anything the user is currently
> using.
This is only true for some parts of the world.
I'd like us not to regress for our user base globally here.
___
On 03/20/2018 11:22 AM, Jonathan Kew wrote:> There are a handful of
tests now in
> web-platform/tests/css/css-fonts/variations, and there a bunch more
> currently in preparation (e.g. see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1436588).
There's also https://github.com/w3c/web-platform-test
On 20/03/2018 09:54, James Graham wrote:
On 19/03/2018 22:32, Jonathan Kew wrote:
As of this week, for the mozilla-61 cycle, I plan to turn support for
OpenType Font Variations on by default.
It has been developed behind the layout.css.font-variations.enabled
and gfx.downloadable_fonts.keep_v
On 19/03/2018 22:32, Jonathan Kew wrote:
As of this week, for the mozilla-61 cycle, I plan to turn support for
OpenType Font Variations on by default.
It has been developed behind the layout.css.font-variations.enabled and
gfx.downloadable_fonts.keep_variation_tables preferences.
Other UAs s
On Tue, Mar 20, 2018 at 11:00 AM, smaug wrote:
> On 03/19/2018 09:30 PM, Kris Maglione wrote:
>>
>> On Mon, Mar 19, 2018 at 08:49:10PM +0200, Henri Sivonen wrote:
>>>
>>> It appears that currently we allow atomicizing invalid UTF-16 string,
>>> which are impossible to look up by UTF-8 key and we d
On 03/19/2018 09:30 PM, Kris Maglione wrote:
On Mon, Mar 19, 2018 at 08:49:10PM +0200, Henri Sivonen wrote:
It appears that currently we allow atomicizing invalid UTF-16 string,
which are impossible to look up by UTF-8 key and we don't allow
atomicizing invalid UTF-8.
I need to change some thin
19 matches
Mail list logo