On Thu, Jan 11, 2018 at 11:43 AM, Daniel Veditz wrote:
> On Wed, Jan 10, 2018 at 5:35 PM, Tantek Çelik
> wrote:
>>
>> Also good methodology worth repeating:
>>"thinking ... through all the way up to and including the user
>> experience, makes for a much more viable approach"
>
>
> Including,
Yes we are an implementer. WOFF 2.0 was enabled in Firefox 39,
released 2015-06-30.
https://bugzilla.mozilla.org/show_bug.cgi?id=1084026 and
https://developer.mozilla.org/en-US/docs/Web/CSS/@font-face#Browser_compatibility
Kevin Brosnan
On Thu, Jan 11, 2018 at 10:40 AM, L. David Baron wrote:
> A
On Thu, Jan 11, 2018 at 12:10:35PM -0800, Bobby Holley wrote:
On Thu, Jan 11, 2018 at 12:06 PM, Kris Maglione
wrote:
On Thu, Jan 11, 2018 at 05:12:37PM +0100, Tom Schuster wrote:
This could be an issue for WebExtensions as well. I think the
contentscript
sandbox runs in a different compartment
On Thu, Jan 11, 2018 at 12:06 PM, Kris Maglione
wrote:
> On Thu, Jan 11, 2018 at 05:12:37PM +0100, Tom Schuster wrote:
>
>> This could be an issue for WebExtensions as well. I think the
>> contentscript
>> sandbox runs in a different compartment.
>>
>
> It runs in a different compartment, but the
On Thu, Jan 11, 2018 at 05:12:37PM +0100, Tom Schuster wrote:
This could be an issue for WebExtensions as well. I think the contentscript
sandbox runs in a different compartment.
It runs in a different compartment, but the DOM constructors it
has access to come from the same content window as
> > Specifically: I was wondering about the real impact of the webvr polyfill
> > not working, on Firefox users. My mention of the work implementing WebVR
> > was pointing out that we will hopefully not need to worry about the
> > webvr-polyfil working on Gecko-based browsers in the not-to-dis
> Specifically: I was wondering about the real impact of the webvr
polyfill not working, on Firefox users. My mention of the work
implementing WebVR was pointing out that we will hopefully not need to
worry about the webvr-polyfil working on Gecko-based browsers in the
not-to-distant future, when
On Wed, Jan 10, 2018 at 5:35 PM, Tantek Çelik
wrote:
> Also good methodology worth repeating:
>"thinking ... through all the way up to and including the user
>
> experience, makes for a much more viable approach"
>
Including, of course, "how will 4chan trolls abuse this?" and "how will
a
A W3C Proposed Recommendation is available for the membership of
W3C (including Mozilla) to vote on, before it proceeds to the final
stage of being a W3C Recomendation:
WOFF (Web Open Font Format) File Format 2.0
https://www.w3.org/TR/WOFF2/
https://w3c.github.io/woff/woff2/
Deadline for r
Oh, I see what you are saying. I think there is some confusion here (perhaps
on my part only).
I do not know if the main use of (and motivation for) the sensor APIs is webvr,
but I have not been involved in it. I thought that (newer) API was brought up
in this discussion as a suggestion for
I don’t understand this comment.
> On Jan 11, 2018, at 12:50 PM, Martin Thomson wrote:
>
> As Anne said, I don't know why you would define a new API rather than
> enhancing the existing one, other than NIH. But I guess the damage is
> now done.
>
> On Fri, Jan 12, 2018 at 4:48 AM, Blair MacI
On Thu, Jan 11, 2018 at 6:48 PM, Blair MacIntyre wrote:
>> In that case I'm not entirely sure why we'd also pursue new
>> variants separately.
>
> I’m not sure what this means?
That if our main usage for the new sensor APIs (those discussed in
https://github.com/w3ctag/design-reviews/issues/207)
As Anne said, I don't know why you would define a new API rather than
enhancing the existing one, other than NIH. But I guess the damage is
now done.
On Fri, Jan 12, 2018 at 4:48 AM, Blair MacIntyre wrote:
>> On Thu, Jan 11, 2018 at 5:30 PM, Blair MacIntyre
>> wrote:
>>> First, this discussion
> On Thu, Jan 11, 2018 at 5:30 PM, Blair MacIntyre
> wrote:
>> First, this discussion pertains to FF on Windows, Mac, Android and Linux, I
>> assume? FF for iOS just uses the wkWebView and it’s up to Apple to decide
>> on things like this. Is this correct?
>
> I believe there's some tricks w
On Thu, Jan 11, 2018 at 5:30 PM, Blair MacIntyre wrote:
> First, this discussion pertains to FF on Windows, Mac, Android and Linux, I
> assume? FF for iOS just uses the wkWebView and it’s up to Apple to decide on
> things like this. Is this correct?
I believe there's some tricks we could pull
As of the latest nightly, you just need gfx.webrender.all set to true.
You can leave the other preferences ( gfx.webrender.enabled,
gfx.webrender.blob-images, image.mem.shared,
layers.acceleration.force-enabled, which are still meaningfull for
developers) as default.
--
- Milan (mi...@mozill
IIRC Blink uses a different mechanism (called "separate worlds") to allow
extensions to interact with content, whereas we use a separate global +
xrays. So this likely will be a problem for WebExtensions, and we'll
presumably need a sandboxOption to opt into the old behavior.
On Thu, Jan 11, 2018
On 1/11/18 1:44 AM, Jon Coppeard wrote:
Just a heads up: JS module scripts (
On 10/01/18 18:40, Tom Ritter wrote:
> This proposal is that. Add a permission 'canvas-imagedata' that will
> return 'granted' when Resist Fingerprinting mode is disabled, and
> 'prompt' when RP is enabled and appropriate.
As this is basically a "is RF turned on?" flag, why not just call it
that?
I’ve been thinking about this since my last message, and I wanted to step back
and clarify something for myself.
First, this discussion pertains to FF on Windows, Mac, Android and Linux, I
assume? FF for iOS just uses the wkWebView and it’s up to Apple to decide on
things like this. Is this c
Based on what Cameron wrote, other browsers already return false if
things get mixed, so hopefully the WebExtensions side of the problem is
still limited?
~ Gijs
On 11/01/2018 16:12, Tom Schuster wrote:
This could be an issue for WebExtensions as well. I think the contentscript
sandbox runs i
This could be an issue for WebExtensions as well. I think the contentscript
sandbox runs in a different compartment.
On Thu, Jan 11, 2018 at 3:58 PM, Gijs Kruitbosch
wrote:
> On 11/01/2018 05:29, Cameron McCormack wrote:
>
>> For use in the meantime, I just landed bug 1428531 on inbound, which a
On 11/01/2018 05:29, Cameron McCormack wrote:
For use in the meantime, I just landed bug 1428531 on inbound, which adds a new
chrome-only static method "isInstance" to Web IDL defined interfaces, so you
can write for example:
Document.isInstance(otherWindow.document)
So that we don't have
We have three categories of solutions suggested here:
- Throttling
- An explicit gesture to approve using the API
- A prompt
We might be able to do some/all of those depending on the situation. Is
there anything else I have missed that has been suggested?
I honestly would like to request we do so
Just a heads up: JS module scripts (
25 matches
Mail list logo