Re: Device Orientation API future

[hearcomestreble]

On Wednesday, January 3, 2018 at 2:43:43 PM UTC-8, Martin Thomson wrote:
> On Thu, Jan 4, 2018 at 2:52 AM, Blair MacIntyre  
> wrote:
> > I was more concerned about the idea (or, at least what I though might be
> > suggested) that you only get orientation if they give location permission.
> > This seems overkill:  even if I know what the data means, I can see uses of
> > orientation that I’d be comfortable with but that I wouldn’t be comfortable
> > giving my geolocation.  that’s all I was talking about.
> 
> I guess that someone needs to work out how to control access to
> orientation without invoking that prompt then.  I think that we could
> easily give access to orientation with geolocation, but I can see that
> there are plenty of cases for orientation *without* geolocation.
> Could we explore the gross movement idea some more?

FYI: As implemented in Chrome, permission is automatically granted to use the 
Generic Sensor API (`chrome://flags/#enable-generic-sensor`) in secure contexts 
(e.g., HTTPS, localhost).

FWIW, the "Mitigation Strategies" section of the Sensors API spec covers this: 
https://w3c.github.io/sensors/#mitigation-strategies

As for the WebVR use cases (namely, "magic window" modes, the webvr-polyfill 
, etc.), check out this GitHub 
issue I've filed for moving away from `devicemotion`: 
https://github.com/googlevr/cardboard-vr-display/issues/10
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposed W3C Charter: Second Screen Working Group

[Martin Thomson]

Without the protocol pieces, this remains vendor-specific.  We should
comment on this and make it clear that we think that definition of a
generic protocol for interacting with the second display has not been
given sufficient priority.  Allowing this to proceed without a generic
protocol would be bad for the ecosystem.

From what I can see, there seem to be a bunch of options that are
described for the protocol, without extremely scant detail.  Certainly
not enough to implement anything.

I'm concerned with the statement "This Working Group does not
anticipate further changes to this specification" regarding the
presentation API.  I haven't reviewed this thoroughly, but there
appear to be some gaps in rather fundamental pieces.  For instance -
and maybe this doesn't change the API at all - but the means of
identification for screens is unclear.  Some of these details are
important, such as whether knowledge of a presentation URL is all the
information necessary to use that URL (i.e., are they capability
URLs?).

On Thu, Jan 4, 2018 at 2:31 PM, Shih-Chiang Chien  wrote:
> The SecondScreen WG intended to move the protocol development to CG, and
> will possibly move to IETF after the incubation phase.
> The revised charter is trying to associate the work of CG to the timeline
> of Presentation API development.
>
> At the meantime, WG will tackle the testability issue found while creating
> test cases and cultivating Level 2 API requirements for advanced use cases.
>
> I'll vote to support this revised charter.
>
> Best Regards,
> Shih-Chiang Chien
> Mozilla Taiwan
>
> On Thu, Jan 4, 2018 at 10:08 AM, L. David Baron  wrote:
>
>> The W3C is proposing a revised charter for:
>>
>>   Second Screen Working Group
>>   https://w3c.github.io/secondscreen-charter/
>>   https://lists.w3.org/Archives/Public/public-new-work/2017Dec/.html
>>
>> Mozilla has the opportunity to send comments or objections through
>> Friday, January 52.  (Sorry for failing to send this out sooner!)
>>
>> A diff relative to the current charter is:
>> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2014%
>> 2Fsecondscreen%2Fcharter-2016.html=https%3A%2F%2Fw3c.
>> github.io%2Fsecondscreen-charter%2F
>>
>> The participants in the working group are:
>> https://www.w3.org/2000/09/dbwg/details?group=74168=1=org
>>
>> Please reply to this thread if you think there's something we should
>> say as part of this charter review, or if you think we should
>> support or oppose it.
>>
>> One longstanding concern for me with this work is to what extent it
>> defines an API that lets an Google-made browser talk to a Google
>> screen, and an Apple-made browser talk to an Apple screen, versus to
>> what extent it allows any browser to talk to any screen that
>> supports a particular piece of technology.  I think there might
>> have been some encouraging news on this front at TPAC in November,
>> but I don't remember the details.  But if there was, I'd rather
>> expect it to be incorporated into this charter, but I don't really
>> see that after a first read.  I'm curious what others know and think
>> about this issue.
>>
>> -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: Device Orientation API future

[Martin Thomson]

On Thu, Jan 4, 2018 at 1:09 PM, Blair MacIntyre  wrote:
> We could chat about it, sure;  how do you envision it working without 
> breaking old websites?

With the understanding that this is purely spitballing...

We would stop providing events (or provide them with extremely low
frequency [1]), but if the currently focused context has an event
handler registered for orientation events, we would enable events once
the orientation changes by a large amount or quickly.  The thresholds
might need some tuning, but a shake or large movement should work.

That means that sites that expect and only receive subtle movement
would stop receiving events.  Sites that don't receive input focus
would stop receiving events (that prevents an embedded iframe from
getting events).  But sites that legitimately use the API will only
appear to be a little "sticky" initially.  We might also persist this
"implicit" permission to remove that stickiness for sites that are
used often (or reduce the activation thresholds over repeat visits).

We should also look at getting a hook into the permission API so that
the current state can be queried.  But that API doesn't really
understand this sort of model, so that might be tricky to work out.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[Karl Dubost]

Jonathan,

Le 4 janv. 2018 à 00:15, Jonathan Kingston  a écrit :
> Firefox has an implementation that only can be used to allow a web page to
> handle RSS feeds. 

in Firefox 8, the feeds panel was removed from Firefox. It created a bit of bad 
press. 
Some people have developed add-ons to cope with the removal.
https://developer.mozilla.org/en-US/Firefox/Releases/2/Adding_feed_readers_to_Firefox

If I check https://addons.mozilla.org/en-US/firefox/search/?q=rss+reader
I can see a couple of addons for reading RSS/Atom feeds.

Do we have a way to know how many add-ons might break with this removal?


Also
https://github.com/search?utf8=%E2%9C%93=registerContentHandler=Issues


Chromium world.
Implementation https://bugs.chromium.org/p/chromium/issues/detail?id=11359
Disabled inhttps://bugs.chromium.org/p/chromium/issues/detail?id=44984
Discussions in https://bugs.chromium.org/p/chromium/issues/detail?id=86115

WebKit world.
Proposed https://bugs.webkit.org/show_bug.cgi?id=73177 (last activity 2014)



-- 
Karl Dubost, mozilla  Webcompat
http://www.la-grange.net/karl/moz





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

Re: Proposed W3C Charter: Second Screen Working Group

[Shih-Chiang Chien]

The SecondScreen WG intended to move the protocol development to CG, and
will possibly move to IETF after the incubation phase.
The revised charter is trying to associate the work of CG to the timeline
of Presentation API development.

At the meantime, WG will tackle the testability issue found while creating
test cases and cultivating Level 2 API requirements for advanced use cases.

I'll vote to support this revised charter.

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

On Thu, Jan 4, 2018 at 10:08 AM, L. David Baron  wrote:

> The W3C is proposing a revised charter for:
>
>   Second Screen Working Group
>   https://w3c.github.io/secondscreen-charter/
>   https://lists.w3.org/Archives/Public/public-new-work/2017Dec/.html
>
> Mozilla has the opportunity to send comments or objections through
> Friday, January 52.  (Sorry for failing to send this out sooner!)
>
> A diff relative to the current charter is:
> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2014%
> 2Fsecondscreen%2Fcharter-2016.html=https%3A%2F%2Fw3c.
> github.io%2Fsecondscreen-charter%2F
>
> The participants in the working group are:
> https://www.w3.org/2000/09/dbwg/details?group=74168=1=org
>
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.
>
> One longstanding concern for me with this work is to what extent it
> defines an API that lets an Google-made browser talk to a Google
> screen, and an Apple-made browser talk to an Apple screen, versus to
> what extent it allows any browser to talk to any screen that
> supports a particular piece of technology.  I think there might
> have been some encouraging news on this front at TPAC in November,
> but I don't remember the details.  But if there was, I'd rather
> expect it to be incorporated into this charter, but I don't really
> see that after a first read.  I'm curious what others know and think
> about this issue.
>
> -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

Re: Device Orientation API future

[Blair MacIntyre]

We could chat about it, sure;  how do you envision it working without breaking 
old websites?

> On Jan 3, 2018, at 5:43 PM, Martin Thomson  wrote:
> 
> On Thu, Jan 4, 2018 at 2:52 AM, Blair MacIntyre  
> wrote:
>> I was more concerned about the idea (or, at least what I though might be
>> suggested) that you only get orientation if they give location permission.
>> This seems overkill:  even if I know what the data means, I can see uses of
>> orientation that I’d be comfortable with but that I wouldn’t be comfortable
>> giving my geolocation.  that’s all I was talking about.
> 
> I guess that someone needs to work out how to control access to
> orientation without invoking that prompt then.  I think that we could
> easily give access to orientation with geolocation, but I can see that
> there are plenty of cases for orientation *without* geolocation.
> Could we explore the gross movement idea some more?

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

Proposed W3C Charter: Second Screen Working Group

[L. David Baron]

The W3C is proposing a revised charter for:

  Second Screen Working Group
  https://w3c.github.io/secondscreen-charter/
  https://lists.w3.org/Archives/Public/public-new-work/2017Dec/.html

Mozilla has the opportunity to send comments or objections through
Friday, January 52.  (Sorry for failing to send this out sooner!)

A diff relative to the current charter is:
https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2014%2Fsecondscreen%2Fcharter-2016.html=https%3A%2F%2Fw3c.github.io%2Fsecondscreen-charter%2F

The participants in the working group are:
https://www.w3.org/2000/09/dbwg/details?group=74168=1=org

Please reply to this thread if you think there's something we should
say as part of this charter review, or if you think we should
support or oppose it.

One longstanding concern for me with this work is to what extent it
defines an API that lets an Google-made browser talk to a Google
screen, and an Apple-made browser talk to an Apple screen, versus to
what extent it allows any browser to talk to any screen that
supports a particular piece of technology.  I think there might
have been some encouraging news on this front at TPAC in November,
but I don't remember the details.  But if there was, I'd rather
expect it to be incorporated into this charter, but I don't really
see that after a first read.  I'm curious what others know and think
about this issue.

-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: Refactoring proposal for the observer service

[smaug]

On 01/04/2018 12:30 AM, Ben Kelly wrote:

On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto  wrote:


So after validating my approach in that bug (which is almost ready) I've
thought that it might be time to give the observer service the same
treatment. First of all we'd have a list of topics (I've picked YAML for
the list but it could be anything that fits the bill):



Could we use our existing idl/webidl/ipdl for this?  It would be nice not
to have to maintain another code generator in the tree if possible.


Yeah, I was thinking this too. I really wish we don't add yet another code 
generator.
idl or webidl should be ok.
But I see artifact builds being rather big issue here(, even though I don't 
personally use them).
Building FF has become so very slow, that avoiding extra build steps whenever 
possible should be a goal.
We should try to make our platform easier to approach, not harder.




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

Re: Refactoring proposal for the observer service

[Gijs Kruitbosch]

This is really interesting, thanks for looking at this!

On 03/01/2018 22:09, Gabriele Svelto wrote:

This would have quite a few coding benefits:
- It would make it far easier to retire/rename a topic, since ... JS would 
throw.


Why would it? I think it would pass undefined (as the topic wouldn't 
exist on the "ObserverTopics" object) which I expect would get coerced 
by xpconnect to just '0'. Unless we either use a Proxy for the JS 
implementation that throws when you access an unknown property (which 
would be runtime-expensive) or unless WebIDL provides a way to do this 
that avoids the coercion when passing it to an observer service method, 
and instead throws from that method if it gets passed `undefined` for a 
topic.



It would also help with code size, performance and memory use:


So, one thing that I have been thinking about in relation to 
https://bugzilla.mozilla.org/show_bug.cgi?id=1425466 is that the 
observer service when invoking lots of JS observers currently does 
(something like) this:


- get called from a single place (in JS/C++, doesn't matter much);
- get list of observers
- call each observer with the same arguments. For JS observers, this 
means crossing from C++ to JS, and back with exceptions or whatever


for cases where there are "many" observers for a single topic (x-ref 
https://bugzilla.mozilla.org/show_bug.cgi?id=1195386 ), this is going to 
be inefficient because we go back and forth across the xpconnect 
boundary N times for N observers, every time getting JS values/wrappers 
for the subject and data, etc. etc. This would be better if there was a 
JS side to things that handled all the dispatching to JS observers, and 
would "forward" exactly 1 observer to the 'real' observer service.


I'm not sure if the costs justify optimizing this. I haven't had time to 
profile this or see how often this happens if you don't run a browser 
session with hundreds or thousands of tabs (and tbh, most if not all the 
consumers which add that many observers ought to be optimized to Not Do 
That anyway).



> - One would not be able to add/remove/change a topic in an artifact
> build. I'm not sure how many JS-only users of the observer service there
> are but if they're not many then this wouldn't be a big deal.

Unfortunately, there are quite a lot ( 
https://searchfox.org/mozilla-central/search?q=obs.addObserver=false=false= 
-- sync, the add-ons manager, session store, etc. etc.). We run into 
this problem with other things as well - telemetry being one that 
currently does something like what you propose (so we can't change it in 
an artifact build and that's pretty annoying) and I know Nicholas 
Nethercote (CC'd) has been looking at making the prefs behave similarly.


Ideally, I would like a solution where especially JS-only observer 
topics don't require a non-artifact build. A JS forwarder for the "real" 
observer service may help with that goal, by making the "new" arguments 
into strings transparently, and using the same string as a webidl name 
property for artifact builds. This would mean "new" JS-only observer 
calls in an artifact build would be slower than the int-based "real" 
ones (and would perform "normally" once you actually did a "real" build, 
ditto for distributed stuff). I think that's an OK trade-off.


Put differently, if we end up in a place where touching any prefs, 
telemetry or observers means frontend folks can't use artifact builds, 
that'll have significant negative impact on our development speed, as 
well as the ability of new contributors to build and contribute code to 
Firefox.


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

Re: Device Orientation API future

[Martin Thomson]

On Thu, Jan 4, 2018 at 2:52 AM, Blair MacIntyre  wrote:
> I was more concerned about the idea (or, at least what I though might be
> suggested) that you only get orientation if they give location permission.
> This seems overkill:  even if I know what the data means, I can see uses of
> orientation that I’d be comfortable with but that I wouldn’t be comfortable
> giving my geolocation.  that’s all I was talking about.

I guess that someone needs to work out how to control access to
orientation without invoking that prompt then.  I think that we could
easily give access to orientation with geolocation, but I can see that
there are plenty of cases for orientation *without* geolocation.
Could we explore the gross movement idea some more?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Refactoring proposal for the observer service

[Ben Kelly]

On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto  wrote:

> So after validating my approach in that bug (which is almost ready) I've
> thought that it might be time to give the observer service the same
> treatment. First of all we'd have a list of topics (I've picked YAML for
> the list but it could be anything that fits the bill):
>

Could we use our existing idl/webidl/ipdl for this?  It would be nice not
to have to maintain another code generator in the tree if possible.

Otherwise seems like a good idea.

Thanks.

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

Re: Refactoring proposal for the observer service

[Botond Ballo]

On Wed, Jan 3, 2018 at 5:09 PM, Gabriele Svelto  wrote:
> - It would make trivially simple to document the topics, their subjects
> and payloads. Potentially this could even be integrated with our
> generated documentation and code search tools making developer lives a
> lot easier.

+1. Not having a place to "declare" / document observer messages has
been one of the things bothering me about the observer service for a
long time.

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

Re: Refactoring proposal for the observer service

[David Teller]

That would be great!

On 03/01/18 23:09, Gabriele Svelto wrote:
> TL;DR this is a proposal to refactor the observer service to use a
> machine-generated list of integers for the topics (disguised as enums/JS
> constants) instead of arbitrary strings.
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Refactoring proposal for the observer service

[Gabriele Svelto]

TL;DR this is a proposal to refactor the observer service to use a
machine-generated list of integers for the topics (disguised as enums/JS
constants) instead of arbitrary strings.

Long version:

I've been working on bug 1348273 [1] in an attempt to gather all our
crash annotations into a machine-readable list that could be used to
generate a list of (named) constants. Specifically an enumeration for
C++ and a frozen object holding constant fields for JS. These constants
would then be used instead of the strings when invoking the crash
annotation interface.

As I was hacking this stuff together it occurred to me that the observer
service has the same kind of interface and the same kind of issues:
figuring out what a particular topic is for is quite hard, and often
requires a fair amount of grep'ing and hg blame'ing to figure out where
it's coming from and what it does. There's no single place where it can
be documented. There's no way to tell what the subject is and what the
data string contains (and if it contains a string at all, I've seen
callers stuffing a pointer to a non-string object in there). Retiring or
renaming a topic is also a nightmare, as it's extremely hard to verify
that you've fixed all its uses.

So after validating my approach in that bug (which is almost ready) I've
thought that it might be time to give the observer service the same
treatment. First of all we'd have a list of topics (I've picked YAML for
the list but it could be anything that fits the bill):

QuitApplication:
  description: Notification sent when the application is about to quit

ProfileBeforeChange:
  description: Notification sent before the profile is lost

...

Which would generate a C++ enum:

// Generated enum
enum class ObserverTopic : uint32_t {
  QuitApplication = 0,
  ProfileBeforeChange = 1,
  ...
}

And a JS object:

const ObserverTopic = Object.freeze({
  QuitApplication: 0,
  ProfileBeforeChange: 1,
  ...
}

Callers would change so that they'd look like this:

os->NotifyObservers(nullptr, ObserverTopic::QuitApplication, nullptr);

Or this:

Services.obs.notifyObservers(null, ObserverTopic.QuitApplication);

Pretty straightforward stuff.

This would have quite a few coding benefits:

- It would make trivially simple to document the topics, their subjects
and payloads. Potentially this could even be integrated with our
generated documentation and code search tools making developer lives a
lot easier.

- It would make it far easier to retire/rename a topic, since C++ code
still using an unknown topic would fail to compile, and JS would throw.

- It would prevent typos from slipping in.

- It would make the naming consistent (compared to current things like
"apz:cancel-autoscroll", "APZ:FlushActiveCheckerboard" and
"apz-repaints-flushed").

It would also help with code size, performance and memory use:

- It makes the generated code a lot leaner, since the identifiers are
now integers under the hood, which require far less code to handle than
strings. For reference, on a Linux PGO build my patch for bug 1348273
shrinks libxul.so by ~35KiB while touching only ~100 call sites, the
observer service has thousands.

- We wouldn't need a hash-table anymore. A fixed-size array of topics,
each holding a vector of listeners, suffices and it can be indexed
directly. Besides the obvious performance improvements (no string
comparisons, no need to walk a sparse structure with all the cache/TLB
effects that come with it) it would also save memory.

While the above effects would be hard to measure (and possibly below the
noise threshold) they would definitely be there; and as we learned with
Quantum significant performance improvements in a codebase as large as
Firefox often come from plenty of small fixes.

This isn't without drawbacks though. The biggest ones I could think of
would be:

- We'd have a new header file that would be included in a lot of places,
and adding, removing or changing a topic would touch it, causing much
recompile.

- One would not be able to add/remove/change a topic in an artifact
build. I'm not sure how many JS-only users of the observer service there
are but if they're not many then this wouldn't be a big deal.

- This would most certainly need significant changes in Thunderbird too,
but I'd help with that, I promise.

So, what do you think? This is non-trivial work but I think that it
would be worth the fuss.

 Gabriele

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1348273
Make AnnotateCrashReport() more robust by turning annotations into a
well known list of constants



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

Re: Intent to implement: support CSS paint-order for HTML text

[fantasai]

On 12/24/2017 04:54 PM, James Graham wrote:

On 24/12/2017 13:13, Emilio Cobos Álvarez wrote:

On 12/24/2017 02:01 PM, Jonathan Kew wrote:

Tests - Is this feature fully tested by web-platform-tests? No, as it is
not yet spec'd (see above). I propose to land a basic mozilla reftest
along with the patches in bug 1426146 (behind a pref); if/when the CSS
WG agrees to accept this issue in the spec, we can migrate the reftest
to WPT


Just FYI, other people land tests into WPT with .tentative.html in the
name, like:

   https://github.com/w3c/web-platform-tests/pull/8602

Not sure what's preferred, I believe that if the chances of this getting
spec'd are high it may be better, but...

James, do you know whether there's any official guideline for these kind
of situations?


The .tentative.html thing is an accepted convention for stuff that tests the presumed behaviour of a future spec, although 
it's possible that there aren't any CSS tests using the pattern yet.


I would certainly encourage using it here rather than having to remember to 
upstream a test at some later date.


As the editor of the spec in question, I can say that the only reason the
issue was open was because we were looking for some combination of implementer
interest and/or confirmation that this is a sane thing to do. jfkthame's intent
to implement is even more formal of a confirmation than we were looking for. :)

I should be able to run it officially past the CSSWG in a few hours, also, and
will prioritize the edit to remove the issue for like tomorrow or something if
that makes things easier. :)

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

Re: Intent to unship: navigator.registerContentHandler()

[Jonathan Kingston]

> I like the approach of  disabling a feature (behind a pref) in
non-Release (Beta and Nightly) for a few releases, to see what surfaces in
bug reports.

This is reasonable, it is the approach we will be taking with the device
sensors. Obviously it takes a little more work however I'm guessing the
breakage risk will be higher than events .

As you mention, I'm going to propose that we move to implement a pref to
disable this feature instead. In Nightly and early beta enable this pref by
default and see if we have any issues.

Thanks
Jonathan

On Wed, Jan 3, 2018 at 7:49 PM, Mike Taylor  wrote:

> Hi Jonathan,
>
> > On Jan 3, 2018, at 9:15 AM, Jonathan Kingston  wrote:
> > There is a small risk of breakage that we could decide to delay and
> instead
> > implement telemetry. However if the site is feature testing rather than
> > user agent testing there shouldn't be an issue here. As this API throws
> > errors there is likelihood websites account for it throwing anyway. I
> would
> > prefer however to let the removal ride the trains due to it's low risk
> > before 61 so our ESR doesn't have it.
>
> I’m never confident sites are doing feature detection or handling errors…
> I like the approach of  disabling a feature (behind a pref) in non-Release
> (Beta and Nightly) for a few releases, to see what surfaces in bug reports.
>
> > - Is only implemented by Firefox
>
> (It was also in Opera Presto 11.60+, RIP)
>
> --
> Mike Taylor
> Web Compat, Mozilla
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: navigator.registerContentHandler()

[Mike Taylor]

Hi Jonathan,

> On Jan 3, 2018, at 9:15 AM, Jonathan Kingston  wrote:
> There is a small risk of breakage that we could decide to delay and instead
> implement telemetry. However if the site is feature testing rather than
> user agent testing there shouldn't be an issue here. As this API throws
> errors there is likelihood websites account for it throwing anyway. I would
> prefer however to let the removal ride the trains due to it's low risk
> before 61 so our ESR doesn't have it.

I’m never confident sites are doing feature detection or handling errors… I 
like the approach of  disabling a feature (behind a pref) in non-Release (Beta 
and Nightly) for a few releases, to see what surfaces in bug reports.

> - Is only implemented by Firefox

(It was also in Opera Presto 11.60+, RIP)

--
Mike Taylor
Web Compat, Mozilla


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

Re: Device Orientation API future

[Daniel Veditz]

On Wed, Jan 3, 2018 at 7:48 AM, Jonathan Kingston  wrote:

> For GPS we only ever talk about "location", I still don't think that is a
> far stretch from head/position tracking.
>

​Users aren't going to understand why their tilt-the-tablet labyrinth game
needs to know they're in Brighton in order to work.

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

Re: Device Orientation API future

[Blair MacIntyre]

I would tend to think that GPS location is more sensitive then device 
orientation, and so exposing device orientation if they’ve given location perms 
seems like a good avenue to explore, yes.

I was more concerned about the idea (or, at least what I though might be 
suggested) that you only get orientation if they give location permission.  
This seems overkill:  even if I know what the data means, I can see uses of 
orientation that I’d be comfortable with but that I wouldn’t be comfortable 
giving my geolocation.  that’s all I was talking about.

> On Jan 3, 2018, at 10:48 AM, Jonathan Kingston  wrote:
> 
> When the language for the permission prompt isn't going to be clear about 
> what the user is exposing (screen, camera and mic) we should be talking about 
> risks.
> 
> For GPS we only ever talk about "location", I still don't think that is a far 
> stretch from head/position tracking.
> 
> On Wed, Jan 3, 2018 at 2:47 PM, Blair MacIntyre  > wrote:
> I don’t think tying orientation to GPS is really a viable approach.
> 
> The main use case for the orientation API, I think, is not AR;  it’s 360 
> images and videos, and “cardboard VR”, right now.
> 
> > On Jan 1, 2018, at 5:01 PM, Martin Thomson  > > wrote:
> >
> > The suggestion that was made in the past was to tie orientation to
> > geolocation.  I think that this would be obvious enough to pass.
> > Orientation is basically a refinement of position.  It clearly makes
> > sense for AR applications.  Pure VR applications might only care about
> > relative orientation and so might suffer a little.
> >
> > I realize that friction is always a concern, but the amount of
> > side-channel information that leaks through the API is hard to ignore.
> > I think that a prompt is wise, while we investigate ways in which we
> > might improve the UX.
> >
> > For instance, we could attempt to interpret gross movement as a
> > deliberate indication of intent.  Then sites could use this to
> > implement their own permission process ("shake your phone/head to
> > start").
> >
> > On Fri, Dec 22, 2017 at 2:52 AM, Jonathan Kingston  > > wrote:
> >> Following the intent to deprecate filed on Sunday for the Ambient Light and
> >> Proximity sensor APIs
> >>  >> >,
> >> we propose to discuss the future of the Device Orientation API.
> >>
> >> DeviceOrientation
> >>  >> >
> >> (deviceorientation, deviceorientationabsolute, and devicemotion events) has
> >> far more usage than the other two sensor APIs and so we need to be more
> >> careful with it to prevent breakage.
> >>
> >> Currently this API is restricted to first party domain scripts only,
> >> however Chrome has filed an intent to ship to have a feature policy to
> >> enable this in third party scripts
> >>  >>  
> >> >.
> >> This would mean that advertisements and others would have unrestricted
> >> access to the users sensor information assuming they’re included through an
> >> iframe with the relevant allow attribute set.
> >>
> >> Risks
> >>
> >> Some of the keylogging risks are outlined in papers [1] and [2], however
> >> there are also risks of the user being identified by physical or
> >> environmental factors like mapping the swing of the device to walking gate
> >> patterns and the angle and shaking of the phone to match to patterns in
> >> altitude and terrain type.
> >>
> >> The current API provides unprompted floating point precision of sensor data
> >> at 60hz to the website.
> >>
> >> Generic sensor API
> >>
> >> These APIs are being replaced by the work on the generic sensor API as
> >> outlined in the following TAG thread
> >>  >> >, though it’s
> >> currently unclear how to properly deal with the risks of sensors other than
> >> throttling. It’s unclear that throttling sufficiently addresses the risks
> >> and also makes them a poor choice for VR.
> >>
> >> Chrome has stated their plan for the UX of the generic sensor API
> >>  >>  
> >> >
> >> and it doesn’t address the unprompted access to sensors, nor do we feel
> >> showing a new indicator about sensor usage goes far enough to mitigate the
> >> 

Re: Device Orientation API future

[Jonathan Kingston]

When the language for the permission prompt isn't going to be clear about
what the user is exposing (screen, camera and mic) we should be talking
about risks.

For GPS we only ever talk about "location", I still don't think that is a
far stretch from head/position tracking.

On Wed, Jan 3, 2018 at 2:47 PM, Blair MacIntyre 
wrote:

> I don’t think tying orientation to GPS is really a viable approach.
>
> The main use case for the orientation API, I think, is not AR;  it’s 360
> images and videos, and “cardboard VR”, right now.
>
> > On Jan 1, 2018, at 5:01 PM, Martin Thomson  wrote:
> >
> > The suggestion that was made in the past was to tie orientation to
> > geolocation.  I think that this would be obvious enough to pass.
> > Orientation is basically a refinement of position.  It clearly makes
> > sense for AR applications.  Pure VR applications might only care about
> > relative orientation and so might suffer a little.
> >
> > I realize that friction is always a concern, but the amount of
> > side-channel information that leaks through the API is hard to ignore.
> > I think that a prompt is wise, while we investigate ways in which we
> > might improve the UX.
> >
> > For instance, we could attempt to interpret gross movement as a
> > deliberate indication of intent.  Then sites could use this to
> > implement their own permission process ("shake your phone/head to
> > start").
> >
> > On Fri, Dec 22, 2017 at 2:52 AM, Jonathan Kingston 
> wrote:
> >> Following the intent to deprecate filed on Sunday for the Ambient Light
> and
> >> Proximity sensor APIs
> >>  platform/DcSi_wLG4fc>,
> >> we propose to discuss the future of the Device Orientation API.
> >>
> >> DeviceOrientation
> >> 
> >> (deviceorientation, deviceorientationabsolute, and devicemotion events)
> has
> >> far more usage than the other two sensor APIs and so we need to be more
> >> careful with it to prevent breakage.
> >>
> >> Currently this API is restricted to first party domain scripts only,
> >> however Chrome has filed an intent to ship to have a feature policy to
> >> enable this in third party scripts
> >>  blink-dev/RX0GN4PyCF8/6XVhJ_oTCgAJ>.
> >> This would mean that advertisements and others would have unrestricted
> >> access to the users sensor information assuming they’re included
> through an
> >> iframe with the relevant allow attribute set.
> >>
> >> Risks
> >>
> >> Some of the keylogging risks are outlined in papers [1] and [2], however
> >> there are also risks of the user being identified by physical or
> >> environmental factors like mapping the swing of the device to walking
> gate
> >> patterns and the angle and shaking of the phone to match to patterns in
> >> altitude and terrain type.
> >>
> >> The current API provides unprompted floating point precision of sensor
> data
> >> at 60hz to the website.
> >>
> >> Generic sensor API
> >>
> >> These APIs are being replaced by the work on the generic sensor API as
> >> outlined in the following TAG thread
> >> , though it’s
> >> currently unclear how to properly deal with the risks of sensors other
> than
> >> throttling. It’s unclear that throttling sufficiently addresses the
> risks
> >> and also makes them a poor choice for VR.
> >>
> >> Chrome has stated their plan for the UX of the generic sensor API
> >>  MxJjxNJ3wk9KHo/edit#>
> >> and it doesn’t address the unprompted access to sensors, nor do we feel
> >> showing a new indicator about sensor usage goes far enough to mitigate
> the
> >> risk.
> >>
> >> We feel that Firefox should prompt users in some manner when accessing
> >> granular sensor information. Until these concerns are mitigated it
> seems we
> >> shouldn’t open up access to these sensors via a feature policy to third
> >> parties.
> >>
> >> Ideas to reduce user risk from the current API:
> >>
> >> - Dialling down the precision of this event or frequency it is fired
> from
> >> 60hz to 5hz however this would limit it’s usage in Web VR.
> >>
> >> - Restrict to secure contexts; this reduces some risk in particular with
> >> man-in-the-middle proxies that modify traffic, but is not going to
> address
> >> the overall issue on its own
> >>
> >> - We could place these events behind a permission prompt preventing
> drive
> >> by usage; a big problem with this suggestion is that it’s unclear what
> to
> >> ask the user
> >>
> >> - Restrict access to only the active tab
> >>
> >> Kind regards,
> >>
> >> Anne van Kesteren, Jonathan Kingston, and Frederik Braun
> >>
> >> [1] https://www.usenix.org/legacy/event/hotsec11/tech/final_
> files/Cai.pdf
> >>
> >> [2] https://dl.acm.org/citation.cfm?id=2714650
> >> 

Intent to unship: navigator.registerContentHandler()

[Jonathan Kingston]

I am suggesting the removal of navigator.registerContentHandler

API used to register a web page to handle content types.

Firefox has an implementation that only can be used to allow a web page to
handle RSS feeds. We don't have telemetry on this feature however we do
know that registerProtocolHandler has around 0.2% usage and this feature is
implemented in multiple browsers and isn't specific to Firefox.

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1398169

There is a small risk of breakage that we could decide to delay and instead
implement telemetry. However if the site is feature testing rather than
user agent testing there shouldn't be an issue here. As this API throws
errors there is likelihood websites account for it throwing anyway. I would
prefer however to let the removal ride the trains due to it's low risk
before 61 so our ESR doesn't have it.

Alternatively we could restrict this API to Secure Context only due to the
risk of passing web content to an insecure context. This would be aligned
with our overall plan regarding HTTP APIs.

Removal of this feature requires the removal of some internal tests and to
stop ignoring a web platform test.

The rationale:

- This API had bugs filed on it's implementation
- Is only implemented by Firefox
- The API is now non standard
- No other browsers have intent to implement

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

Re: overly strict eslint rules

[Mark Banner]

On 24/12/2017 22:07, Masatoshi Kimura wrote:

I got the following error when I tried it just now:
As far as I know, it should work fine with the latest version of 
MozillaBuild. If it doesn't, please file a bug in Testing:Lint and we'll 
take a look.

---
$ mach lint browser/base/content/aboutDialog.js
eslint-plugin-html v2.0.3 should be v4.0.0.
ESLint is an old version, clobbering node_modules directory
Clobbering node_modules...
Installing eslint for mach using
"d:\mozilla-build\node-v8.1.4-win-x64\npm.cmd install --loglevel=error"...
npm ERR! code ENOLOCAL
npm ERR! Could not install from
"tools\lint\eslint\eslint-plugin-mozilla" as it does not contain a
package.json file.
In this case, I think it incorrectly removed the 
tools\lint\eslint\eslint-plugin-mozilla directory, if you check your 
source tree diffs, you should see if that was the case or not (though 
since this was a while ago, you may have already found that by now).


I've a feeling I know why, unfortunately my windows environment isn't 
very good at the moment, so I'll need to get that updated to investigate.


Mark.
___
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 think tying orientation to GPS is really a viable approach.

The main use case for the orientation API, I think, is not AR;  it’s 360 images 
and videos, and “cardboard VR”, right now.  

> On Jan 1, 2018, at 5:01 PM, Martin Thomson  wrote:
> 
> The suggestion that was made in the past was to tie orientation to
> geolocation.  I think that this would be obvious enough to pass.
> Orientation is basically a refinement of position.  It clearly makes
> sense for AR applications.  Pure VR applications might only care about
> relative orientation and so might suffer a little.
> 
> I realize that friction is always a concern, but the amount of
> side-channel information that leaks through the API is hard to ignore.
> I think that a prompt is wise, while we investigate ways in which we
> might improve the UX.
> 
> For instance, we could attempt to interpret gross movement as a
> deliberate indication of intent.  Then sites could use this to
> implement their own permission process ("shake your phone/head to
> start").
> 
> On Fri, Dec 22, 2017 at 2:52 AM, Jonathan Kingston  wrote:
>> Following the intent to deprecate filed on Sunday for the Ambient Light and
>> Proximity sensor APIs
>> ,
>> we propose to discuss the future of the Device Orientation API.
>> 
>> DeviceOrientation
>> 
>> (deviceorientation, deviceorientationabsolute, and devicemotion events) has
>> far more usage than the other two sensor APIs and so we need to be more
>> careful with it to prevent breakage.
>> 
>> Currently this API is restricted to first party domain scripts only,
>> however Chrome has filed an intent to ship to have a feature policy to
>> enable this in third party scripts
>> .
>> This would mean that advertisements and others would have unrestricted
>> access to the users sensor information assuming they’re included through an
>> iframe with the relevant allow attribute set.
>> 
>> Risks
>> 
>> Some of the keylogging risks are outlined in papers [1] and [2], however
>> there are also risks of the user being identified by physical or
>> environmental factors like mapping the swing of the device to walking gate
>> patterns and the angle and shaking of the phone to match to patterns in
>> altitude and terrain type.
>> 
>> The current API provides unprompted floating point precision of sensor data
>> at 60hz to the website.
>> 
>> Generic sensor API
>> 
>> These APIs are being replaced by the work on the generic sensor API as
>> outlined in the following TAG thread
>> , though it’s
>> currently unclear how to properly deal with the risks of sensors other than
>> throttling. It’s unclear that throttling sufficiently addresses the risks
>> and also makes them a poor choice for VR.
>> 
>> Chrome has stated their plan for the UX of the generic sensor API
>> 
>> and it doesn’t address the unprompted access to sensors, nor do we feel
>> showing a new indicator about sensor usage goes far enough to mitigate the
>> risk.
>> 
>> We feel that Firefox should prompt users in some manner when accessing
>> granular sensor information. Until these concerns are mitigated it seems we
>> shouldn’t open up access to these sensors via a feature policy to third
>> parties.
>> 
>> Ideas to reduce user risk from the current API:
>> 
>> - Dialling down the precision of this event or frequency it is fired from
>> 60hz to 5hz however this would limit it’s usage in Web VR.
>> 
>> - Restrict to secure contexts; this reduces some risk in particular with
>> man-in-the-middle proxies that modify traffic, but is not going to address
>> the overall issue on its own
>> 
>> - We could place these events behind a permission prompt preventing drive
>> by usage; a big problem with this suggestion is that it’s unclear what to
>> ask the user
>> 
>> - Restrict access to only the active tab
>> 
>> Kind regards,
>> 
>> Anne van Kesteren, Jonathan Kingston, and Frederik Braun
>> 
>> [1] https://www.usenix.org/legacy/event/hotsec11/tech/final_files/Cai.pdf
>> 
>> [2] https://dl.acm.org/citation.cfm?id=2714650
>> ___
>> 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: overly strict eslint rules

[Alex Gaynor]

On Wed, Jan 3, 2018 at 4:43 AM, Mark Banner  wrote:

> On 24/12/2017 19:41, Ben Kelly wrote:
>
>> But I also see rules about cosmetic things like what kind of quotes must
>> be
>> used for strings.
>> AFAICT this kind of rule does not have any tangible safety benefit.  Its
>> purely a cosmetic style choice.  I don't see why we should bounce patches
>> out of the tree if the author and reviewer of a component prefer to use
>> single quotes instead of double quotes in a file.
>>
> As Jonathan already mentioned, the stylistic rules are designed to help
> enforce a consistent style, and reduce code review cycles to address review
> "nits" - benefiting both the submitter and reviewer.
>
> This also helps newcomers find and pick up the consist style quickly,
> rather than having to "examine the files in the component and work out the
> style that's used most" which is what we've had in the past.
>
>
It's also of tremendous value to those of us whose work on Firefox requires
them to interact with many different components; consistency across the
codebase is a huge boon to our ability to dive into new things as they're
needed.

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

Re: overly strict eslint rules

[Mark Banner]

On 24/12/2017 19:41, Ben Kelly wrote:

But I also see rules about cosmetic things like what kind of quotes must be
used for strings.
AFAICT this kind of rule does not have any tangible safety benefit.  Its
purely a cosmetic style choice.  I don't see why we should bounce patches
out of the tree if the author and reviewer of a component prefer to use
single quotes instead of double quotes in a file.
As Jonathan already mentioned, the stylistic rules are designed to help 
enforce a consistent style, and reduce code review cycles to address 
review "nits" - benefiting both the submitter and reviewer.


This also helps newcomers find and pick up the consist style quickly, 
rather than having to "examine the files in the component and work out 
the style that's used most" which is what we've had in the past.


As a side note - the quotes rule was introduced at the request of 
Firefox peers to have consistent use of quotes across style (a 
consistent review nit, and frequently missed).

I also find this kind of cosmetic rule especially frustrating because we do
not run eslint by default.  AFAIK it does not even install with mach
bootstrap.  If we are going to enforce this kind of thing these checks
should be run as part of a build or when executing tests.  They should not
require manual installation of tools and running separate commands.
Thank you for highlighting this. Last year we were working on improving 
our hook support, with the intention of getting bootstrap hooked up as 
well. We didn't get time for that, so that will be the first priority 
this year.


I'm not yet convinced about hooking it into build / test execution. We 
could do this, but there's a variety of issues about when we run them 
and if we do/don't fail, that would make it harder in various instances 
(e.g. we have a rule to disallow 'debugger' statements, but you might 
want to run the tests with it). This might need a separate discussion.



As a further anecdote, I have also had to fight eslint rules in devtools
which required things like simultaneously using an extreme indent value and
not exceeding a line width limit.  Basically conflicting and impossible
rules to satisfy.  I ended up wasting close to an hour figuring out an ugly
work around for the problem.  It did not feel like the lint was providing
value.
devtools started out with stricter rules overall. For ESLint for most of 
mozilla-central, I think we have been conservative on the more stylistic 
rules. Note, they can be disabled in various sections if it makes sense 
(e.g. some of the accessible files disable no-multi-spaces, as it makes 
sense for those code blocks, but not for other places in the tree). I 
think longer term, we should consider changing the ESLint stylistic 
rules to using something like the "prettier" tool across the tree 
(similar to clang-format but for javascript - automatically formats).


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