Re: Intent to unship: navigator.registerContentHandler()

[Tantek Çelik]

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, of course, "how will 4chan trolls abuse this?" and "how will
> ad-tech trackers abuse this?"

Why stop there?

What about "how will state-level-actors abuse this to mislead,
surveil, and censor users?"  (only 1/2 :)

While I agree with asking the sorts of questions you're asking, I
think such abuse-cases are a distinctly different class of design
problems/considerations than what I believe was a positive UX design
methodology that Anne expressed, of making sure users can actually
viably get done what they want to get done.

That being said, perhaps consider filing issues to add your questions
to the W3C Security & Privacy questionnaire, especially if you think
we should be asking them for every web standards spec/API/feature we
consider contributing to and /or implementing.

https://github.com/w3ctag/security-questionnaire

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: W3C Proposed Recommendation: WOFF 2.0

[Kevin Brosnan]

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 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 responses: Sunday, February 11, 2018
>
> If there are comments you think Mozilla should send as part of the
> review, please say so in this thread.  Ideally, such comments should
> link to github issues filed against the specification.  (I'd note,
> however, that there have been previous opportunities to make
> comments, so it's somewhat bad form to bring up fundamental issues
> for the first time at this stage.)
>
> Given that this is something that I believe we implement, we should
> be voting on this, even if that vote is just to support without any
> comments.  I suspect Jonathan Kew knows what the status of our
> implementation is, and about whether we should be raising any
> issues.
>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: performing cross-context instanceof checks

[Kris Maglione]

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.


It runs in a different compartment, but the DOM constructors it has access
to come from the same content window as the nodes it would be checking, so
this isn't an issue.


Oh, I guess Xrays behavior would be unaffected by Cameron's proposal.
Ignore my previous message.


Right, as long as both the node that's being checked and the 
constructor have X-ray wrappers, they work as expected without 
isinstance hooks (albeit much more slowly).


It might change the behavior when checking a non-X-rayed node 
against an X-rayed constructor, or vice versa, though. Hopefully 
people aren't relying on that.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: performing cross-context instanceof checks

[Kris Maglione]

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 the nodes it 
would be checking, so this isn't an issue.



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 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 even more call sites we need to fix up once we
start looking at bug 1360715, please try to use isInstance rather than
instanceof if you need to do cross-context DOM object tests from chrome JS.



Assuming we're happy to update all sites (not only sites where we're sure
the DOM instance is sometimes cross-context), this type of thing is
relatively easy to automatically rewrite with an xpcshell script like the
ones Florian has been using to update other conventions (e.g. use of
Services.prefs instead of manually Cc[...].getService(Ci.nsIPrefBranch)
etc. ). If we rewrite the extant callsites, we can add eslint checks that
warn and can do similar rewrites for people, which will be better at
avoiding new callsites than just convention (which people are liable to
forget in a few days/weeks/months), and would make the transition
relatively "easy".

~ Gijs

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[Blair MacIntyre]

> > 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, 
> > whenever we have full platform coverage for a real WebVR/WebXR 
> > implementation.
> 
> My ideal here is that we have an explicit user action / gesture or prompt 
> for: Magic window, WebVR/XR and device orientation. We might choose to make 
> several prompts rolled into one for VR but ultimately it will still require 
> the user to understand the risks. I'm not really sure there is an obvious way 
> of protecting the user from magic window being just as dangerous as device 
> orientation.

I think that breakdown of categories is a good set.  Right now, WebVR/XR 
(HMD’s) has been using one approach.  "Magic window”-like apps have not been 
implement in WebVR, but rather using device orientation (akin to the polyfill), 
so anything that looks like that (right now) is just as dangerous, as you say.

My hope is that the “Magic window” style of AR/VR is supported directly by the 
WebXR api.  There will be some pushback at increased friction (right now, 
experiences like that start working immediately because of device orientation) 
but I think on the whole, the community group understands the need for some 
sort of user action / gesture.

> > if we’re including iOS in the list of platforms we may want to try and 
> > remove device orientation from
> 
> I don't think we need to remove it just provide UI in the short term to 
> require the user to approve.

Great.  I would agree with that approach.

> > when WebXR (including “Magic Window” support) will ship in all versions of 
> > Firefox
> 
> I'm unsure here too, I'm not after restricting these websites from working at 
> least in the short term. I think the functionality should still exist if we 
> can come up with the right controls to these APIs.
> 
> I suspect we are mostly talking about fennec but I'm also not sure if any 
> laptops/tablets use these APIs if the sensors exist. If the APIs are in use 
> again I think the prompts should be clear to the user about the risks they 
> have.
> 
> One thing that we could try is taking the user though an on-boarding tutorial 
> when they first see a website that uses this API. The tutorial could explain 
> to them what the API will be called, how they will be prompted and what the 
> risks are to them.

I think we (folks in the MR team) would be interested to explore that with you; 
 I personally would be, partially because I suspect we may need such an 
“education” approach with future sensors and capabilities.  If we look down the 
road at the kind of sensor data advanced AR displays collect (using sensors to 
build models of the world around the user, for example), we will eventually 
want to explore how to expose that data into the web (as part of WebXR, or some 
other API).  Explaining what this means to users will be hard, much like device 
orientation.

Thanks for your patience with all of this!




> 
> On Thu, Jan 11, 2018 at 6:15 PM, Blair MacIntyre  > wrote:
> 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 a replacement for the 
> deviceorientation APIs.  (Again, I’m unaware of the history or motivations 
> behind that API.)
> 
> There has been some supposition in this discussion that the main use of the 
> device orientation APIs is the WebVR polyfill.  I do not know if that is 
> true, I don’t think Chris or I said that — I haven’t seen any mention of any 
> data to support or not support that.  It is clear that _a_ use of the device 
> orientation APIs is supporting WebVR polyfill.   But it also used for 
> panoramic photo viewers, 360 video viewers, and probably other (legitimate) 
> things.   Regardless, I fully understand the security/privacy concerns.
> 
> My message this morning was intended to (perhaps) reframe the discussion and 
> (perhaps) let us move forward.  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, whenever we have full platform coverage for a real 
> WebVR/WebXR implementation.
> 
> What is/was unclear to me is:
> - if we’re including iOS in the list of platforms we may want to try and 
> remove device orientation from.   Matters insofar as we WON’T be able to 
> implement WebVR/WebXR there.
> - when 

Re: Device Orientation API future

[Jonathan Kingston]

> 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, whenever we have full platform coverage for a real
WebVR/WebXR implementation.

My ideal here is that we have an explicit user action / gesture or prompt
for: Magic window, WebVR/XR and device orientation. We might choose to make
several prompts rolled into one for VR but ultimately it will still require
the user to understand the risks. I'm not really sure there is an obvious
way of protecting the user from magic window being just as dangerous as
device orientation.

> if we’re including iOS in the list of platforms we may want to try and
remove device orientation from

I don't think we need to remove it just provide UI in the short term to
require the user to approve.

> when WebXR (including “Magic Window” support) will ship in all versions
of Firefox

I'm unsure here too, I'm not after restricting these websites from working
at least in the short term. I think the functionality should still exist if
we can come up with the right controls to these APIs.

I suspect we are mostly talking about fennec but I'm also not sure if any
laptops/tablets use these APIs if the sensors exist. If the APIs are in use
again I think the prompts should be clear to the user about the risks they
have.

One thing that we could try is taking the user though an on-boarding
tutorial when they first see a website that uses this API. The tutorial
could explain to them what the API will be called, how they will be
prompted and what the risks are to them.

On Thu, Jan 11, 2018 at 6:15 PM, Blair MacIntyre 
wrote:

> 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 a replacement for the
> deviceorientation APIs.  (Again, I’m unaware of the history or motivations
> behind that API.)
>
> There has been some supposition in this discussion that the main use of
> the device orientation APIs is the WebVR polyfill.  I do not know if that
> is true, I don’t think Chris or I said that — I haven’t seen any mention of
> any data to support or not support that.  It is clear that _a_ use of the
> device orientation APIs is supporting WebVR polyfill.   But it also used
> for panoramic photo viewers, 360 video viewers, and probably other
> (legitimate) things.   Regardless, I fully understand the security/privacy
> concerns.
>
> My message this morning was intended to (perhaps) reframe the discussion
> and (perhaps) let us move forward.  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, whenever we have full platform
> coverage for a real WebVR/WebXR implementation.
>
> What is/was unclear to me is:
> - if we’re including iOS in the list of platforms we may want to try and
> remove device orientation from.   Matters insofar as we WON’T be able to
> implement WebVR/WebXR there.
> - when WebXR (including “Magic Window” support) will ship in all versions
> of Firefox.  I could “guess” but that’s not useful (I have no control over
> that).
>
> But, if we laid out a plan that said “in the short term we’ll do X, which
> may not be ideal, when WebXR is available we’ll do Y”, that might help.  I
> hope that the second step is not too far in the future, but thinking of it
> that way at least doesn’t lock us into “we need to find a satisfactory
> solution that keeps the webxr-polyfill working indefinitely” since it
> doesn't need to work indefinitely.
>
> Please forgive me for the lack of clarity.  And, of course, if that sort
> of approach isn’t acceptable, just say so.
>
>
> > On Jan 11, 2018, at 12:53 PM, Anne van Kesteren 
> wrote:
> >
> > 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) is WebVR/XR and
> > we don't have any other uses that are compelling enough, and WebVR/XR
> > will come with their own APIs for this, there's no reason for us to
> > worry about the new sensor APIs.
> >
> >
> > --
> > https://annevankesteren.nl/
>
>
___
dev-platform mailing list

Re: Intent to unship: navigator.registerContentHandler()

[Daniel Veditz]

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
ad-tech trackers abuse this?"​

-Dan Veditz
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

W3C Proposed Recommendation: WOFF 2.0

[L. David Baron]

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 responses: Sunday, February 11, 2018

If there are comments you think Mozilla should send as part of the
review, please say so in this thread.  Ideally, such comments should
link to github issues filed against the specification.  (I'd note,
however, that there have been previous opportunities to make
comments, so it's somewhat bad form to bring up fundamental issues
for the first time at this stage.)

Given that this is something that I believe we implement, we should
be voting on this, even if that vote is just to support without any
comments.  I suspect Jonathan Kew knows what the status of our
implementation is, and about whether we should be raising any
issues.

-David

-- 
턞   L. David Baron http://dbaron.org/   턂
턢   Mozilla  https://www.mozilla.org/   턂
 Before I built a wall I'd ask to know
 What I was walling in or walling out,
 And to whom I was like to give offense.
   - Robert Frost, Mending Wall (1914)


signature.asc
Description: PGP signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[Blair MacIntyre]

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 a replacement for the deviceorientation 
APIs.  (Again, I’m unaware of the history or motivations behind that API.)   

There has been some supposition in this discussion that the main use of the 
device orientation APIs is the WebVR polyfill.  I do not know if that is true, 
I don’t think Chris or I said that — I haven’t seen any mention of any data to 
support or not support that.  It is clear that _a_ use of the device 
orientation APIs is supporting WebVR polyfill.   But it also used for panoramic 
photo viewers, 360 video viewers, and probably other (legitimate) things.   
Regardless, I fully understand the security/privacy concerns.

My message this morning was intended to (perhaps) reframe the discussion and 
(perhaps) let us move forward.  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, whenever we have full platform coverage for a real 
WebVR/WebXR implementation.   

What is/was unclear to me is:
- if we’re including iOS in the list of platforms we may want to try and remove 
device orientation from.   Matters insofar as we WON’T be able to implement 
WebVR/WebXR there.
- when WebXR (including “Magic Window” support) will ship in all versions of 
Firefox.  I could “guess” but that’s not useful (I have no control over that).  

But, if we laid out a plan that said “in the short term we’ll do X, which may 
not be ideal, when WebXR is available we’ll do Y”, that might help.  I hope 
that the second step is not too far in the future, but thinking of it that way 
at least doesn’t lock us into “we need to find a satisfactory solution that 
keeps the webxr-polyfill working indefinitely” since it doesn't need to work 
indefinitely.

Please forgive me for the lack of clarity.  And, of course, if that sort of 
approach isn’t acceptable, just say so.


> On Jan 11, 2018, at 12:53 PM, Anne van Kesteren  wrote:
> 
> 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) is WebVR/XR and
> we don't have any other uses that are compelling enough, and WebVR/XR
> will come with their own APIs for this, there's no reason for us to
> worry about the new sensor APIs.
> 
> 
> -- 
> https://annevankesteren.nl/

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[Blair MacIntyre]

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 MacIntyre  
> wrote:
>>> 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 on iOS in theory.
>> 
>> Perhaps.  But is that part of the discussion?  I ask because
>>> 
>>> 
 From a WebVR perspective, the polyfill (that uses device-orientation) 
 defers to the built in WebVR API if it exists.
>>> 
>>> So WebVR/XR has its own equivalents for these APIs? I was not aware of
>>> that.
>> 
>> No, it’s different:  WebVR/XR provide precise 3D orientation and position 
>> (assume 3D position tracking is available) of the display.  Typically, 
>> that’s a Head-Worn Display (ie., a Vive or Rift or whatever).  Currently, 
>> WebVR has only been implemented only for head-worn displays.  The polyfill 
>> was used to fill in the gaps;  provide “VR” on those paper “cardboard” 
>> display holders, for example.
>> 
>> Moving forward, WebXR will include the notion of “Magic Window” displays, 
>> meaning “you’re holding the device in your hands and it tries to give the 
>> appearance of a portal into the virtual or AR world”.  So, “tracked 3D 
>> content”.
>> 
>> For the WebVR/XR api to work, it must provide a super-set of the 
>> device-orientation capabilities to the application.  There are separate 
>> discussions about the security aspects of WebVR/XR:  it will not be 
>> accessible without permission or user-gesture, as this API is.
>> 
>> So, it’s not an “equivalent” API, but is rather providing the information 
>> needed to do 3D AR/VR directly, without relying on getting device 
>> orientation from this API.
>> 
>> 
>>> In that case I'm not entirely sure why we'd also pursue new
>>> variants separately.
>> 
>> I’m not sure what this means?
>> 
>>> 
>>> 
>>> --
>>> https://annevankesteren.nl/
>> 

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[Anne van Kesteren]

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) is WebVR/XR and
we don't have any other uses that are compelling enough, and WebVR/XR
will come with their own APIs for this, there's no reason for us to
worry about the new sensor APIs.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[Martin Thomson]

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 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 on iOS in theory.
>
> Perhaps.  But is that part of the discussion?  I ask because
>>
>>
>>> From a WebVR perspective, the polyfill (that uses device-orientation) 
>>> defers to the built in WebVR API if it exists.
>>
>> So WebVR/XR has its own equivalents for these APIs? I was not aware of
>> that.
>
> No, it’s different:  WebVR/XR provide precise 3D orientation and position 
> (assume 3D position tracking is available) of the display.  Typically, that’s 
> a Head-Worn Display (ie., a Vive or Rift or whatever).  Currently, WebVR has 
> only been implemented only for head-worn displays.  The polyfill was used to 
> fill in the gaps;  provide “VR” on those paper “cardboard” display holders, 
> for example.
>
> Moving forward, WebXR will include the notion of “Magic Window” displays, 
> meaning “you’re holding the device in your hands and it tries to give the 
> appearance of a portal into the virtual or AR world”.  So, “tracked 3D 
> content”.
>
> For the WebVR/XR api to work, it must provide a super-set of the 
> device-orientation capabilities to the application.  There are separate 
> discussions about the security aspects of WebVR/XR:  it will not be 
> accessible without permission or user-gesture, as this API is.
>
> So, it’s not an “equivalent” API, but is rather providing the information 
> needed to do 3D AR/VR directly, without relying on getting device orientation 
> from this API.
>
>
>> In that case I'm not entirely sure why we'd also pursue new
>> variants separately.
>
> I’m not sure what this means?
>
>>
>>
>> --
>> https://annevankesteren.nl/
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[Blair MacIntyre]

> 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 on iOS in theory.

Perhaps.  But is that part of the discussion?  I ask because 
> 
> 
>> From a WebVR perspective, the polyfill (that uses device-orientation) defers 
>> to the built in WebVR API if it exists.
> 
> So WebVR/XR has its own equivalents for these APIs? I was not aware of
> that.

No, it’s different:  WebVR/XR provide precise 3D orientation and position 
(assume 3D position tracking is available) of the display.  Typically, that’s a 
Head-Worn Display (ie., a Vive or Rift or whatever).  Currently, WebVR has only 
been implemented only for head-worn displays.  The polyfill was used to fill in 
the gaps;  provide “VR” on those paper “cardboard” display holders, for 
example.  

Moving forward, WebXR will include the notion of “Magic Window” displays, 
meaning “you’re holding the device in your hands and it tries to give the 
appearance of a portal into the virtual or AR world”.  So, “tracked 3D 
content”.  

For the WebVR/XR api to work, it must provide a super-set of the 
device-orientation capabilities to the application.  There are separate 
discussions about the security aspects of WebVR/XR:  it will not be accessible 
without permission or user-gesture, as this API is.

So, it’s not an “equivalent” API, but is rather providing the information 
needed to do 3D AR/VR directly, without relying on getting device orientation 
from this API.


> In that case I'm not entirely sure why we'd also pursue new
> variants separately.

I’m not sure what this means?

> 
> 
> -- 
> https://annevankesteren.nl/

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[Anne van Kesteren]

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 on iOS in theory.


> From a WebVR perspective, the polyfill (that uses device-orientation) defers 
> to the built in WebVR API if it exists.

So WebVR/XR has its own equivalents for these APIs? I was not aware of
that. In that case I'm not entirely sure why we'd also pursue new
variants separately.


-- 
https://annevankesteren.nl/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: If you're trying to run Nightly with WebRender enabled, you will have to change some preferences...

[Milan Sreckovic]

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...@mozilla.com)

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: performing cross-context instanceof checks

[Bobby Holley]

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 at 8:16 AM, Gijs Kruitbosch 
wrote:

> 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 in a different compartment.
>>
>> On Thu, Jan 11, 2018 at 3:58 PM, Gijs Kruitbosch <
>> gijskruitbo...@gmail.com>
>> wrote:
>>
>> 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 even more call sites we need to fix up once we
 start looking at bug 1360715, please try to use isInstance rather than
 instanceof if you need to do cross-context DOM object tests from chrome
 JS.


>>> Assuming we're happy to update all sites (not only sites where we're sure
>>> the DOM instance is sometimes cross-context), this type of thing is
>>> relatively easy to automatically rewrite with an xpcshell script like the
>>> ones Florian has been using to update other conventions (e.g. use of
>>> Services.prefs instead of manually Cc[...].getService(Ci.nsIPrefBranch)
>>> etc. ). If we rewrite the extant callsites, we can add eslint checks that
>>> warn and can do similar rewrites for people, which will be better at
>>> avoiding new callsites than just convention (which people are liable to
>>> forget in a few days/weeks/months), and would make the transition
>>> relatively "easy".
>>>
>>> ~ Gijs
>>>
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: JS modules are now enabled in nightly

[Steve Fink]

On 1/11/18 1:44 AM, Jon Coppeard wrote:

Just a heads up: JS module scripts 

Re: Intent to Implement: canvas-imagedata permission

[Gervase Markham]

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? Or are we going to add more permissions for any other things about
RF mode that people might want to query?

Gerv

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[Blair MacIntyre]

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 correct?

From a WebVR perspective, the polyfill (that uses device-orientation) defers to 
the built in WebVR API if it exists.  We have WebVR on Windows, and will 
hopefully(?) have it on all these other platforms soon-ish (I am unsure of 
timelines for this).  

On top of this, device orientation really is mostly used on mobile, so Android 
is likely the main platform of concern here?  Some Windows/Linux machines 
(tablets?) have orientation, I assume (although I haven’t looked at it in a few 
years on such a device), but most don’t.

So is this discussion mostly about Android?  One question might be:  how long 
till we ship WebVR of some form on Android?  Most people don’t have “VR” 
displays for their Android phones (e.g., Daydream, GearVR, etc), but I’m 
wondering if we might have part of the mitigation we’re thinking about be to 
have our WebVR implementation work on all devices, not just ones with “real” VR 
support.  The next API (now called WebXR) will include support for what the 
community is calling “Magic Window” VR/AR, which is just AR/VR without a 
headmounted display.

All of this is to say:  if we assume that within 2018, we could conceivably 
have WebXR of some form available in FF on all our platforms, to handle the 
cases the WebVR polyfill currently handles, does this change this discussion?

The main use will them be for things like panoramic images / 360 video viewers 
— when we aren’t talking “VR”, perhaps throttling might work, or perhaps other 
approaches might be suitable that aren’t appropriate for VR. 


> On Jan 11, 2018, at 6:30 AM, Jonathan Kingston  wrote:
> 
> 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 some user studies on different
> content strings for prompts and see if users understand the risks.
> Prompts are a UX pattern that are convention already, inventing new ones
> will take more experimenting to perfect. So if we can find the right
> content where users understand some of the time, this is better than not
> giving users the ability to ever understand where their data is going.
> 
> Thanks
> 
> On Thu, Jan 11, 2018 at 7:20 AM, Anne van Kesteren  wrote:
> 
>> On Thu, Jan 11, 2018 at 5:39 AM, Chris Van Wiemeersch 
>> wrote:
>>> Anne and Martin, can you think of changes to request for the Sensor API
>>> that we would resolve or reasonably improve the existing fingerprinting
>>> concerns?
>> 
>> It sounds like Chrome's approach is throttling, which would probably
>> work, but it doesn't work for WebVR, right? (At which point we're back
>> at looking at a permission prompt and being unsure how to phrase the
>> question.)
>> 
>> 
>> --
>> https://annevankesteren.nl/
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>> 
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: performing cross-context instanceof checks

[Gijs Kruitbosch]

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 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 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 even more call sites we need to fix up once we
start looking at bug 1360715, please try to use isInstance rather than
instanceof if you need to do cross-context DOM object tests from chrome JS.



Assuming we're happy to update all sites (not only sites where we're sure
the DOM instance is sometimes cross-context), this type of thing is
relatively easy to automatically rewrite with an xpcshell script like the
ones Florian has been using to update other conventions (e.g. use of
Services.prefs instead of manually Cc[...].getService(Ci.nsIPrefBranch)
etc. ). If we rewrite the extant callsites, we can add eslint checks that
warn and can do similar rewrites for people, which will be better at
avoiding new callsites than just convention (which people are liable to
forget in a few days/weeks/months), and would make the transition
relatively "easy".

~ Gijs

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: performing cross-context instanceof checks

[Tom Schuster]

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 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 even more call sites we need to fix up once we
>> start looking at bug 1360715, please try to use isInstance rather than
>> instanceof if you need to do cross-context DOM object tests from chrome JS.
>>
>
> Assuming we're happy to update all sites (not only sites where we're sure
> the DOM instance is sometimes cross-context), this type of thing is
> relatively easy to automatically rewrite with an xpcshell script like the
> ones Florian has been using to update other conventions (e.g. use of
> Services.prefs instead of manually Cc[...].getService(Ci.nsIPrefBranch)
> etc. ). If we rewrite the extant callsites, we can add eslint checks that
> warn and can do similar rewrites for people, which will be better at
> avoiding new callsites than just convention (which people are liable to
> forget in a few days/weeks/months), and would make the transition
> relatively "easy".
>
> ~ Gijs
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: performing cross-context instanceof checks

[Gijs Kruitbosch]

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 even more call sites we need to fix up once we start 
looking at bug 1360715, please try to use isInstance rather than instanceof if 
you need to do cross-context DOM object tests from chrome JS.


Assuming we're happy to update all sites (not only sites where we're 
sure the DOM instance is sometimes cross-context), this type of thing is 
relatively easy to automatically rewrite with an xpcshell script like 
the ones Florian has been using to update other conventions (e.g. use of 
Services.prefs instead of manually Cc[...].getService(Ci.nsIPrefBranch) 
etc. ). If we rewrite the extant callsites, we can add eslint checks 
that warn and can do similar rewrites for people, which will be better 
at avoiding new callsites than just convention (which people are liable 
to forget in a few days/weeks/months), and would make the transition 
relatively "easy".


~ Gijs
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Device Orientation API future

[Jonathan Kingston]

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 some user studies on different
content strings for prompts and see if users understand the risks.
Prompts are a UX pattern that are convention already, inventing new ones
will take more experimenting to perfect. So if we can find the right
content where users understand some of the time, this is better than not
giving users the ability to ever understand where their data is going.

Thanks

On Thu, Jan 11, 2018 at 7:20 AM, Anne van Kesteren  wrote:

> On Thu, Jan 11, 2018 at 5:39 AM, Chris Van Wiemeersch 
> wrote:
> > Anne and Martin, can you think of changes to request for the Sensor API
> > that we would resolve or reasonably improve the existing fingerprinting
> > concerns?
>
> It sounds like Chrome's approach is throttling, which would probably
> work, but it doesn't work for WebVR, right? (At which point we're back
> at looking at a permission prompt and being unsure how to phrase the
> question.)
>
>
> --
> https://annevankesteren.nl/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

JS modules are now enabled in nightly

[Jon Coppeard]

Just a heads up: JS module scripts