Intent to remove intl.uidirection pref

[Daniel Minor]

In Bug 1676137 I'm planning to remove the intl.uidirection pref. This pref
was introduced in Bug 1312049 to make it easier to test right-to-left (RTL)
locales, but since that time, pseudolocale support has been added to
Firefox.

For testing purposes, setting the intl.l10n.pseudo preference to "bidi" is
preferable. It switches the text direction to RTL, but it also decorates
the text, making it easier to notice unlocalized text.

In Bug 1673054 I consolidated existing test code to use the "bidi"
pseudolocale, and in Bug 1675789 I improved the readability of the "bidi"
text based upon developer feedback. Removing the intl.uidirection pref
would allow us to continue to consolidate and clean up the localization
code.

We have had feedback that some users use this pref to force left-to-right
layout while using a locale that is normally RTL, but this was never the
intended or supported use case for this preference. The proper way of
handling this would be to define a locale variant to support this and
submit it to the Unicode Common Locale Data Repository.

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

Intent to Remove: Fuzzyfox

[Tom Ritter]

Fuzzyfox[0] is an implementation of a research idea that severely
limits the data that can be extracted by timing side channels
exploited by untrusted JavaScript. It effectively provides a knob that
allows one to control the amount of data that can be extracted by
controlling the coarseness and fuzziness of the clock used by the
browser. In comparison to our existing clock fuzziness enabled now, it
operates in the context of the entire browser, rather than just the
explicit timers and clocks exposed to untrusted JavaScript - therefore
it also mitigates the data that can be extracted by constructed clocks
relying on e.g. web animations.

Unfortunately it does not address the fact that Shared Array Buffer
can be turned into a precise timer, it was written in the early days
of SAB and produces its results by disabling it.

We landed it two years ago[1], and had intended to explore it further
if needed for Spectre, as well as see if it could be used practically
to mitigate the multiple and various timing attacks that have been
demonstrated in browsers to steal user browser history,
cross-application user activity, cross-origin images or frame data,
etc etc.

We've never gotten to that examination, and it seems that we might
never; so in the interest of clarity and cleanliness it makes sense to
remove it.

Presently, if you enable privacy.fuzzyfox.enabled you will switch over
to Fuzzyfox mode. You will probably experience some jank and bowser
slowdown. Fuzzyfox affects the entire browser, and that does include
sleeping on the main thread[2] in certain circumstances. Had time been
available, the next steps would have been to get profiles of poor
browser behavior under Fuzzyfox, and try to understand why they were
occuring. (Setting privacy.fuzzyfox.clockgrainus too coarse would
cause expected slowness, but 250 ought to be a usable number, ideally
1000.)


This work will be done in https://bugzilla.mozilla.org/show_bug.cgi?id=1666222

-tom


[0] 
https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/kohlbrenner
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=fuzzyfox
[2] 
https://searchfox.org/mozilla-central/rev/02cb78667e87ccc42fea5edc6f3f2dd2edd6ecd5/toolkit/components/fuzzyfox/Fuzzyfox.cpp#212-216
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove: nsStackFrame aka. `display: -moz-stack` and related features

[Tim Nguyen]

Hi folks,

I’m planning to remove nsStackFrame in bug 1576946 [0]. This is part of a
larger effort to make the browser stop using XUL layouts and align on more
standard CSS layouts such as CSS grid or flexbox instead. The removal is
targeted for Firefox 72.

The removal includes these two non web-exposed features:
- `display: -moz-stack` and the `-moz-stack-sizing` property
- support for XUL absolute positioning attributes
(left/top/bottom/right/start/end XUL attributes), that only worked in
display: -moz-stack contexts

Note that the  element is not going away. It will instead be
implemented using a single-area CSS grid, so those usages won’t need to be
rewritten. However, if you were planning to use XUL absolute positioning
attributes, you’ll need to look into alternatives:
- `align-self: start` or `align-self: end` can be used to position the
element on the vertical axis if you were using `top="0"` or `bottom="0"`
- `justify-self: start` or `justify-self: end` can be used to position the
element on the horizontal axis if you were using `start="0"` or `end="0"`
- If you were using non-zero values in the attributes and the element is
using `display: block;` or a non-XUL block-level display value, you can use
CSS absolute positioning instead.
- If you were using non-zero values in the attributes with a XUL display
value, you can use a combination of `margin` and
`justify-self`/`align-self`, see this code change [1] as a reference.

Regarding `-moz-stack-sizing`, this property was used to determine whether
a certain element would influence the size of its parent. The current
usages in mozilla-central were only used for children of  [2] and
those usages didn’t seem to change visually with the new CSS grid-based
implementation of  which ignores the `-moz-stack-sizing` property,
so it made sense to remove it.

[0]: https://bugzilla.mozilla.org/show_bug.cgi?id=1576946
[1]: https://i.imgur.com/8hUDUDS.png
[2]:
https://searchfox.org/mozilla-central/search?q=-moz-stack-sizing&case=false®exp=false&path=

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

Re: Intent to remove: Fennec

[Nicholas Alexander]

Hi all,

On Thu, Sep 19, 2019 at 12:56 PM James Willcox  wrote:

> Folks,
>
> As you may be aware, Fennec has been frozen on 68 ESR with the expectation
> that Fenix will become the new Firefox for Android in 2020. For reasons of
> hygiene and simplification, I propose that we begin removing Fennec from
> mozilla-central as soon as feasible. There are a few known blockers
> currently being tracked under bug 1582218. If you know of any other issues,
> please let me know and/or file blockers.
>
> Obviously, we will not be removing anything related to GeckoView. This
> means that mobile/android/geckoview/, MOZ_WIDGET_ANDROID, etc. will all be
> sticking around. Only the Fennec frontend and any platform code that needed
> to disambiguate Fennec from GeckoView at runtime[0] will be targeted.
>

I just queued landing Bug 1580356
 which removes Fennec
(Firefox for Android) build support, source code, and various hangers on.
A Nightly-simulation try build was happy

so hopefully it sticks.

Please file follow-up depending on that ticket and blocking Bug 1582218
.

Good night and good luck,
Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove: Fennec

[mark . erikson]

Haha :)  I both appreciate the "request to get involved" aspect, as well as the 
subtle "STOP WHINING AND CONTRIBUTE SOMETHING USEFUL!" aspect... I've repeated 
that phrase more times than I can count myself :)

I actually am a maintainer of the Redux JS state management lib, so A) that 
already sucks up all my free time, and B) I'm mostly a JS and Python dev, and 
while I've done Java in the past, it's not my strong point (and really I'd 
rather not ever write Java again if I don't have to).

On Tuesday, September 24, 2019 at 9:12:08 PM UTC-4, Jared Hirsch wrote:
> Hey Mark,
> 
> Since you've traveled this far down the rabbit hole already, seems like I
> should just _casually mention_ that contributions are welcome ^_^
> 
> You can learn about Mozilla's next-gen Android browsers and browser
> components here, if you're interested:
> 
> https://mozac.org/contributing/
> https://mozac.org/blog/
> https://github.com/mozilla-mobile/fenix
> https://github.com/mozilla-mobile/android-components
> 
> If Android hacking isn't your thing, the contributor docs on MDN can help
> you explore other projects:
> 
> https://developer.mozilla.org/docs/Mozilla/Developer_guide
> 
> Feel free to ping me, too, with any questions.
> 
> Have fun!
> 
> Jared
> 
> On Tue, Sep 24, 2019 at 11:45 AM  wrote:
> 
> > Yeah, this kind of detail was really missing from the public statements
> > :)  I don't expect consumer-facing PR posts to go into nitty-gritty
> > technical details, but it wasn't apparent that there was really anything
> > more going on besides "nope, we're just going to rewrite it and move all
> > the UI around in the process".  Appreciate the info.
> >
> > On Tuesday, September 24, 2019 at 1:41:44 PM UTC-4, Kris Maglione wrote:
> > > On Tue, Sep 24, 2019 at 10:07:28AM -0700, mark.erik...@gmail.com wrote:
> > > >- I am very happy with the current Fennec app and its UI, and
> > > >don't understand why Mozilla feels a need to drop that product
> > > >and create a new one from scratch.
> > >
> > > We're not creating a new one from scratch. Many of the component
> > > parts of Fenix already existed, and the core is basically the
> > > same as Fennec. That said, there are many reasons:
> > >
> > > 1) GeckoView, which is a more or less drop-in replacement for
> > > Android's WebView, is designed to be used by any application
> > > which needs to embed web content on Android, including
> > > potentially other web browsers. It's an important part of our
> > > core mission to make sure the web remains a viable living
> > > standard, with multiple competing implementations, to avoid the
> > > sort of stagnation and vendor lock-in we saw when IE6
> > > essentially ruled the world.
> > >
> > > 2) We also already needed to maintain WebView-based browser
> > > front-ends for configurations where shipping our entire
> > > rendering back-end was not viable or practical. Given that we
> > > already need to maintain these separate, already-compatible
> > > front-end and back-end implementations, having to maintain an
> > > entirely separate browser with a completely different front-end,
> > > and a lot of different back-end glue, is just not a good use of
> > > resources.
> > >
> > > 3) GeckoView and the Fenix front-end are much more modern
> > > frameworks than Fennec. They were architected from the ground up
> > > using all of the knowledge and experience that we've gained
> > > developing Fennec and a number of other experimental browsers
> > > over the years. The result is that they are not only much easier
> > > to develop and maintain, but also much faster and more resource
> > > efficient.
> > >
> > > 4) The current Fennec browser, unlike Fenix and our desktop
> > > browsers, is very much single-process by design. Web content
> > > runs in the same process as the browser UI. The native Java UI
> > > allows us to use threading to work around some of the
> > > performance problems inherent in this sort of design, but it
> > > doesn't give us any of the security properties of process
> > > isolation, which are becoming increasingly important in the age
> > > of Spectre attacks. If we wanted to continue maintaining Fennec
> > > apart from Fenix, we would need to drastically rearchitect it to
> > > support process isolation for web content. And, given that
> > > Fenix and GeckoView were designed to handle this from the start,
> > > again, that would just not be a good use of resources.
> > >
> > > --
> > > Kris Maglione
> > >
> > > UNIX is simple.  It just takes a genius to understand its simplicity.
> > >   --Dennis Ritchie
> >
> > ___
> > 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: Intent to remove: Fennec

[Jared Hirsch]

Hey Mark,

Since you've traveled this far down the rabbit hole already, seems like I
should just _casually mention_ that contributions are welcome ^_^

You can learn about Mozilla's next-gen Android browsers and browser
components here, if you're interested:

https://mozac.org/contributing/
https://mozac.org/blog/
https://github.com/mozilla-mobile/fenix
https://github.com/mozilla-mobile/android-components

If Android hacking isn't your thing, the contributor docs on MDN can help
you explore other projects:

https://developer.mozilla.org/docs/Mozilla/Developer_guide

Feel free to ping me, too, with any questions.

Have fun!

Jared

On Tue, Sep 24, 2019 at 11:45 AM  wrote:

> Yeah, this kind of detail was really missing from the public statements
> :)  I don't expect consumer-facing PR posts to go into nitty-gritty
> technical details, but it wasn't apparent that there was really anything
> more going on besides "nope, we're just going to rewrite it and move all
> the UI around in the process".  Appreciate the info.
>
> On Tuesday, September 24, 2019 at 1:41:44 PM UTC-4, Kris Maglione wrote:
> > On Tue, Sep 24, 2019 at 10:07:28AM -0700, mark.erik...@gmail.com wrote:
> > >- I am very happy with the current Fennec app and its UI, and
> > >don't understand why Mozilla feels a need to drop that product
> > >and create a new one from scratch.
> >
> > We're not creating a new one from scratch. Many of the component
> > parts of Fenix already existed, and the core is basically the
> > same as Fennec. That said, there are many reasons:
> >
> > 1) GeckoView, which is a more or less drop-in replacement for
> > Android's WebView, is designed to be used by any application
> > which needs to embed web content on Android, including
> > potentially other web browsers. It's an important part of our
> > core mission to make sure the web remains a viable living
> > standard, with multiple competing implementations, to avoid the
> > sort of stagnation and vendor lock-in we saw when IE6
> > essentially ruled the world.
> >
> > 2) We also already needed to maintain WebView-based browser
> > front-ends for configurations where shipping our entire
> > rendering back-end was not viable or practical. Given that we
> > already need to maintain these separate, already-compatible
> > front-end and back-end implementations, having to maintain an
> > entirely separate browser with a completely different front-end,
> > and a lot of different back-end glue, is just not a good use of
> > resources.
> >
> > 3) GeckoView and the Fenix front-end are much more modern
> > frameworks than Fennec. They were architected from the ground up
> > using all of the knowledge and experience that we've gained
> > developing Fennec and a number of other experimental browsers
> > over the years. The result is that they are not only much easier
> > to develop and maintain, but also much faster and more resource
> > efficient.
> >
> > 4) The current Fennec browser, unlike Fenix and our desktop
> > browsers, is very much single-process by design. Web content
> > runs in the same process as the browser UI. The native Java UI
> > allows us to use threading to work around some of the
> > performance problems inherent in this sort of design, but it
> > doesn't give us any of the security properties of process
> > isolation, which are becoming increasingly important in the age
> > of Spectre attacks. If we wanted to continue maintaining Fennec
> > apart from Fenix, we would need to drastically rearchitect it to
> > support process isolation for web content. And, given that
> > Fenix and GeckoView were designed to handle this from the start,
> > again, that would just not be a good use of resources.
> >
> > --
> > Kris Maglione
> >
> > UNIX is simple.  It just takes a genius to understand its simplicity.
> >   --Dennis Ritchie
>
> ___
> 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: Intent to remove: Fennec

[mark . erikson]

Yeah, this kind of detail was really missing from the public statements :)  I 
don't expect consumer-facing PR posts to go into nitty-gritty technical 
details, but it wasn't apparent that there was really anything more going on 
besides "nope, we're just going to rewrite it and move all the UI around in the 
process".  Appreciate the info.

On Tuesday, September 24, 2019 at 1:41:44 PM UTC-4, Kris Maglione wrote:
> On Tue, Sep 24, 2019 at 10:07:28AM -0700, mark.erik...@gmail.com wrote:
> >- I am very happy with the current Fennec app and its UI, and 
> >don't understand why Mozilla feels a need to drop that product 
> >and create a new one from scratch.
> 
> We're not creating a new one from scratch. Many of the component 
> parts of Fenix already existed, and the core is basically the 
> same as Fennec. That said, there are many reasons:
> 
> 1) GeckoView, which is a more or less drop-in replacement for 
> Android's WebView, is designed to be used by any application 
> which needs to embed web content on Android, including 
> potentially other web browsers. It's an important part of our 
> core mission to make sure the web remains a viable living 
> standard, with multiple competing implementations, to avoid the 
> sort of stagnation and vendor lock-in we saw when IE6 
> essentially ruled the world.
> 
> 2) We also already needed to maintain WebView-based browser 
> front-ends for configurations where shipping our entire 
> rendering back-end was not viable or practical. Given that we 
> already need to maintain these separate, already-compatible 
> front-end and back-end implementations, having to maintain an 
> entirely separate browser with a completely different front-end, 
> and a lot of different back-end glue, is just not a good use of 
> resources.
> 
> 3) GeckoView and the Fenix front-end are much more modern 
> frameworks than Fennec. They were architected from the ground up 
> using all of the knowledge and experience that we've gained 
> developing Fennec and a number of other experimental browsers 
> over the years. The result is that they are not only much easier 
> to develop and maintain, but also much faster and more resource 
> efficient.
> 
> 4) The current Fennec browser, unlike Fenix and our desktop 
> browsers, is very much single-process by design. Web content 
> runs in the same process as the browser UI. The native Java UI 
> allows us to use threading to work around some of the 
> performance problems inherent in this sort of design, but it 
> doesn't give us any of the security properties of process 
> isolation, which are becoming increasingly important in the age 
> of Spectre attacks. If we wanted to continue maintaining Fennec 
> apart from Fenix, we would need to drastically rearchitect it to 
> support process isolation for web content. And, given that 
> Fenix and GeckoView were designed to handle this from the start, 
> again, that would just not be a good use of resources.
> 
> -- 
> Kris Maglione
> 
> UNIX is simple.  It just takes a genius to understand its simplicity.
>   --Dennis Ritchie

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

Re: Intent to remove: Fennec

[Botond Ballo]

On Tue, Sep 24, 2019 at 1:10 PM  wrote:
> - I have a _bunch_ of addons installed in Fennec.  uBlock Origin is by far 
> the most critical, but I have a number of other quality-of-life addons as 
> well.  Based on the articles I've seen, Fenix does not yet have any extension 
> support, so I can't even justify trying it out.

Note that this "intent to remove" email refers only to removing Fennec
code from our mainline development branch. It does not mean stopping
to ship Fennec right away. Fennec continues to be shipped from our ESR
68 branch, and will continue to do so until Fenix is considered ready
to replace it. My understanding is, extension support will definitely
be part of that.

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

Re: Intent to remove: Fennec

[Kris Maglione]

On Tue, Sep 24, 2019 at 10:07:28AM -0700, mark.erik...@gmail.com wrote:
- I am very happy with the current Fennec app and its UI, and 
don't understand why Mozilla feels a need to drop that product 
and create a new one from scratch.


We're not creating a new one from scratch. Many of the component 
parts of Fenix already existed, and the core is basically the 
same as Fennec. That said, there are many reasons:


1) GeckoView, which is a more or less drop-in replacement for 
Android's WebView, is designed to be used by any application 
which needs to embed web content on Android, including 
potentially other web browsers. It's an important part of our 
core mission to make sure the web remains a viable living 
standard, with multiple competing implementations, to avoid the 
sort of stagnation and vendor lock-in we saw when IE6 
essentially ruled the world.


2) We also already needed to maintain WebView-based browser 
front-ends for configurations where shipping our entire 
rendering back-end was not viable or practical. Given that we 
already need to maintain these separate, already-compatible 
front-end and back-end implementations, having to maintain an 
entirely separate browser with a completely different front-end, 
and a lot of different back-end glue, is just not a good use of 
resources.


3) GeckoView and the Fenix front-end are much more modern 
frameworks than Fennec. They were architected from the ground up 
using all of the knowledge and experience that we've gained 
developing Fennec and a number of other experimental browsers 
over the years. The result is that they are not only much easier 
to develop and maintain, but also much faster and more resource 
efficient.


4) The current Fennec browser, unlike Fenix and our desktop 
browsers, is very much single-process by design. Web content 
runs in the same process as the browser UI. The native Java UI 
allows us to use threading to work around some of the 
performance problems inherent in this sort of design, but it 
doesn't give us any of the security properties of process 
isolation, which are becoming increasingly important in the age 
of Spectre attacks. If we wanted to continue maintaining Fennec 
apart from Fenix, we would need to drastically rearchitect it to 
support process isolation for web content. And, given that 
Fenix and GeckoView were designed to handle this from the start, 
again, that would just not be a good use of resources.


--
Kris Maglione

UNIX is simple.  It just takes a genius to understand its simplicity.
--Dennis Ritchie

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

Re: Intent to remove: Fennec

[mark . erikson]

Heh.  No, I haven't tried Fenix, which I realize also makes it a bit harder to 
take my complaints seriously :)

Having said that:

- I am very happy with the current Fennec app and its UI, and don't understand 
why Mozilla feels a need to drop that product and create a new one from 
scratch.  I know there's mentions of a "GeckoView" piece that sounds like it 
makes embedding easier, but I don't know why that can't be plugged into the 
existing Fenix codebase.
- I have a _bunch_ of addons installed in Fennec.  uBlock Origin is by far the 
most critical, but I have a number of other quality-of-life addons as well.  
Based on the articles I've seen, Fenix does not yet have any extension support, 
so I can't even justify trying it out.

There was a long HN discussion thread at 
https://news.ycombinator.com/item?id=20295694 a few months ago, which has a 
number of criticisms of this migration process.  I would generally agree with 
the criticisms in that thread, regarding Fenix vs Fennec, and general Mozilla 
priorities.  Given Mozilla's long-declining market share, throwing resources 
into rewriting the Android app for no obvious benefit seems like a waste, vs 
improving the desktop app further.

On Tuesday, September 24, 2019 at 3:47:13 AM UTC-4, Dirkjan Ochtman wrote:
> On Mon, Sep 23, 2019 at 10:51 PM  wrote:
> 
> > As a happy Fennec end user with no direct involvement with Mozilla, I'm
> > decidedly unhappy about the direction Mozilla seems to be going here.  I
> > don't expect this complaint to have any effect on plans, but FYI.
> >
> 
> Have you actually tried Fenix (Firefox Preview)? How did it fall short of
> your usage of Fennec?
> 
> Kind regards,
> 
> Dirkjan

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

Re: Intent to remove: Fennec

[Bobby Holley]

+1. This is a big milestone, and reflects countless hours of hard work
building our next-generation mobile stack. Congrats to everyone
involved!

On Thu, Sep 19, 2019 at 12:59 PM Kris Maglione  wrote:
>
> This sounds like a stellar plan.
>
> -Kris
>
> On Thu, Sep 19, 2019 at 02:55:56PM -0500, James Willcox wrote:
> >Folks,
> >
> >As you may be aware, Fennec has been frozen on 68 ESR with the expectation
> >that Fenix will become the new Firefox for Android in 2020. For reasons of
> >hygiene and simplification, I propose that we begin removing Fennec from
> >mozilla-central as soon as feasible. There are a few known blockers
> >currently being tracked under bug 1582218. If you know of any other issues,
> >please let me know and/or file blockers.
> >
> >Obviously, we will not be removing anything related to GeckoView. This
> >means that mobile/android/geckoview/, MOZ_WIDGET_ANDROID, etc. will all be
> >sticking around. Only the Fennec frontend and any platform code that needed
> >to disambiguate Fennec from GeckoView at runtime[0] will be targeted.
> >
> >Thanks,
> >James
>
> --
> Kris Maglione
>
> Of all the preposterous assumptions of humanity over humanity, nothing
> exceeds most of the criticisms made on the habits of the poor by the
> well-housed, well-warmed, and well-fed.
> --Herman Melville
>
> ___
> 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: Intent to remove: Fennec

[Dirkjan Ochtman]

On Mon, Sep 23, 2019 at 10:51 PM  wrote:

> As a happy Fennec end user with no direct involvement with Mozilla, I'm
> decidedly unhappy about the direction Mozilla seems to be going here.  I
> don't expect this complaint to have any effect on plans, but FYI.
>

Have you actually tried Fenix (Firefox Preview)? How did it fall short of
your usage of Fennec?

Kind regards,

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

Re: Intent to remove: Fennec

[mark . erikson]

As a happy Fennec end user with no direct involvement with Mozilla, I'm 
decidedly unhappy about the direction Mozilla seems to be going here.  I don't 
expect this complaint to have any effect on plans, but FYI.

On Thursday, September 19, 2019 at 3:59:09 PM UTC-4, Kris Maglione wrote:
> This sounds like a stellar plan.
> 
> -Kris
> 
> On Thu, Sep 19, 2019 at 02:55:56PM -0500, James Willcox wrote:
> >Folks,
> >
> >As you may be aware, Fennec has been frozen on 68 ESR with the expectation
> >that Fenix will become the new Firefox for Android in 2020. For reasons of
> >hygiene and simplification, I propose that we begin removing Fennec from
> >mozilla-central as soon as feasible. There are a few known blockers
> >currently being tracked under bug 1582218. If you know of any other issues,
> >please let me know and/or file blockers.
> >
> >Obviously, we will not be removing anything related to GeckoView. This
> >means that mobile/android/geckoview/, MOZ_WIDGET_ANDROID, etc. will all be
> >sticking around. Only the Fennec frontend and any platform code that needed
> >to disambiguate Fennec from GeckoView at runtime[0] will be targeted.
> >
> >Thanks,
> >James
> 
> -- 
> Kris Maglione
> 
> Of all the preposterous assumptions of humanity over humanity, nothing
> exceeds most of the criticisms made on the habits of the poor by the
> well-housed, well-warmed, and well-fed.
>   --Herman Melville

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

Re: Intent to remove: Fennec

[Kris Maglione]

This sounds like a stellar plan.

-Kris

On Thu, Sep 19, 2019 at 02:55:56PM -0500, James Willcox wrote:

Folks,

As you may be aware, Fennec has been frozen on 68 ESR with the expectation
that Fenix will become the new Firefox for Android in 2020. For reasons of
hygiene and simplification, I propose that we begin removing Fennec from
mozilla-central as soon as feasible. There are a few known blockers
currently being tracked under bug 1582218. If you know of any other issues,
please let me know and/or file blockers.

Obviously, we will not be removing anything related to GeckoView. This
means that mobile/android/geckoview/, MOZ_WIDGET_ANDROID, etc. will all be
sticking around. Only the Fennec frontend and any platform code that needed
to disambiguate Fennec from GeckoView at runtime[0] will be targeted.

Thanks,
James


--
Kris Maglione

Of all the preposterous assumptions of humanity over humanity, nothing
exceeds most of the criticisms made on the habits of the poor by the
well-housed, well-warmed, and well-fed.
--Herman Melville

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

Intent to remove: Fennec

[James Willcox]

Folks,

As you may be aware, Fennec has been frozen on 68 ESR with the expectation
that Fenix will become the new Firefox for Android in 2020. For reasons of
hygiene and simplification, I propose that we begin removing Fennec from
mozilla-central as soon as feasible. There are a few known blockers
currently being tracked under bug 1582218. If you know of any other issues,
please let me know and/or file blockers.

Obviously, we will not be removing anything related to GeckoView. This
means that mobile/android/geckoview/, MOZ_WIDGET_ANDROID, etc. will all be
sticking around. Only the Fennec frontend and any platform code that needed
to disambiguate Fennec from GeckoView at runtime[0] will be targeted.

Thanks,
James

[0] https://searchfox.org/mozilla-central/search?q=jni%3A%3AIsFennec&path=
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove Ambient Light and Proximity sensor APIs

[Roni Kantola]

Are there any reasons at all not to make this a feature that simply needs/asks 
a permission? 

Perhaps with a short additional text "Allowing might compromise privacy". Not 
only for ambient light and proximity sensors, but especially if you want to 
remove device orientation information too. We already have location and camera 
permissions, for example. They are much bigger privacy issues, but asking for a 
permission is rather ok. 

If a website asks to get permissions for all of those things, it kind of 
deteriorates usability, but it's for the website to decide whether they want to 
have that tradeoff, and for the user to decide whether they trust the website 
or want to allow something.

I am developing a citizen science website for mapping, and it becomes 
impossible if you simply deprecate everything. Perhaps an actual app might do 
the trick, though, but it can be suboptimal.

2018-03-01 14.03.33 UTC+2 Jonathan Kingston wrote:
> As an update here the code has landed in 60 from
> https://bugzilla.mozilla.org/show_bug.cgi?id=1359076
> 
> This adds:
> - Deprecation warnings for DeviceOrientation and DeviceMotion sensors.
> - Deprecation errors for AmbientLight and Proximity sensors.
> - Preferences to control all 4 sensors independently:
>   - "device.sensors.ambientLight.enabled" - devicelight event and
> DeviceLightEvent constructor.
>   - "device.sensors.proximity.enabled" - deviceproximity, userproximity
> events and  DeviceProximityEvent and UserProximityEvent constructors.
>  - "device.sensors.motion.enabled" - devicemotion event and
> DeviceMotionEvent constructor.
>  - "device.sensors.orientation.enabled" - deviceorientation event and
> DeviceOrientationEvent constructor.
> - In Nightly and Early beta releases the proximity and light sensors are
> disabled by default.
> 
> My plan is to deprecate light and proximity sensors in Stable Firefox in
> version 62 if no issues arise.
> 
> Please reach out if you have any questions or concerns.
> 
> Thanks
> Jonathan
> 
> On Tue, Dec 19, 2017 at 7:01 AM, Anne van Kesteren  wrote:
> 
> > On Mon, Dec 18, 2017 at 7:36 PM, Gervase Markham  wrote:
> > > appear.in, which supports both audio and video calling via WebRTC, works
> > > in Firefox for Android, although performance is not awesome on my Z3C
> > > Compact.
> > >
> > > It does not blank the screen when you place the device to your ear.
> >
> > There might be more secure ways we can address this use case. E.g.,
> > having a dedicated signal just for that, perhaps only given if the
> > user already granted access to the microphone and such.
> >
> > (And if something does require the full power of the proximity API, we
> > should first work out how to expose it securely. I'm sure folks can
> > come up with use cases for running arbitrary code as root too, but
> > that doesn't mean we can offer it.)
> >
> >
> > --
> > 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

Re: Intent to remove "-e10s" from treeherder group symbols and task labels

[Andrew Halberstadt]

This has now landed. So to re-iterate, if you see a "-1proc" suffix in the
task symbol that means it is running with e10s disabled. Otherwise e10s is
enabled. This symbol change will ride the trains (so you'll still see
"-e10s" on other branches for the time being).


On Wed, Apr 10, 2019 at 9:40 AM Andrew Halberstadt  wrote:

> I had about 5 independent suggestions of "-sp" and I agree that it is much
> better than "-fc". But another idea that came out of these conversations
> was "1proc" which also ticks all the boxes (only being a tiny bit longer
> than "e10s") and being even clearer than "-sp". I think I'll go with that
> one. Thanks to everyone for all the feedback!
>
> -Andrew
>
> On Wed, Apr 10, 2019 at 4:36 AM Jonathan Kew  wrote:
>
>> On 09/04/2019 20:44, Andrew Halberstadt wrote:
>> > Yeah, I did consider "non-e10s" for awhile and maybe it is the better
>> > choice. But here are my counter arguments:
>> >
>> > 1) One of the goals of this change is to de-clutter the treeherder UI.
>> > Using an 8 character symbol suffix runs counter to that goal (even if
>> it is
>> > still less cluttered overall).
>> > 2) People who use "e10s" in their |mach try fuzzy| queries out of muscle
>> > memory (or in saved presets) will accidentally select the exact
>> opposite of
>> > what they want.
>> > 3) For new contributors "e10s" is a code word anyway. It's just now they
>> > need to learn "fc" instead of "e10s".
>> >
>> > None of those are terribly compelling, but it's still enough to make me
>> > prefer "-fc".
>>
>> I think (1) and (2) here are good points; I'm less convinced by (3).
>> Yes, e10s is a code word, but it's one that is pretty long-established
>> and pervasive in the project and surrounding documentation (it even
>> shows up in the names of about:config settings). It appeared in
>> treeherder UI *because* it was a well-established term within the project.
>>
>> The proposed -fc suffix, on the other hand, seems gratuitously cryptic.
>> If it had suddenly appeared in treeherder, I'd have been totally
>> clueless as to its meaning; and even after seeing the announcement here,
>> it feels like an artificial label that's trying a bit too hard to come
>> up with a "clever" code where none is needed. It's not like we're
>> starting with a standard multi-process configuration, and launching a
>> grand "Fuel Cell" project that aims to merge the processes together.
>>
>> How about suffixing these jobs with -sp for "Single Process"? That would
>> be a lot more transparent, IMO.
>>
>> JK
>> ___
>> 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: Intent to remove "-e10s" from treeherder group symbols and task labels

[Andrew Halberstadt]

I had about 5 independent suggestions of "-sp" and I agree that it is much
better than "-fc". But another idea that came out of these conversations
was "1proc" which also ticks all the boxes (only being a tiny bit longer
than "e10s") and being even clearer than "-sp". I think I'll go with that
one. Thanks to everyone for all the feedback!

-Andrew

On Wed, Apr 10, 2019 at 4:36 AM Jonathan Kew  wrote:

> On 09/04/2019 20:44, Andrew Halberstadt wrote:
> > Yeah, I did consider "non-e10s" for awhile and maybe it is the better
> > choice. But here are my counter arguments:
> >
> > 1) One of the goals of this change is to de-clutter the treeherder UI.
> > Using an 8 character symbol suffix runs counter to that goal (even if it
> is
> > still less cluttered overall).
> > 2) People who use "e10s" in their |mach try fuzzy| queries out of muscle
> > memory (or in saved presets) will accidentally select the exact opposite
> of
> > what they want.
> > 3) For new contributors "e10s" is a code word anyway. It's just now they
> > need to learn "fc" instead of "e10s".
> >
> > None of those are terribly compelling, but it's still enough to make me
> > prefer "-fc".
>
> I think (1) and (2) here are good points; I'm less convinced by (3).
> Yes, e10s is a code word, but it's one that is pretty long-established
> and pervasive in the project and surrounding documentation (it even
> shows up in the names of about:config settings). It appeared in
> treeherder UI *because* it was a well-established term within the project.
>
> The proposed -fc suffix, on the other hand, seems gratuitously cryptic.
> If it had suddenly appeared in treeherder, I'd have been totally
> clueless as to its meaning; and even after seeing the announcement here,
> it feels like an artificial label that's trying a bit too hard to come
> up with a "clever" code where none is needed. It's not like we're
> starting with a standard multi-process configuration, and launching a
> grand "Fuel Cell" project that aims to merge the processes together.
>
> How about suffixing these jobs with -sp for "Single Process"? That would
> be a lot more transparent, IMO.
>
> JK
> ___
> 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: Intent to remove "-e10s" from treeherder group symbols and task labels

[Jonathan Kew]

On 09/04/2019 20:44, Andrew Halberstadt wrote:

Yeah, I did consider "non-e10s" for awhile and maybe it is the better
choice. But here are my counter arguments:

1) One of the goals of this change is to de-clutter the treeherder UI.
Using an 8 character symbol suffix runs counter to that goal (even if it is
still less cluttered overall).
2) People who use "e10s" in their |mach try fuzzy| queries out of muscle
memory (or in saved presets) will accidentally select the exact opposite of
what they want.
3) For new contributors "e10s" is a code word anyway. It's just now they
need to learn "fc" instead of "e10s".

None of those are terribly compelling, but it's still enough to make me
prefer "-fc".


I think (1) and (2) here are good points; I'm less convinced by (3). 
Yes, e10s is a code word, but it's one that is pretty long-established 
and pervasive in the project and surrounding documentation (it even 
shows up in the names of about:config settings). It appeared in 
treeherder UI *because* it was a well-established term within the project.


The proposed -fc suffix, on the other hand, seems gratuitously cryptic. 
If it had suddenly appeared in treeherder, I'd have been totally 
clueless as to its meaning; and even after seeing the announcement here, 
it feels like an artificial label that's trying a bit too hard to come 
up with a "clever" code where none is needed. It's not like we're 
starting with a standard multi-process configuration, and launching a 
grand "Fuel Cell" project that aims to merge the processes together.


How about suffixing these jobs with -sp for "Single Process"? That would 
be a lot more transparent, IMO.


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

Re: Intent to remove "-e10s" from treeherder group symbols and task labels

[Andrew Halberstadt]

Yeah, I did consider "non-e10s" for awhile and maybe it is the better
choice. But here are my counter arguments:

1) One of the goals of this change is to de-clutter the treeherder UI.
Using an 8 character symbol suffix runs counter to that goal (even if it is
still less cluttered overall).
2) People who use "e10s" in their |mach try fuzzy| queries out of muscle
memory (or in saved presets) will accidentally select the exact opposite of
what they want.
3) For new contributors "e10s" is a code word anyway. It's just now they
need to learn "fc" instead of "e10s".

None of those are terribly compelling, but it's still enough to make me
prefer "-fc".

On Tue, Apr 9, 2019 at 3:34 PM Sylvestre Ledru  wrote:

>
> Le 09/04/2019 à 21:26, Andrew Halberstadt a écrit :
> > Hi everyone,
> >
> > Almost all of our tasks in CI now run with e10s enabled, we only run
> > non-e10s
> > with Fennec and Linux32. Yet the "default" state in terms of our CI, is
> > still non-
> > e10s. You can see this by the presence of "-e10s" suffixes in task labels
> > and
> > treeherder symbols.
> >
> > To better reflect reality, I'd like to switch things around such that
> "e10s"
> > becomes the default state and non-e10s tasks are the ones that need
> special
> > labeling. In bug 1541527
> >  I have a patch
> that
> > removes all "-e10s" suffixes from
> > treeherder symbols and task labels, and adds a new "-fc" suffix to
> non-e10s
> > tasks.
> Thanks for doing that!
> > This change could potentially cause disruptions to things like saved
> |mach
> > try
> > fuzzy| presets or ActiveData queries that depend on the task label. *If
> you
> > can*
> > *think of any other possible reasons to hold off from landing please let
> me*
> > *know!* I'll wait a week for comment.
> >
> > Why -fc?
> What about "non-e10s"? I think code names aren't great for new comers
> and just make their life harder.
>
> Sylvestre
>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove "-e10s" from treeherder group symbols and task labels

[Sylvestre Ledru]

Le 09/04/2019 à 21:26, Andrew Halberstadt a écrit :

Hi everyone,

Almost all of our tasks in CI now run with e10s enabled, we only run
non-e10s
with Fennec and Linux32. Yet the "default" state in terms of our CI, is
still non-
e10s. You can see this by the presence of "-e10s" suffixes in task labels
and
treeherder symbols.

To better reflect reality, I'd like to switch things around such that "e10s"
becomes the default state and non-e10s tasks are the ones that need special
labeling. In bug 1541527
 I have a patch that
removes all "-e10s" suffixes from
treeherder symbols and task labels, and adds a new "-fc" suffix to non-e10s
tasks.

Thanks for doing that!

This change could potentially cause disruptions to things like saved |mach
try
fuzzy| presets or ActiveData queries that depend on the task label. *If you
can*
*think of any other possible reasons to hold off from landing please let me*
*know!* I'll wait a week for comment.

Why -fc?

What about "non-e10s"? I think code names aren't great for new comers
and just make their life harder.

Sylvestre


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

Intent to remove "-e10s" from treeherder group symbols and task labels

[Andrew Halberstadt]

Hi everyone,

Almost all of our tasks in CI now run with e10s enabled, we only run
non-e10s
with Fennec and Linux32. Yet the "default" state in terms of our CI, is
still non-
e10s. You can see this by the presence of "-e10s" suffixes in task labels
and
treeherder symbols.

To better reflect reality, I'd like to switch things around such that "e10s"
becomes the default state and non-e10s tasks are the ones that need special
labeling. In bug 1541527
 I have a patch that
removes all "-e10s" suffixes from
treeherder symbols and task labels, and adds a new "-fc" suffix to non-e10s
tasks.

This change could potentially cause disruptions to things like saved |mach
try
fuzzy| presets or ActiveData queries that depend on the task label. *If you
can*
*think of any other possible reasons to hold off from landing please let me*
*know!* I'll wait a week for comment.

Why -fc?

The electrolysis of water is the process of using electricity to break down
water
molecules into hydrogen and oxygen. A fuel cell is a device that can use
oxygen to convert the chemical energy of hydrogen into electricity, aka the
reverse process as electrolysis. Therefore "-fc" stands for "fuel cell", the
opposite of e10s. This is why engineers shouldn't be allowed to name
things..
other suggestions welcome.

Let me know if you have questions or concerns!
Thanks,
Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove DHE ciphers in Fx 64 (Was: Intent to remove DHE ciphers from WebRTC DTLS handshake)

[Nils Ohlmeier]

As the Telemetry data [1] shows no significant usage of the DHE ciphers in Beta 
63 and Nightly 64 we are planing to remove the DHE ciphers in Firefox 65.

Please voice your concerns now, if you have any.

Best
  Nils Ohlmeier

[1] 
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2018-10-01&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=beta%252F63&measure=WEBRTC_DTLS_CIPHER&min_channel_version=nightly%252F60&processType=*&product=Firefox&sanitize=0&sort_keys=submissions&start_date=2018-09-04&table=1&trim=0&use_submission_date=0

> On Aug 29, 2018, at 3:56 PM, Nils Ohlmeier  wrote:
> 
> Summary:
> 
> We are looking at removing the DHE cipher suites from the DTLS handshake in 
> Firefox soon.
> 
> Ciphers:
> - TLS_DHE_RSA_WITH_AES_128_CBC_SHA 
> - TLS_DHE_RSA_WITH_AES_256_CBC_SHA
> are the  two suites which we want to remove, because they are considered too 
> weak.
> 
> A Telemetry probe landed in Firefox 63 Nightly to monitor the usage of the 
> different cipher suites:
> https://telemetry.mozilla.org/new-pipeline/dist.html#measure=WEBRTC_DTLS_CIPHER
>  
> 
> 
> Bug tracking the deactivation:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1227519 
> 
> 
> Targeted release: Firefox 66
> 
> Best
>   Nils Ohlmeier

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

Re: Intent to remove DHE ciphers from WebRTC DTLS handshake

[Nicholas Alexander]

On Thu, Aug 30, 2018 at 2:15 PM, Nicholas Alexander 
wrote:

>
>
> On Wed, Aug 29, 2018 at 3:56 PM, Nils Ohlmeier 
> wrote:
>
>> Summary:
>>
>> We are looking at removing the DHE cipher suites from the DTLS handshake
>> in Firefox soon.
>>
>> Ciphers:
>> - TLS_DHE_RSA_WITH_AES_128_CBC_SHA
>> - TLS_DHE_RSA_WITH_AES_256_CBC_SHA
>> are the  two suites which we want to remove, because they are considered
>> too weak.
>>
>
> Are these suites considered "too weak" across the board?  For historical
> reasons Firefox for Android will handshake to Firefox Sync servers using
> these suites: https://searchfox.org/mozilla-central/rev/
> 05d91d3e02a0780f44599371005591d7988e2809/mobile/android/
> services/src/main/java/org/mozilla/gecko/background/
> common/GlobalConstants.java#73.  Sounds like we should drop those suites
> there too -- can you confirm?
>

After a little (off-list) discussion, I've filed
https://bugzilla.mozilla.org/show_bug.cgi?id=1487842 tracking dropping
these.

Thanks, Nils (and others)!
Nick
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove DHE ciphers from WebRTC DTLS handshake

[Nicholas Alexander]

On Wed, Aug 29, 2018 at 3:56 PM, Nils Ohlmeier 
wrote:

> Summary:
>
> We are looking at removing the DHE cipher suites from the DTLS handshake
> in Firefox soon.
>
> Ciphers:
> - TLS_DHE_RSA_WITH_AES_128_CBC_SHA
> - TLS_DHE_RSA_WITH_AES_256_CBC_SHA
> are the  two suites which we want to remove, because they are considered
> too weak.
>

Are these suites considered "too weak" across the board?  For historical
reasons Firefox for Android will handshake to Firefox Sync servers using
these suites:
https://searchfox.org/mozilla-central/rev/05d91d3e02a0780f44599371005591d7988e2809/mobile/android/services/src/main/java/org/mozilla/gecko/background/common/GlobalConstants.java#73.
Sounds like we should drop those suites there too -- can you confirm?

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

Intent to remove DHE ciphers from WebRTC DTLS handshake

[Nils Ohlmeier]

Summary:

We are looking at removing the DHE cipher suites from the DTLS handshake in 
Firefox soon.

Ciphers:
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA
are the  two suites which we want to remove, because they are considered too 
weak.

A Telemetry probe landed in Firefox 63 Nightly to monitor the usage of the 
different cipher suites:
https://telemetry.mozilla.org/new-pipeline/dist.html#measure=WEBRTC_DTLS_CIPHER 


Bug tracking the deactivation:
https://bugzilla.mozilla.org/show_bug.cgi?id=1227519 


Targeted release: Firefox 66

Best
  Nils Ohlmeier


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

Intent to remove: isRemote member in WebRTC getStats() results

[Jan-Ivar Bruaroey]

We're removing the isRemote member of the RTCRTPStreamStats [1] 
dictionary used to identify remote statistics returned from the 
peerConnection.getStats() method in WebRTC. [2]


The spec changed in 2017 to explicit types instead of this boolean. [3]

We just landed a deprecation warning in Nightly 63. [4]

We plan on removing isRemote in 65, as the warning says. [5]

We plan to warn in 63-64, but for technical reasons can't warn in 65.

The transition plan involves educating web developers to use the 
existing remoteId API, which remains unaffected by this transition.

Full details are in https://blog.mozilla.org/webrtc/getstats-isremote-65

Compatibility:
 - Chrome does not yet return remote statistics from the spec's latest
   pc.getStats() API, only local stats.
 - Safari implements this subset of getStats() similar to Firefox today.
 - Edge doesn't implement RTCPeerConnection, though there's a shim.

.: Jan-Ivar :.

[1] 
https://w3c.github.io/webrtc-stats/archives/20170330/webrtc-stats.html#dom-rtcrtpstreamstats-isremote

[2] http://w3c.github.io/webrtc-pc/#dom-rtcpeerconnection-getstats
[3] https://github.com/w3c/webrtc-stats/pull/191/files
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1393306
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1380555

PS: There’s also an isRemote member in RTCIceCandidateStats which 
remains unaffected.

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

Re: Intent to remove: the 'Memory usage of Subprocesses' table from about:performance

[Kris Maglione]

+1 for adding it back in the future.

Even if memory usage isn't as directly related to performance as 
CPU usage is, it has a *huge* effect on performance on memory 
constrained systems, if it causes them to have to swap.


Also, in my experience, the overlap between poorly-performing 
code and leaky code tends to be high, so it would really be nice 
to keep these numbers in one place.


On Thu, Jul 12, 2018 at 10:25:31AM -0700, Eric Rahm wrote:

Thanks Florian, considering it's roughly unmaintained right now, leaking,
and showing up in perf profiles it sounds reasonable to remove the memory
section. I've filed bug 1475301 [1] to allow us to measure USS off main
thread; we can deal with adding that back in the future if it makes sense.

-e

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1475301

On Thu, Jul 12, 2018 at 12:41 AM, Florian Quèze  wrote:


On Thu, Jul 12, 2018 at 1:18 AM, Eric Rahm  wrote:

> What performance issues are you seeing? RSS and USS should be relatively
> lightweight and the polling frequency isn't very high.

It seems ResidentUniqueDistinguishedAmount does blocking system calls,
resulting in blocking the main thread for several seconds in the worst
case. Here's a screenshot of a profile showing it:
https://i.imgur.com/DjRMQtY.png (unfortunately that profile is too big
and fails to upload with the 'share' feature).

There's also a memory leak in the implementation, after leaving
about:performance open for a couple hours, there was more than 300MB
of JS "Function" and "Call" objects (about:memory screenshot:
https://i.imgur.com/21YNDru.png ) and the devtools' Memory tool shows
that this is coming from the code queuing updates to that subprocess
memory table: https://i.imgur.com/04M71hg.png

Florian

--
Florian Quèze


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


--
Kris Maglione
Senior Firefox Add-ons Engineer
Mozilla Corporation

If we wish to count lines of code, we should not regard them as lines
produced but as lines spent.
--Edsger W. Dijkstra

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

Re: Intent to remove: the 'Memory usage of Subprocesses' table from about:performance

[Eric Rahm]

Thanks Florian, considering it's roughly unmaintained right now, leaking,
and showing up in perf profiles it sounds reasonable to remove the memory
section. I've filed bug 1475301 [1] to allow us to measure USS off main
thread; we can deal with adding that back in the future if it makes sense.

-e

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1475301

On Thu, Jul 12, 2018 at 12:41 AM, Florian Quèze  wrote:

> On Thu, Jul 12, 2018 at 1:18 AM, Eric Rahm  wrote:
>
> > What performance issues are you seeing? RSS and USS should be relatively
> > lightweight and the polling frequency isn't very high.
>
> It seems ResidentUniqueDistinguishedAmount does blocking system calls,
> resulting in blocking the main thread for several seconds in the worst
> case. Here's a screenshot of a profile showing it:
> https://i.imgur.com/DjRMQtY.png (unfortunately that profile is too big
> and fails to upload with the 'share' feature).
>
> There's also a memory leak in the implementation, after leaving
> about:performance open for a couple hours, there was more than 300MB
> of JS "Function" and "Call" objects (about:memory screenshot:
> https://i.imgur.com/21YNDru.png ) and the devtools' Memory tool shows
> that this is coming from the code queuing updates to that subprocess
> memory table: https://i.imgur.com/04M71hg.png
>
> Florian
>
> --
> Florian Quèze
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove: the 'Memory usage of Subprocesses' table from about:performance

[Florian Quèze]

On Thu, Jul 12, 2018 at 1:18 AM, Eric Rahm  wrote:

> What performance issues are you seeing? RSS and USS should be relatively
> lightweight and the polling frequency isn't very high.

It seems ResidentUniqueDistinguishedAmount does blocking system calls,
resulting in blocking the main thread for several seconds in the worst
case. Here's a screenshot of a profile showing it:
https://i.imgur.com/DjRMQtY.png (unfortunately that profile is too big
and fails to upload with the 'share' feature).

There's also a memory leak in the implementation, after leaving
about:performance open for a couple hours, there was more than 300MB
of JS "Function" and "Call" objects (about:memory screenshot:
https://i.imgur.com/21YNDru.png ) and the devtools' Memory tool shows
that this is coming from the code queuing updates to that subprocess
memory table: https://i.imgur.com/04M71hg.png

Florian

-- 
Florian Quèze
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove: the 'Memory usage of Subprocesses' table from about:performance

[Eric Rahm]

This was added in bug 1255843 [1]. I don't feel to strongly about keeping
it around, I believe mconley and mrbkap came up with the idea of adding it.
It's *much* more lightweight than about:memory and provides automatic
updates which is nice for monitoring without external tools.

What performance issues are you seeing? RSS and USS should be relatively
lightweight and the polling frequency isn't very high.

-e

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1255843

On Wed, Jul 11, 2018 at 11:12 AM, Florian Quèze  wrote:

> Context: we are currently redesigning about:performance to make it
> more useful for users.
>
> This section of the current about:performance page provides
> information that isn't actionable for users, and collecting this
> information causes performance issues, so I think it's time to remove
> it.
>
> I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1474990 for the
> removal.
>
> If someone uses this information and strongly thinks we should keep it
> (eg. by moving it to about:memory), now is the time to speak up.
>
> Thanks,
> Florian
>
> --
> Florian Quèze
> ___
> 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

Intent to remove: the 'Memory usage of Subprocesses' table from about:performance

[Florian Quèze]

Context: we are currently redesigning about:performance to make it
more useful for users.

This section of the current about:performance page provides
information that isn't actionable for users, and collecting this
information causes performance issues, so I think it's time to remove
it.

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1474990 for the removal.

If someone uses this information and strongly thinks we should keep it
(eg. by moving it to about:memory), now is the time to speak up.

Thanks,
Florian

-- 
Florian Quèze
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove most XPCOM special directories

[josh]

I intend to remove most of XPCOM's special directories in bug 1449686. They are 
unused in mozilla-central and only legacy addons would have used them.

Let me know in the bug if you have any concerns.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove Ambient Light and Proximity sensor APIs

[gaurav . genisys]

Originally posted this on the Firefox support forum 
(https://support.mozilla.org/en-US/questions/1222676), and was advised to post 
this here as well.

At our Russell Group UK university, we rely on the ambient light sensor heavily 
for research projects on visual perception, smart devices, etc, using mobile 
devices for quick and easy variable-location tests. We have been able to do 
this because Firefox on Android (as far as we know - Chrome doesn't do it, 
Safari iOS doesn't either, and neither does Opera, to the best of our 
knowledge) was the only browser to allow access to the light sensor, which is 
incredibly useful. Now we understand that you have privacy concerns and thus 
wish to disable the ambient light sensor API completely, but this will 
completely grind to a halt some of our methods while we redevelop alternatives. 
We distribute these to participants of psychophysical tests, who so far were 
simply able to install Firefox on Android and the web-loaded app would just 
work. We were under the impression that such APIs would become more widely 
available over time, including other platforms and operating systems, not the 
 other way around where you would end up planning to remove an incredibly 
useful feature. 

Please could you not disable the light sensor, surely there must be other ways, 
such as asking user permission for access just like you do with the cameras. 
Disabling the sensor API will be a gigantic step backwards, specially in the 
scientific community. 

(Adding on the above, previously there were indications of the browser 
community planning to extend sensor readings by introducing additional readable 
parameters such as camera exposure and white balance. This makes sense, and is 
a step forward. Similar steps forward would be to enhance sensor access, rather 
than the other way round.)

On Sunday, 17 December 2017 15:30:06 UTC, Jonathan Kingston  wrote:
> I am suggesting the removal of both Ambient Light and Proximity Sensor APIs
> via a preference so we can ensure there is no adverse impact to the web
> with a quick mitigation if needed.
> 
> If there are no issues with this, I plan to push the code early in the new
> year to account for the holiday downtime.
> 
> Previous attempts have been made to remove these APIs however this intent
> to remove *does not* include Device Orientation which will need further
> work to deprecate:
> https://groups.google.com/forum/#!topic/mozilla.dev.platform/45XApRxACaM
> 
> <https://groups.google.com/forum/#!topic/mozilla.dev.platform/45XApRxACaM>
> Previous thread:
> https://groups.google.com/forum/#!searchin/mozilla.dev.platform/ambient$20light|sort:relevance/mozilla.dev.platform/QI2-SO-1jxY/-CrSbuH-BAAJ
> 
> The rationale:
> 
> * These APIs have various privacy leaks, including violating the
> same-origin policy, without the user being informed or interaction.
> * These APIs do not match the current standards for sensor APIs
> * There's no interest to address these shortcomings. (Mostly in the sense
> of engineering resources and having other problems to tackle first.)
> * As these are event-driven APIs the compatibility impact should be minimal
> to none. The events simply won't fire.
> 
> Work will be implemented here: https://bugzilla.mozilla.org/
> show_bug.cgi?id=1359076
> Thanks
> Jonathan

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

Intent to Remove: privacy.firstparty.isolate.restrict_opener_access

[Tom Ritter]

privacy.firstparty.isolate.restrict_opener_access is a pref for First
Party Isolation that relaxes the protections of FPI by allowing access
to window.opener across first party domains.

It was created because in Tor Browser's initial FPI patch, they
allowed this by mistake, and we wanted to keep backwards
compatibility.

Except it was ever actually used; although it did solve at least one
FPI login breakage flow that relied on that opener access.

Since it's been used in practice by anyone we know of, and it
complicated some codepaths, we intend to remove it.

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

Re: Intent to remove Ambient Light and Proximity sensor APIs

[Jonathan Kingston]

As an update here the code has landed in 60 from
https://bugzilla.mozilla.org/show_bug.cgi?id=1359076

This adds:
- Deprecation warnings for DeviceOrientation and DeviceMotion sensors.
- Deprecation errors for AmbientLight and Proximity sensors.
- Preferences to control all 4 sensors independently:
  - "device.sensors.ambientLight.enabled" - devicelight event and
DeviceLightEvent constructor.
  - "device.sensors.proximity.enabled" - deviceproximity, userproximity
events and  DeviceProximityEvent and UserProximityEvent constructors.
 - "device.sensors.motion.enabled" - devicemotion event and
DeviceMotionEvent constructor.
 - "device.sensors.orientation.enabled" - deviceorientation event and
DeviceOrientationEvent constructor.
- In Nightly and Early beta releases the proximity and light sensors are
disabled by default.

My plan is to deprecate light and proximity sensors in Stable Firefox in
version 62 if no issues arise.

Please reach out if you have any questions or concerns.

Thanks
Jonathan

On Tue, Dec 19, 2017 at 7:01 AM, Anne van Kesteren  wrote:

> On Mon, Dec 18, 2017 at 7:36 PM, Gervase Markham  wrote:
> > appear.in, which supports both audio and video calling via WebRTC, works
> > in Firefox for Android, although performance is not awesome on my Z3C
> > Compact.
> >
> > It does not blank the screen when you place the device to your ear.
>
> There might be more secure ways we can address this use case. E.g.,
> having a dedicated signal just for that, perhaps only given if the
> user already granted access to the microphone and such.
>
> (And if something does require the full power of the proximity API, we
> should first work out how to expose it securely. I'm sure folks can
> come up with use cases for running arbitrary code as root too, but
> that doesn't mean we can offer it.)
>
>
> --
> 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

Intent to remove: Throttling of timeouts from tracking scripts

[Andreas Farre]

TL;DR We have decided to not (re-)turn on throttling of timeouts from
tracking scripts, and also remove throttling of timeouts from tracking
scripts altogether.

This feature was, in the beginning, only intended for tabs in the
background, but experiments were also conducted to see the effect of
throttling for foreground tabs. These experiments showed that users
became inclined to abandon pages to a higher degree than before, and
after letting the feature be turned on for Nightly for a period of
time, issues that would actually block user interaction were noticed.

Actually being able to resolve these issues for foreground tabs is
difficult, especially in light of how we schedule timeout events after
the rewrite that allowed us to only use a single timer per
window[1,2]. Even being able to solve the issues related to throttling
of background tracking timeouts would introduce unwarranted
complexity, and by instead removing throttling of timeouts from
tracking scripts we would reduce complexity of timeout handling.

The silver lining is that the importance of throttling of timeouts
from tracking scripts has been reduced since we started throttling all
timeouts from background windows using the background execution
budget, to the degree that we are confident that throttling of
tracking timeouts is not as necessary anymore.

Cheers,
Andreas

[1] Bug 1363829: https://bugzilla.mozilla.org/show_bug.cgi?id=1363829
[2] Bug 1371787: https://bugzilla.mozilla.org/show_bug.cgi?id=1371787
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove: nsIDOMWindowUtils.sendKeyEvent() and nsIFrameLoader.sendCrossProcessKeyEvent()

[Masayuki Nakano]

Hi,

I'd like to remove legacy API to dispatch keyboard events.

One is nsIDOMWindowUtils.sendKeyEvent(), this has already replaced 
completely with nsITextInputProcessor [*1] since 2015 [*2].  It's really 
easy to rewrite legacy API users with new API because our EventUtils.js 
for mochitest has a good wrapper for using new API [*3].


The other is nsIFrameLoader.sendCrossProcessKeyEvent().  This was 
implemented for old Fennec [*4] and looks like that nobody uses this API 
now.  This shares same implementation with 
nsIDOMWindowUtils.sendKeyEvent() but dispatches keyboard events only in 
the remote process associated with the frame loader. Unfortunately, we 
don't have alternative API for this.  However, if the remote process has 
focus, keyboard events synthesized with nsITextInputProcessor are sent 
to the remote process.  So, I guess that we don't need this API anymore.


I'm working on this at bug 1134542:
https://bugzilla.mozilla.org/show_bug.cgi?id=1134542

Thunderbird still uses nsIDOMWindowUtils.sendKeyEvent().  Therefore, 
I'll wait to land the removing patch until those bugs [*5][*6] are 
fixed.  However, if they won't be fixed by the next weekend, I'll drop 
these legacy API soon anyway.


*1 
https://searchfox.org/mozilla-central/source/dom/interfaces/base/nsITextInputProcessor.idl

*2 https://bugzilla.mozilla.org/show_bug.cgi?id=917322
*3 
https://searchfox.org/mozilla-central/rev/97cb0aa64ae51adcabff76fb3b5eb18368f5f8ab/testing/mochitest/tests/SimpleTest/EventUtils.js#835-905

*4 https://bugzilla.mozilla.org/show_bug.cgi?id=553149
*5 https://bugzilla.mozilla.org/show_bug.cgi?id=1433648
*6 https://bugzilla.mozilla.org/show_bug.cgi?id=1434317

--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove: some methods of nsIEditActionListener or the interface itself

[Masayuki Nakano]

I'd like to remove unnecessary methods of nsIEditActionListener or 
nsIEditActionListener itself completely.


This is not buildinclass.  So, this can be implemented by XUL addons. 
Currently, this is used only by ThunderHTMLedit (only Did*()). 
Additionally, 3 internal classes of Gecko implements this interface.


Supporting this interface is expensive from a point of view of Quantum 
Flow.  When editor changes DOM tree, a set of methods of this interface 
is always called every time.  When running for loop to call a method of 
the interface, we need to copy edit action listeners array with array of 
strong pointer. Then, we need to call them with nsIDOM* interfaces. 
I.e., a lot of unnecessary QIs are required.  Additionally, each 
implementation will QI back to nsINode or something. Finally, all of 
them are virtual call but our internal classes implements less than half 
of the methods.


So, my current idea is, keep supporting ThunderHTMLedit as far as 
possible.  Even with that, we can make all our internal classes are 
notified directly instead of via the interface.  This is not so 
beautiful but we can get rid of virtual call cost, unnecessary method 
calls and unnecessary QIs.  Then, only XUL addon for Thunderbird may use 
the interface. However, in most environment, that's not used. So, our 
editor can check before doing for loop if there is edit action listeners.


Feel free to suggest something in this bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1429676

And currently, I'm working on making HTMLEditRules not derived from 
nsIEditActionListener:

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

And nsIEditActionListener::Will*() will be removed because of no users:
https://bugzilla.mozilla.org/show_bug.cgi?id=1430319

--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove: do_check_*, do_print, do_execute_soon, do_register_cleanup

[Michael de Boer]

<3 Thanks so much for taking this, Florian!

> On 19 Dec 2017, at 20:14, Florian Quèze  wrote:
> 
> In order to reduce the confusion for people writing tests using both
> xpcshell and mochitests, I'm currently working on removing the old
> do_* helpers that have an obvious nicer equivalent.
> 
> This is happening in https://bugzilla.mozilla.org/show_bug.cgi?id=1421992
> 
> I'm removing the following do_check_* functions and replacing them
> with equivalent Assert.* calls in the existing xpcshell tests:
> do_check_true, do_check_false, do_check_eq, do_check_neq,
> do_check_null, do_check_matches.
> 
> Additionally, I'm renaming do_print to info, do_register_cleanup to
> registerCleanupFunction and do_execute_soon to executeSoon.
> 
> The patches are large (about 2000 files and 25000 lines touched) so
> I'm giving a heads up that I'm expecting to land this in a few days. I
> anybody has xpcshell tests that are ready to land, I would suggest
> landing them sooner than later.
> 
> Thanks,
> Florian
> 
> -- 
> Florian Quèze
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev

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

Intent to remove: do_check_*, do_print, do_execute_soon, do_register_cleanup

[Florian Quèze]

In order to reduce the confusion for people writing tests using both
xpcshell and mochitests, I'm currently working on removing the old
do_* helpers that have an obvious nicer equivalent.

This is happening in https://bugzilla.mozilla.org/show_bug.cgi?id=1421992

I'm removing the following do_check_* functions and replacing them
with equivalent Assert.* calls in the existing xpcshell tests:
do_check_true, do_check_false, do_check_eq, do_check_neq,
do_check_null, do_check_matches.

Additionally, I'm renaming do_print to info, do_register_cleanup to
registerCleanupFunction and do_execute_soon to executeSoon.

The patches are large (about 2000 files and 25000 lines touched) so
I'm giving a heads up that I'm expecting to land this in a few days. I
anybody has xpcshell tests that are ready to land, I would suggest
landing them sooner than later.

Thanks,
Florian

-- 
Florian Quèze
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove Ambient Light and Proximity sensor APIs

[Anne van Kesteren]

On Mon, Dec 18, 2017 at 7:36 PM, Gervase Markham  wrote:
> appear.in, which supports both audio and video calling via WebRTC, works
> in Firefox for Android, although performance is not awesome on my Z3C
> Compact.
>
> It does not blank the screen when you place the device to your ear.

There might be more secure ways we can address this use case. E.g.,
having a dedicated signal just for that, perhaps only given if the
user already granted access to the microphone and such.

(And if something does require the full power of the proximity API, we
should first work out how to expose it securely. I'm sure folks can
come up with use cases for running arbitrary code as root too, but
that doesn't mean we can offer it.)


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

Re: Intent to remove Ambient Light and Proximity sensor APIs

[Peter Saint-Andre]

On 12/18/17 11:36 AM, Gervase Markham wrote:
> On 18/12/17 18:25, Tantek Çelik wrote:
>> Do you know of a specific (URL?) mobile-device-capable (which
>> device(s)?) WebRTC-based audio-calling webapp that works today? I
>> would be very interested in testing it out.
> 
> appear.in, which supports both audio and video calling via WebRTC, works
> in Firefox for Android, although performance is not awesome on my Z3C
> Compact.

My old team at talky.io offers both web and mobile WebRTC, too:

https://talky.io/

(For mobile, it's iOS only, not Android.)

Peter




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 remove Ambient Light and Proximity sensor APIs

[Gervase Markham]

On 18/12/17 18:25, Tantek Çelik wrote:
> Do you know of a specific (URL?) mobile-device-capable (which
> device(s)?) WebRTC-based audio-calling webapp that works today? I
> would be very interested in testing it out.

appear.in, which supports both audio and video calling via WebRTC, works
in Firefox for Android, although performance is not awesome on my Z3C
Compact.

It does not blank the screen when you place the device to your ear.

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

Re: Intent to remove Ambient Light and Proximity sensor APIs

[Tantek Çelik]

On Mon, Dec 18, 2017 at 5:52 AM, Gervase Markham  wrote:
> On 17/12/17 15:29, Jonathan Kingston wrote:
>> I am suggesting the removal of both Ambient Light and Proximity Sensor APIs
>> via a preference so we can ensure there is no adverse impact to the web
>> with a quick mitigation if needed.

I think this removal is prudent and timely. It is consistent with our
default principles on privacy etc. and good to do it quickly while we
think the potential impact is low at worst.


> Is it fair to say that after removal of the Proximity Sensor API, no
> e.g. WebRTC-based audio-calling webapp

Do you know of a specific (URL?) mobile-device-capable (which
device(s)?) WebRTC-based audio-calling webapp that works today? I
would be very interested in testing it out.


> will be able to blank the screen
> when the user holds the device to their ear?
>
> That seems sad.

It's likely worth capturing your use-case in the Sensors Use-cases doc:
* https://w3c.github.io/sensors/usecases

That specific use-case doesn't seem to be in there, so go ahead and
file it here and feel free to cc: @tantek
* https://github.com/w3c/sensors/issues

Thanks,

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

Re: Intent to remove Ambient Light and Proximity sensor APIs

[Jonathan Kingston]

> Is it fair to say that after removal of the Proximity Sensor API, no
e.g. WebRTC-based audio-calling webapp will be able to blank the screen
when the user holds the device to their ear?

Yes, however this would be the case for all other browsers too.

Given that we are the only browser to implement the event based interface
 for
this I don't think we should block on the loss of this feature.

The next generation of these APIs are going through TAG review where many
of the concerns here are still being addressed:
https://github.com/w3ctag/design-reviews/issues/207


We may be able to reimplement this functionality with the new APIs with far
less granular access and prompted if more granular is needed. There has
also been no real intent from browser makers to ship them despite their
improvements.

Thanks

On Mon, Dec 18, 2017 at 7:52 AM, Gervase Markham  wrote:

> On 17/12/17 15:29, Jonathan Kingston wrote:
> > I am suggesting the removal of both Ambient Light and Proximity Sensor
> APIs
> > via a preference so we can ensure there is no adverse impact to the web
> > with a quick mitigation if needed.
>
> Is it fair to say that after removal of the Proximity Sensor API, no
> e.g. WebRTC-based audio-calling webapp will be able to blank the screen
> when the user holds the device to their ear?
>
> That seems sad.
>
> Gerv
>
> ___
> 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: Intent to remove Ambient Light and Proximity sensor APIs

[Gervase Markham]

On 17/12/17 15:29, Jonathan Kingston wrote:
> I am suggesting the removal of both Ambient Light and Proximity Sensor APIs
> via a preference so we can ensure there is no adverse impact to the web
> with a quick mitigation if needed.

Is it fair to say that after removal of the Proximity Sensor API, no
e.g. WebRTC-based audio-calling webapp will be able to blank the screen
when the user holds the device to their ear?

That seems sad.

Gerv

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

Intent to remove Ambient Light and Proximity sensor APIs

[Jonathan Kingston]

I am suggesting the removal of both Ambient Light and Proximity Sensor APIs
via a preference so we can ensure there is no adverse impact to the web
with a quick mitigation if needed.

If there are no issues with this, I plan to push the code early in the new
year to account for the holiday downtime.

Previous attempts have been made to remove these APIs however this intent
to remove *does not* include Device Orientation which will need further
work to deprecate:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/45XApRxACaM

<https://groups.google.com/forum/#!topic/mozilla.dev.platform/45XApRxACaM>
Previous thread:
https://groups.google.com/forum/#!searchin/mozilla.dev.platform/ambient$20light|sort:relevance/mozilla.dev.platform/QI2-SO-1jxY/-CrSbuH-BAAJ

The rationale:

* These APIs have various privacy leaks, including violating the
same-origin policy, without the user being informed or interaction.
* These APIs do not match the current standards for sensor APIs
* There's no interest to address these shortcomings. (Mostly in the sense
of engineering resources and having other problems to tackle first.)
* As these are event-driven APIs the compatibility impact should be minimal
to none. The events simply won't fire.

Work will be implemented here: https://bugzilla.mozilla.org/
show_bug.cgi?id=1359076
Thanks
Jonathan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove pcast and feed protocols

[Jonathan Kingston]

We have a two feed handling protocols that were never standardised and
aren't implemented in other browsers. These protocols have been subject to
various security bugs and also contribute to some technical debt.

The protocols are used to route URLs in Firefox to the feed reader. The
feed reader won't be impacted by this change or other registered feed
handlers.

The work was implemented here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1420622

I intend to fully remove this code and let it ride the trains.

As the telemetry suggests the pcast protocol is almost never used so is
safe to be removed for all users. The feed protocol however is used by the
"Subscribe to this page" functionality and was changed as part of this
patch to work without the protocol.

https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2017-11-28&keys=__none__!__none__!__none__&max_channel_version=release%252F57&measure=FEED_PROTOCOL_USAGE&min_channel_version=null&processType=*&product=Firefox&sanitize=1&sort_keys=submissions&start_date=2017-11-12&table=0&trim=1&use_submission_date=0


Shout out to :bz who fixed a test that was depending on the feed protocol.

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

Re: Intent to Remove: Insecure use of WebCrypto

[Tim Taubert]

On Fri, Jul 28, 2017 at 10:15 PM, Jonathan Kingston  wrote:
> Hey Tim,
>
> The only questions I have about this our are difference in implementation
> over Chrome the more we increase the use of [SecureContext] the greater risk
> we put on compat bugs.

Good news, the implementation difference was just removed by Kate in
bug 1410364.

Let's move forward with the proposal for Firefox 59.

> Our implementation differs in that we actually abide to the specification on
> window.opener insecure contexts making the openee insecure. This may for
> example cause breakage on payment sites that want to use crypto.
>
> Perhaps we should shift to using SecureContextIfOpenerIgnored instead; at
> least for the time being?
>
> The difference is somewhat a technicality anyway as the inverse isn't true a
> SecureContext that opens an !SecureContext is not then treated as insecure
> despite the risk being pretty much the same.
>
> On Thu, Jul 20, 2017 at 3:47 PM, Tim Taubert  wrote:
>>
>> Summary: The WebCrypto spec [1] states that window.crypto.subtle
>> should only be usable from a secure origin (i.e. on a domain being
>> served over HTTPS). Currently Gecko's implementation works on insecure
>> origins (i.e. sites served over unencrypted HTTP). To bring our
>> implementation in line with the spec, we're going to remove access to
>> crypto.subtle on non-secure origins.
>>
>> Sites using the WebCrypto API's crypto.subtle interface on a
>> non-secure origin should switch to HTTPS as soon as possible.
>>
>> Chrome too is planning to remove access to crypto.subtle on non-secure
>> origins [2]. Edge seems positive about implementing those restrictions
>> as well [3].
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1333140
>>
>> Standard: https://w3c.github.io/webcrypto/Overview.html
>>
>> Platform coverage: This will affect Windows, MacOS, Linux, and Android.
>>
>> Estimated target date: This could land as early as Firefox 56, but
>> should in Firefox 57. We probably want to coordinate with Chrome, they
>> seem as ready as we are.
>>
>> Our telemetry [4] indicates that about 9% of crypto.subtle use is
>> still on insecure origins. This was at around 1-2% - that's not the
>> percentage of all users, but only of those that visit pages that use
>> crypto.subtle - but became inflated around two weeks after we started
>> measuring. The blink-dev thread [2] has a good summary and indicates
>> that this is caused by Twitter launching AMP support serving from
>> origins which may be insecure. AMP has a fallback that is lazy-loaded
>> in case crypto.subtle isn't available, so no one's Twitter would break
>> when we ship this.
>>
>>
>> [1] https://w3c.github.io/webcrypto/Overview.html#crypto-interface
>> [2]
>> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ZD3NWqkk-bo/discussion
>> [3] https://github.com/w3c/webcrypto/issues/28#issuecomment-243243989
>> [4] https://mzl.la/2ttx8aV
>> ___
>> 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

Intent to remove: WebVR on insecure contexts

[Kearwood Kip Gilbert]

Summary: 
WebVR on insecure contexts (i.e. web sites served over non-HTTPS) is deprecated 
and will soon stop working in Firefox. 

Sites wanting to use WebVR should switch to HTTPS if they have not already. 

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

Link to standard: 
https://w3c.github.io/webvr/spec/1.1/

WebVR is a powerful feature that exposes sensor inputs that can capture 
biometric data (ie. distance of eyes to ground when user is standing).  
Immersive WebVR sites must be inherently trusted with this information.  The 
risks are greater if the transport is not encrypted.

Timeframe: 
We will immediately remove WebVR on insecure origins in FF59’s Nightly.  This 
should give developers some time to test their sites in Nightly until it rides 
the trains to FF59 in release.  WebVR is enabled by default in release FF57 and 
can be used to access insecure sites until they are updated.


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

Re: Intent to remove client.mk

[Gregory Szorc]

On Fri, Oct 27, 2017 at 4:16 PM, Gregory Szorc  wrote:

> client.mk has existed since 1998 (https://hg.mozilla.org/
> experimental/mozilla-central-cvs/rev/0a5e1fa423bd). Before `mach`,
> client.mk was the recommended way to build Firefox and perform other
> build tasks. client.mk has rarely changed in recent years because the
> build system maintainers have been working around it and because not much
> has changed around how the very early parts of "invoke the build system"
> work.
>
> The build system maintainers are making a significant push towards
> supporting building Firefox without GNU make in this and future quarters.
>
> Since client.mk is a make file and we want to not require make to build
> Firefox, client.mk is incompatible with our vision for the future of the
> Firefox build system. Furthermore, client.mk represents an ancient piece
> of build system infrastructure and its convoluted content creates
> consternation and inhibits forward progress. For these reasons, I'm
> announcing the intent to remove client.mk.
>
> If you have tools, infrastructure, workflows, etc that use client.mk - or
> any direct use of `make` for that matter - please transition them to `mach`
> commands and/or check with a build peer regarding your use case. You can
> file bugs regarding client.mk dependencies against bug 1412398.
>
> Thank you for your understanding.
>

Heads up: the patches to ween off client.mk have started landing. As I'm
touching the code, it is obvious how brittle things are and that there is a
web of under-documented dependencies everywhere I look.

If you see the build system behaving in strange ways - e.g. running
configure twice, complaining about clobbers when it shouldn't, running
moz.build sandbox evaluation when it shouldn't, etc, please don't hesitate
to make noise in #build or file a bug blocking 1412398. Even if we break a
workflow you relied on and there isn't a good equivalent, we'd like to
know. Disrupting people unnecessarily is definitely not a goal of this
refactor.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove: elements matching hack

[Emilio Cobos Álvarez]

Hi,

In bug 1374247, I intend to remove the XBL compatibility hack introduced
in bug 653881 [1] for which  elements may be "transparent"
in selector-matching.

That means that a selector like .foo > .bar, would match a tree like:

  

  

  

The motivation is the following: This was not implemented in stylo, but
the Firefox UI depends on it, so we need to do something if we want
stylo on chrome documents.

I fear that it is the kind of thing that if we ever implement, it will
stay there forever. Also, one-offs like these tend to be buggy and
overlooked when implementing optimizations.

Finally, this hack doesn't apply to Shadow DOM, so removing it would
likely help with the efforts of transitioning away from XBL.

Since just removing it would have chances to silently break parts of the
Firefox UI, I'm landing a diagnostic assertion to verify that we don't
use it. I've been browsing for a couple days now with it without issues,
but if you get a crash pointing you to that bug, please file and I'll
take care of it :)

Thanks!

 -- Emilio

[1]:
https://hg.mozilla.org/mozilla-central/rev/1b8207252e9ca1194eccd3adc14b961785fb4e8e
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove client.mk

[Nicholas Nethercote]

This is excellent news.

Relatedly, I want to particularly say that I think moz.build files are
great. The syntax and semantics are very clear. They're easy to modify.
They handle both simple cases and complex cases well. They pretty much
never get in the way, which is exactly what a developer wants from a build
system. The contrast with Makefiles is... significant.

Nick

On Sat, Oct 28, 2017 at 10:16 AM, Gregory Szorc  wrote:

> client.mk has existed since 1998 (https://hg.mozilla.org/
> experimental/mozilla-central-cvs/rev/0a5e1fa423bd). Before `mach`,
> client.mk was the recommended way to build Firefox and perform other
> build tasks. client.mk has rarely changed in recent years because the
> build system maintainers have been working around it and because not much
> has changed around how the very early parts of "invoke the build system"
> work.
>
> The build system maintainers are making a significant push towards
> supporting building Firefox without GNU make in this and future quarters.
>
> Since client.mk is a make file and we want to not require make to build
> Firefox, client.mk is incompatible with our vision for the future of the
> Firefox build system. Furthermore, client.mk represents an ancient piece
> of build system infrastructure and its convoluted content creates
> consternation and inhibits forward progress. For these reasons, I'm
> announcing the intent to remove client.mk.
>
> If you have tools, infrastructure, workflows, etc that use client.mk - or
> any direct use of `make` for that matter - please transition them to `mach`
> commands and/or check with a build peer regarding your use case. You can
> file bugs regarding client.mk dependencies against bug 1412398.
>
> Thank you for your understanding.
>
> ___
> dev-builds mailing list
> dev-bui...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-builds
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove client.mk

[Kris Maglione]

On Fri, Oct 27, 2017 at 04:16:01PM -0700, Gregory Szorc wrote:

client.mk has existed since 1998 (
https://hg.mozilla.org/experimental/mozilla-central-cvs/rev/0a5e1fa423bd).
Before `mach`, client.mk was the recommended way to build Firefox and
perform other build tasks. client.mk has rarely changed in recent years
because the build system maintainers have been working around it and
because not much has changed around how the very early parts of "invoke the
build system" work.

The build system maintainers are making a significant push towards
supporting building Firefox without GNU make in this and future quarters.


I think I speak for all of us when I say: \o/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove client.mk

[Gregory Szorc]

client.mk has existed since 1998 (
https://hg.mozilla.org/experimental/mozilla-central-cvs/rev/0a5e1fa423bd).
Before `mach`, client.mk was the recommended way to build Firefox and
perform other build tasks. client.mk has rarely changed in recent years
because the build system maintainers have been working around it and
because not much has changed around how the very early parts of "invoke the
build system" work.

The build system maintainers are making a significant push towards
supporting building Firefox without GNU make in this and future quarters.

Since client.mk is a make file and we want to not require make to build
Firefox, client.mk is incompatible with our vision for the future of the
Firefox build system. Furthermore, client.mk represents an ancient piece of
build system infrastructure and its convoluted content creates
consternation and inhibits forward progress. For these reasons, I'm
announcing the intent to remove client.mk.

If you have tools, infrastructure, workflows, etc that use client.mk - or
any direct use of `make` for that matter - please transition them to `mach`
commands and/or check with a build peer regarding your use case. You can
file bugs regarding client.mk dependencies against bug 1412398.

Thank you for your understanding.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Remove: Insecure use of WebCrypto

[Jonathan Kingston]

Hey Tim,

The only questions I have about this our are difference in implementation
over Chrome the more we increase the use of [SecureContext] the greater
risk we put on compat bugs.

Our implementation differs in that we actually abide to the specification
on window.opener insecure contexts making the openee insecure. This may for
example cause breakage on payment sites that want to use crypto.

Perhaps we should shift to using SecureContextIfOpenerIgnored instead; at
least for the time being?

The difference is somewhat a technicality anyway as the inverse isn't true
a SecureContext that opens an !SecureContext is not then treated as
insecure despite the risk being pretty much the same.

On Thu, Jul 20, 2017 at 3:47 PM, Tim Taubert  wrote:

> Summary: The WebCrypto spec [1] states that window.crypto.subtle
> should only be usable from a secure origin (i.e. on a domain being
> served over HTTPS). Currently Gecko's implementation works on insecure
> origins (i.e. sites served over unencrypted HTTP). To bring our
> implementation in line with the spec, we're going to remove access to
> crypto.subtle on non-secure origins.
>
> Sites using the WebCrypto API's crypto.subtle interface on a
> non-secure origin should switch to HTTPS as soon as possible.
>
> Chrome too is planning to remove access to crypto.subtle on non-secure
> origins [2]. Edge seems positive about implementing those restrictions
> as well [3].
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1333140
>
> Standard: https://w3c.github.io/webcrypto/Overview.html
>
> Platform coverage: This will affect Windows, MacOS, Linux, and Android.
>
> Estimated target date: This could land as early as Firefox 56, but
> should in Firefox 57. We probably want to coordinate with Chrome, they
> seem as ready as we are.
>
> Our telemetry [4] indicates that about 9% of crypto.subtle use is
> still on insecure origins. This was at around 1-2% - that's not the
> percentage of all users, but only of those that visit pages that use
> crypto.subtle - but became inflated around two weeks after we started
> measuring. The blink-dev thread [2] has a good summary and indicates
> that this is caused by Twitter launching AMP support serving from
> origins which may be insecure. AMP has a fallback that is lazy-loaded
> in case crypto.subtle isn't available, so no one's Twitter would break
> when we ship this.
>
>
> [1] https://w3c.github.io/webcrypto/Overview.html#crypto-interface
> [2] https://groups.google.com/a/chromium.org/forum/#!topic/
> blink-dev/ZD3NWqkk-bo/discussion
> [3] https://github.com/w3c/webcrypto/issues/28#issuecomment-243243989
> [4] https://mzl.la/2ttx8aV
> ___
> 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

Intent to remove CSSStyleDeclaration.getAuthoredPropertyValue()

[Bradley Werth]

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

This chrome-only API was intended to assist developer tools in
reporting the authored values for properties that are normalized after
parsing. We are removing it for four reasons:

1) Only color properties were specially handled by this API.
2) Firefox devtools doesn't call this API, and the only known add-on
that does is Firebug, which has a fallback.
3) There are APIs to do CSS lexing in JS, which provides another way
to retrieve authored values.
4) If this API is retained, the transition to Quantum Style aka
"Stylo" would require significant code changes in the Quantum Style
code and would introduce some performance inefficiency.

If you need to return authored values, you can use a mthod similar to
the one used by the Firefox devtools. There are two chrome-only APIs
in inIDOMUtils.idl:

1) getCSSLexer returns a CSS lexer that will lex some text. The lexer
is documented here:
https://dxr.mozilla.org/mozilla-central/source/dom/webidl/CSSLexer.webidl
2) getRelativeRuleLine returns the line number of a CSS rule, relative
to the 

Re: Intent to remove: EME support on insecure contexts

[Enrico Weigelt, metux IT consult]

On 04.08.2017 04:04, Chris Pearce wrote:

Summary:
Encrypted Media Extensions on insecure contexts (i.e. web sites served over 
non-HTTPS) is deprecated and will soon stop working in Firefox.

Sites wanting to use EME should switch to HTTPS if they have not already.


Let me add another request here: allow builds completely w/o EME.

While trying to build moz/tbird w/o the codecs, I've observed that
some EME stuff (depending eg. on FMP4) does get build, even w/
--disable-eme.

I've got a patch for fixing the codec build problem here. Couldn't
submit yet - still having problems w/ git+hg ...

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

Re: Intent to remove:

[Henri Sivonen]

On Thu, May 5, 2016 at 10:55 PM, Ehsan Akhgari  wrote:
> At the very least we need to make sure that a surprisingly large
> number of sessions don't run into isindex, right?

Out of 36.15 million release-channel Firefox 54 sessions examined,
there were 8 (just 8, no multiplier) with at least one isindex form
submission.

The removal corresponding to this intent is in 56.

-- 
Henri Sivonen
hsivo...@hsivonen.fi
https://hsivonen.fi/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove: EME support on insecure contexts

[Chris Pearce]

Summary:
Encrypted Media Extensions on insecure contexts (i.e. web sites served over 
non-HTTPS) is deprecated and will soon stop working in Firefox.

Sites wanting to use EME should switch to HTTPS if they have not already.

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

Link to standard:
https://www.w3.org/TR/encrypted-media/#privacy-secureorigin

The EME spec requires that EME only be usable from a secure context, e.g., on 
origins served over HTTPS, and not those served over HTTP.

EME is a powerful feature which makes use of sandboxed closed source CDMs which 
send messages (relayed via the JavaScript video player) to third party servers, 
and the risks are greater if the transport is not encrypted.

Chrome has already removed support for EME on insecure origins in M58:
https://www.chromestatus.com/feature/5724389932793856

Firefox is already logging a deprecation warning to the WebConsole when EME is 
used on an insecure origin (bug 1361000), and we have telemetry to track 
whether EME requests are made in a secure or insecure context:
https://mzl.la/2hsC7Dq

Timeframe:
I am hoping we can remove EME on insecure origins in Q4 2017 or Q1 2018.

Our telemetry shows about 8% of sites using EME are still in insecure contexts, 
and I'd prefer to see that number lower before we disable EME in insecure 
contexts. Given that Chrome have already removed their support for EME in 
insecure contexts, I expect this telemetry to show improvement quickly.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: security problems [WAS: Intent to remove: sensor APIs]

[Enrico Weigelt, metux IT consult]

On 02.08.2017 15:53, Blair MacIntyre wrote:


FWIW, I wouldn’t mind being involved in a discussion about this,

> if people want to seriously consider putting it behind a
> "user-permission prompt"  (similar to geolocation) or

"user-action requirement”


I'd even go further and move it to an extra package, that may not even
be deployed in the first place.

One major reason is that browsers are often used on system where we
can't always trust the user to always take the right decisions.
Scenarios could be my 90rs old grandpa (who's already annoyed by all
that web-2.0 stuff) or business machines where companies wanna protect
themselves from espionage etc (similar to banning smartphones w/
cameras from their facilities, etc.

The more of those things are added to the browser, the harder it gets
to manage this. Sooner or later we'll get to a point where FF is just
banned (or forked). I doubt that this is your intention.


There has been discussion of this issue in the WebVR community, for

> example, noting that in WebVR, you don’t get any device reports
> without a user action requesting the “VR”.

By device reports you mean calling home ?


On top of that, there is very likely a need to not just “ask once at

> the start” but toggle access to sensitive info on/off as the user uses
> a web app

And there should be a manual control (eg. via keys or mouse gestures),
w/o the web app noticing that it's manual.

There's even more: the user also needs control over where the data
is actually coming from (eg. which device exactly). Otherwise that
fancy feature will only be usable in some specific usecases.


I think as we move toward exposing AR technology (like Tango, ARKit,

> Windows Holographic) in web user-agents, we may need to rethink how
> we obtain and manage the data user’s give to pages.

Yes, that's a very vital issue. And I'd also suggest which parts of that
are implemented *inside* the browser at all (vs external applications)

> I believe that respecting user privacy and supporting their ability
> to control information flow may actually be the thing that makes the

web a preferred platform for AR/VR,


Perhaps we should also rethink what "the web" *actually* means here.
Does everything that the web might offer need to run inside the
browser ? Does that mean the browser has to become an kind of own
operating system ?


since the various platforms are giving all data to apps automatically,

> which create a “take it or leave it” attitude regarding privacy and
> sensor information.

An important point here is that it's easy to leave it. If you don't want
to run any proprietary code, just don't do it. Period. And it doesn't
seem to be easy making great number of people dependent on it.

OTOH, if these things are already integrated in the browser, it isn't
so easy anymore. It quickly becomes an all or nothing decision.


Anyway, if folks want to discuss this, let me know.  We should probably move 
off this thread?


Agreed, for the WebVR stuff (maybe should be even discussed on a
separate list). In general, I'd just like to highlight that
security is a vital aspect.


--mtx

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

Re: Intent to remove: sensor APIs

[Enrico Weigelt, metux IT consult]

On 02.08.2017 14:39, Blair MacIntyre wrote:


It’s used for panoramic image viewing (orient the pano with the camera
movement), and google street view uses it for similar motion control.


Okay, why not adding a generic interface for controlling the virtual
view direction ? So, the user/operator could decide how to control it
(keys, mouse gestures, external 3d positioning devices, etc).

Anyways, I wonder how the current approach would work at all with
non-portable devices. And the idea of having to physically turn around
just to see different perspectives seems really weird to me.


Regarding security:  perhaps it is, I have seen discussions of this
sort.


Allowing webites to track individual movements, IMHO qualifies more
than just an "perhaps". Do you feel well with the idea of being tracked
with every single footstep ?

> But, it would seem that ship sailed when the W3C approved it, and

now it’s common and assumed and relied upon. Removing it in Firefox
would render Firefox incompatible with a growing use of the web,


Okay, we now know that was a wrong assumption - but even it was
really was approved: does that mean we have to support anything that
some beaurocrats find a good idea ?

In the past, there have been lots of standards that peopel stopped
supporting / complying to, because they turned out to be a bad idea.
I still remember when leaded fuel was standard - meanwhile it's even
prohibited (except for a few old timers). I also remember when IPX
or DecNet have been de-facto standards. Flash has been a de-facto
standard, it was a security nightmare, and it took a long time to get
rid of it.

What would you do if W3C decided that web applications shall be allowed
to execute arbitrary binaries with user's full privileges ?
(actually, I wouldn't be surprised if Goverments making such laws ...)


especially mobile (including Windows tablets).


What would be the actual impact ? A few websites that rely on that
won't work completely anymore. Actually, haven't seen single one yet.

Is it okay, to sacrify the security of all users just for the joy of
that small minority ?


This might be a discussion the security team wants to have, I guess:

> is the Firefox team worried enough about the threats opened by this
> API to justify breaking a large class of applications, and making

Firefoxunusable for AR/VR moving forward.


Suggestive question. And implies that this "large class of applications"
actually exists already.

I'd prefer asking: is it okay to sacrifice security for some niche
features ?

OTOH, I'd also question whether that AR/VR really belongs into a
browser, and what's the costs and risks of that. (some countries
already started legislation against AR, most notably Pokemon Go, for
good reasons ...).

Certainly, AR/VR has it's use in some industrial applications or
entertainment machines, but I doubt Browsers and HTML are particular
well suited for those jobs.



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

Re: security problems [WAS: Intent to remove: sensor APIs]

[Blair MacIntyre]

> At least these things should be purely optional and providing an
> *easy* way to filter that data. (same for the geolocation stuff).


FWIW, I wouldn’t mind being involved in a discussion about this, if people want 
to seriously consider putting it behind a "user-permission prompt"  (similar to 
geolocation) or "user-action requirement” (similar to webvr and some aspects of 
mobile video playing) of some sort.  

There has been discussion of this issue in the WebVR community, for example, 
noting that in WebVR, you don’t get any device reports without a  user action 
requesting the “VR”.  But, there is the tension between making the APIs usable, 
permission fatigue on the part of users, etc.  On top of that, there is very 
likely a need to not just “ask once at the start” but toggle access to 
sensitive info on/off as the user uses a web app (e.g., in the experimental 
Argon4 “AR-enabled” web browser, we have the ability to toggle location data 
on/off at any time without having to reload).

I think as we move toward exposing AR technology (like Tango, ARKit, Windows 
Holographic) in web user-agents, we may need to rethink how we obtain and 
manage the data user’s give to pages.  

I want the web to work well in these new application areas;  but I also want 
the characteristics of the web we love (i.e., the ability to feel relatively 
safe as you move around and follow links) to survive as well.  I believe that 
respecting user privacy and supporting their ability to control information 
flow may actually be the thing that makes the web a preferred platform for 
AR/VR,  since the various platforms are giving all data to apps automatically, 
which create a “take it or leave it” attitude regarding privacy and sensor 
information.   This is a major driver for me for how a WebAR api may structured.

Anyway, if folks want to discuss this, let me know.  We should probably move 
off this thread?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

security problems [WAS: Intent to remove: sensor APIs]

[Enrico Weigelt, metux IT consult]

On 02.08.2017 14:29, Michael Hoye wrote:


You need to dial this rhetoric back about 100%. It is not acceptable to
bring even an implied accusation like that to a technical discussion, or
indeed any conversation at all, at Mozilla.


Who did I accuse of what exactly ?

All I'd like to say here is that those features add yet another tool
for mass sourveillance.

I've grown up in the GDR regime - I've learned what it means when your
privacy is invaded or you get punished because somebody in your family
or a neighbor said a wrong word.

And we're strongly marching towards the same again, but now with the
oppressors having much better technology, in our bedrooms. It's not
fiction, it's fact - it's already there. Spying phone apps everywhere,
even spying TV sets, remote controllable cards, etc, etc.

Quite recently, the German parliament voted yet another enabling act
for mass sourveillance (eg. wiretapping people just because some
neighbour or colleque *might* possibly have done a tax fraud, etc).
And they did what w/ only a small minority of the representatives
even present (reminds me to 1933).

So, the problem is very immanent. We need to be very careful here,
which information to send out (or even aquire in the first place).
Various fingerprinting techniques already impose a big problem
(IMHO, generic cookies should never have been introduced in the
first place).


We're always happy to listen to honest criticism and walk back our
mistakes, but we are going have those discussions without demeaning the
work or comparing the people doing that work to volkscryptopolitzei
collaborators.


Please. I didn't imply anybody here collaborating with dark forces.
I'm just warning about the danger of these features.

At least these things should be purely optional and providing an
*easy* way to filter that data. (same for the geolocation stuff).


--mtx

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

Re: Intent to remove: sensor APIs

[Blair MacIntyre]

> On Wed, Aug 2, 2017 at 4:39 PM, Blair MacIntyre  
> wrote:
>> Are we still talking about deviceorientation?
> 
> As I said twice and Frederik repeated, we're not, other than asking if
> anyone has a plan for how to make it interoperable.

Yes, I know;  I was just responding to Enrico’s question. :)

> Note that it's far
> from a W3C standard: https://www.w3.org/TR/orientation-event/. Doesn't
> seem like anything got approved there.

Fair enough, sorry for my incorrect assertion, I should have checked!   So, 
this is an example of the danger, perhaps, of everybody implementing a working 
proposal before it’s approved, and then having it adopted and used widely.

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

Re: Intent to remove: sensor APIs

[Anne van Kesteren]

On Wed, Aug 2, 2017 at 4:39 PM, Blair MacIntyre  wrote:
> Are we still talking about deviceorientation?

As I said twice and Frederik repeated, we're not, other than asking if
anyone has a plan for how to make it interoperable. Note that it's far
from a W3C standard: https://www.w3.org/TR/orientation-event/. Doesn't
seem like anything got approved there.


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

Re: Intent to remove: sensor APIs

[Blair MacIntyre]

Are we still talking about deviceorientation?

It’s used to determine the 3D orientation of the device, so that we can tell 
the direction it is facing.  Developers use it to render 3D graphics (WebGL or 
CSS3D using perspective DIV) around the user.  e.g., look at one of my project 
samples, like https://samples.argonjs.io/directionsWebGL 
, which uses device location and 
deviceorientation (this simple samples puts 3D labels in the cardinal 
directions, and uses the position to illuminate them based on the current sun 
location).  The WebVR polyfill uses it to determine viewing direction, to 
simulate 3D device orientation.

It’s used for panoramic image viewing (orient the pano with the camera 
movement), and google street view uses it for similar motion control. 

Regarding security:  perhaps it is, I have seen discussions of this sort.  But, 
it would seem that ship sailed when the W3C approved it, and now it’s common 
and assumed and relied upon. Removing it in Firefox would render Firefox 
incompatible with a growing use of the web, especially mobile (including 
Windows tablets).  This might be a discussion the security team wants to have, 
I guess:  is the Firefox team worried enough about the threats opened by this 
API to justify breaking a large class of applications, and making Firefox 
unusable for AR/VR moving forward.

> On Aug 2, 2017, at 9:54 AM, Enrico Weigelt, metux IT consult 
>  wrote:
> 
> On 02.08.2017 13:01, Salvador de la Puente wrote:
>> I strongly encourage you to take a look at the telemetry stats regarding
>> the usage of deviceorientation API and other. I don't know the penetration
>> of proximity and ambient light APIs but deviceorientation is definitively
>> used.
> 
> Just curious: for what exactly is it used ?
> 
> For rendering / GUI, I'd assume that the job of the windowing system /
> compositor - the application would just see a window geometry change.
> 
> Making that information visible to websites (even worse: movement
> tracking via g-sensor, etc), definitively looks like security nightmare
> which even the Stasi never dared dreaming of.
> 
> --mtx
> 

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

Re: Intent to remove: sensor APIs

[Michael Hoye]

On Aug 2, 2017 15:54, "Enrico Weigelt, metux IT consult" <
enrico.weig...@gr13.net> wrote:



Making that information visible to websites (even worse: movement
tracking via g-sensor, etc), definitively looks like security nightmare
which even the Stasi never dared dreaming of.


You need to dial this rhetoric back about 100%. It is not acceptable to
bring even an implied accusation like that to a technical discussion, or
indeed any conversation at all, at Mozilla.

We're always happy to listen to honest criticism and walk back our
mistakes, but we are going have those discussions without demeaning the
work or comparing the people doing that work to volkscryptopolitzei
collaborators.

I encourage you to read our community participation guidelines carefully,
and to take them to heart before continuing.

Thank you.

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

Re: Intent to remove: sensor APIs

[Enrico Weigelt, metux IT consult]

On 02.08.2017 13:01, Salvador de la Puente wrote:

I strongly encourage you to take a look at the telemetry stats regarding
the usage of deviceorientation API and other. I don't know the penetration
of proximity and ambient light APIs but deviceorientation is definitively
used.


Just curious: for what exactly is it used ?

For rendering / GUI, I'd assume that the job of the windowing system /
compositor - the application would just see a window geometry change.

Making that information visible to websites (even worse: movement
tracking via g-sensor, etc), definitively looks like security nightmare
which even the Stasi never dared dreaming of.

--mtx

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

Re: Intent to remove: sensor APIs

[Frederik Braun]

As mentioned in thread, we will not disable deviceorientation.
Please see below.

On 02.08.2017 15:01, Salvador de la Puente wrote:
> I strongly encourage you to take a look at the telemetry stats regarding
> the usage of deviceorientation API and other. I don't know the penetration
> of proximity and ambient light APIs but deviceorientation is definitively
> used.
> 
> Please, consider twice before taking a final decision.
> 
> El 31 jul. 2017 3:44 p. m., "Anne van Kesteren"  escribió:
> 
>> On Mon, Jul 24, 2017 at 6:11 PM, Anne van Kesteren 
>> wrote:
>>> Please consider the request to remove device orientation retracted for
>>> now. We'll still need to figure out some kind of long term plan for
>>> that API though. WebVR building on it through libraries that abstract
>>> away the browser incompatibilities will just make it harder to fix the
>>> underpinnings going forward. (And there's always the risk that folks
>>> don't use libraries and code directly against what Chrome ships. Seems
>>> likely even.)
>>
>> Small update: we'll start by just disabling proximity. Disabling
>> ambient light will follow soon after, but is a little trickier as we
>> use the web-facing API in the Firefox for Android frontend.
>> (Suggestions for fixing the orientation interoperability mess are
>> still welcome!)
>>
>>
>> --
>> 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: Intent to remove: sensor APIs

[Salvador de la Puente]

I strongly encourage you to take a look at the telemetry stats regarding
the usage of deviceorientation API and other. I don't know the penetration
of proximity and ambient light APIs but deviceorientation is definitively
used.

Please, consider twice before taking a final decision.

El 31 jul. 2017 3:44 p. m., "Anne van Kesteren"  escribió:

> On Mon, Jul 24, 2017 at 6:11 PM, Anne van Kesteren 
> wrote:
> > Please consider the request to remove device orientation retracted for
> > now. We'll still need to figure out some kind of long term plan for
> > that API though. WebVR building on it through libraries that abstract
> > away the browser incompatibilities will just make it harder to fix the
> > underpinnings going forward. (And there's always the risk that folks
> > don't use libraries and code directly against what Chrome ships. Seems
> > likely even.)
>
> Small update: we'll start by just disabling proximity. Disabling
> ambient light will follow soon after, but is a little trickier as we
> use the web-facing API in the Firefox for Android frontend.
> (Suggestions for fixing the orientation interoperability mess are
> still welcome!)
>
>
> --
> 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

Re: Intent to remove: sensor APIs

[Anne van Kesteren]

On Mon, Jul 24, 2017 at 6:11 PM, Anne van Kesteren  wrote:
> Please consider the request to remove device orientation retracted for
> now. We'll still need to figure out some kind of long term plan for
> that API though. WebVR building on it through libraries that abstract
> away the browser incompatibilities will just make it harder to fix the
> underpinnings going forward. (And there's always the risk that folks
> don't use libraries and code directly against what Chrome ships. Seems
> likely even.)

Small update: we'll start by just disabling proximity. Disabling
ambient light will follow soon after, but is a little trickier as we
use the web-facing API in the Firefox for Android frontend.
(Suggestions for fixing the orientation interoperability mess are
still welcome!)


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

Intent to remove: prerendering

[Samael Wang]

There's an experimental framework to support  behind a 
preference implemented last year [1]. We ceased to work on it after realizing 
it's unlikely to benefit users as Chromium team indicated the usage rate is low 
and Chromium was going to remove it [2].

We'll clean up the code after 57 release since we're not going to ship this 
feature. The plan is to remove prerendering-specific code but keep 
GroupedSHistory [3], a feature to build cross-process session history without 
dropping bfcache. It was for prerendering but hopefully can also benefit some 
use cases of e10s-multi in the future.

The bug to track the removal is at:
https://bugzilla.mozilla.org/show_bug.cgi?id=1383876

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1315105
[2] https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/0nSxuuv9bBw
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=groupedshistory

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

Re: Intent to remove: sensor APIs

[Blair MacIntyre]

I’m not sure what you’re asking:  I’ve been using the deviceorientation API 
like this for many years, as have plenty of other people.It’s absolutely 
needed.
 
--
Blair MacIntyre
Principal Research Scientist
bmacint...@mozilla.com 




> On Jul 24, 2017, at 8:04 PM, Enrico Weigelt, metux IT consult 
> mailto:enrico.weig...@gr13.net>> wrote:
> 
> On 24.07.2017 20:46, Blair MacIntyre wrote:
> 
>> We are working on adding AR capabilities to the browser, and this will 
>> (similarly)
> > need to know device orientation.
> 
> Please make sure, we can easily compile completely w/o that.
> 
> 
> --mtx
> 

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

Re: Intent to remove: sensor APIs

[Enrico Weigelt, metux IT consult]

On 24.07.2017 20:46, Blair MacIntyre wrote:


We are working on adding AR capabilities to the browser, and this will 
(similarly)

> need to know device orientation.

Please make sure, we can easily compile completely w/o that.


--mtx

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

Re: Intent to remove: sensor APIs

[Enrico Weigelt, metux IT consult]

On 24.07.2017 20:43, Kearwood  Kip  Gilbert wrote:

Please note that disabling the Device Orientation API will also
effectively disable the “WebVR Polyfill”.  The “WebVR Polyfill” is a
javascript library that allows browser that otherwise don’t support VR
(ie, Fennec) to use “Cardboard” VR holders to create simple VR
experiences.


Am I the only one here still remembering that web-browsers used
to be HTTP clients w/ hypertext display ?

The whole VR stuff might be nice for some niches (eg. CAD stuff, etc),
but I wonder what that got to do w/ hypertext ...


A non-VR use case that affects 90% of users is the “magic window”
effects.  These are most commonly used by sites such as Facebook to give
some degree of freedom in viewing a 360 panorama video or photo by
moving the phone around.


A website (especially FB) getting device positioning information
delivered by the browser - that is *really* scary!

The wireless tracking (even w/o gps) already is a massive problem,
we need to care about (not a browser topic), the situation is already
worse than in the previous socialist regimes. We shouldn't make that
even worse.


Combined with media capture API’s the orientation API is also essential
for implementing things like “Google Goggle” or Yelp’s Monocle on the
web platform.


Sorry, but these kind misfeatures are a total security nightmare,
way beyond the red line. Bad enought the people collaborate w/ mass
sourveillance by using games like pokemon go (which, IMHO should be
prohibited). But infecting browers with that is magnitudes worse.


--mtx

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

Re: Intent to remove: sensor APIs

[Blair MacIntyre]

On Jul 24, 2017, at 4:38 PM, Enrico Weigelt, metux IT consult 
 wrote:
> 
> On 24.07.2017 15:07, Mike Hoye wrote:
>> 
>> I have a sense that as AR gets richer and more nuanced that ambient
> 
> Are we still talking about browsers ?


Yes.  

There are plenty of websites that use deviceorientation, for example to let you 
pan around a panographic photo or a 3D “scene” using the orientation of your 
mobile device.  

Most websites that use WebVR prefer to use “real” WebVR APIs, but on most 
mobile browsers (which don’t support them) use deviceorientation to support a 
“3DOF” (just orientation) view in the world.

We are working on adding AR capabilities to the browser, and this will 
(similarly) need to know device orientation.


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

RE: Intent to remove: sensor APIs

[Kearwood Kip Gilbert]

Please note that disabling the Device Orientation API will also effectively 
disable the “WebVR Polyfill”.  The “WebVR Polyfill” is a javascript library 
that allows browser that otherwise don’t support VR (ie, Fennec) to use 
“Cardboard” VR holders to create simple VR experiences.  Usage of these VR 
holders with non-VR capable browsers is quite prolific, with these holders 
found in most department stores.

The WebVR API when implemented directly by the browser (ie. Firefox Desktop) 
negates the need of the Device Orientation API, as it exposes the tracking data 
from the VR positional sensors in a more direct fashion.

A non-VR use case that affects 90% of users is the “magic window” effects.  
These are most commonly used by sites such as Facebook to give some degree of 
freedom in viewing a 360 panorama video or photo by moving the phone around.

Combined with media capture API’s the orientation API is also essential for 
implementing things like “Google Goggle” or Yelp’s Monocle on the web platform.

Cheers,
- Kip


From: Enrico Weigelt, metux IT consult
Sent: July 24, 2017 1:35 PM
To: Ben Kelly; Anne van Kesteren
Cc: dev-platform
Subject: Re: Intent to remove: sensor APIs

On 24.07.2017 13:57, Ben Kelly wrote:
 > On Mon, Jul 24, 2017 at 5:10 AM, Anne van Kesteren  
wrote:
 >
 >> * Device orientation
 >>
 >
 > Isn't this one required to build a decent web experience on mobile 
for some
 > sites?

Could you please define "decent web experience" ?

Maybe I'm just old, but I absolutely don't want an website know anything
about my local devices. Window size and resolution is fine, but ambient
conditions seriously crossed the red line of what I'd ever allow on my
machines.

I've already started patching out that stuff.

Same for things like USB devices, or all that "cloud" stuff.


--mtx

___
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: Intent to remove: sensor APIs

[Enrico Weigelt, metux IT consult]

On 24.07.2017 15:07, Mike Hoye wrote:


I have a sense that as AR gets richer and more nuanced that ambient


Are we still talking about browsers ?


--mtx

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

Re: Intent to remove: sensor APIs

[Enrico Weigelt, metux IT consult]

On 24.07.2017 13:57, Ben Kelly wrote:
> On Mon, Jul 24, 2017 at 5:10 AM, Anne van Kesteren  
wrote:

>
>> * Device orientation
>>
>
> Isn't this one required to build a decent web experience on mobile 
for some

> sites?

Could you please define "decent web experience" ?

Maybe I'm just old, but I absolutely don't want an website know anything
about my local devices. Window size and resolution is fine, but ambient
conditions seriously crossed the red line of what I'd ever allow on my
machines.

I've already started patching out that stuff.

Same for things like USB devices, or all that "cloud" stuff.


--mtx

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

Re: Intent to remove: sensor APIs

[Anne van Kesteren]

Please consider the request to remove device orientation retracted for
now. We'll still need to figure out some kind of long term plan for
that API though. WebVR building on it through libraries that abstract
away the browser incompatibilities will just make it harder to fix the
underpinnings going forward. (And there's always the risk that folks
don't use libraries and code directly against what Chrome ships. Seems
likely even.)

On Mon, Jul 24, 2017 at 5:07 PM, Mike Hoye  wrote:
> I have a sense that as AR gets richer and more nuanced that ambient light
> and proximity sensing will become important as well, even if we're not there
> yet.

I'm not sure that's a good reason to keep the current APIs around
though. Ambient light in particular leaks cross-origin data. It's
rather surprising we haven't acted on that thus far. And none of what
we ship ended up being standardized as such. If we actually think we
need these APIs we should put in the effort to solve the security and
standardization issues.


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

Re: Intent to remove: sensor APIs

[Blair MacIntyre]

True, true.  For example, if the ambient light sensing could deliver the kind 
of “estimation of ambient lighting” that Apple’s ARKit does, we could use that 
in rendering.

But, one question will be:  what of these capabilities should just be part of 
“WebAR”, and which can be used effectively independent of WebAR?  Especially 
when we think of issues discussed on this thread (e.g., threat models and 
security) having “things needed for AR” folded into WebAR, and accessible in 
the context of whatever permission model WebAR ends up using may be the way we 
want to go.

--
Blair MacIntyre
Principal Research Scientist
bmacint...@mozilla.com 




> On Jul 24, 2017, at 11:07 AM, Mike Hoye  > wrote:
> 
> 
> I have a sense that as AR gets richer and more nuanced that ambient light and 
> proximity sensing will become important as well, even if we're not there yet.
> 
> - mhoye
> 
> On 2017-07-24 10:39 AM, Blair MacIntyre wrote:
>> I was just about to say the same thing.  This API is essential for our AR 
>> work;  the fact that Firefox is different than other browsers is 
>> problematic, but there are javascript libraries that help with it.  Getting 
>> rid of it would be really bad.
>> 
>>> On Jul 24, 2017, at 9:57 AM, Ben Kelly >> > wrote:
>>> 
>>> On Mon, Jul 24, 2017 at 5:10 AM, Anne van Kesteren >> > wrote:
>>> 
 * Device orientation
 
>>> Isn't this one required to build a decent web experience on mobile for some
>>> sites?  It seems pretty common on mobile to adjust the UX based on whether
>>> the device is in portrait/landscape orientation.
>>> ___
>>> 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: Intent to remove: sensor APIs

[Mike Hoye]

I have a sense that as AR gets richer and more nuanced that ambient 
light and proximity sensing will become important as well, even if we're 
not there yet.


- mhoye

On 2017-07-24 10:39 AM, Blair MacIntyre wrote:

I was just about to say the same thing.  This API is essential for our AR work; 
 the fact that Firefox is different than other browsers is problematic, but 
there are javascript libraries that help with it.  Getting rid of it would be 
really bad.


On Jul 24, 2017, at 9:57 AM, Ben Kelly  wrote:

On Mon, Jul 24, 2017 at 5:10 AM, Anne van Kesteren  wrote:


* Device orientation


Isn't this one required to build a decent web experience on mobile for some
sites?  It seems pretty common on mobile to adjust the UX based on whether
the device is in portrait/landscape orientation.
___
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: Intent to remove: sensor APIs

[Blair MacIntyre]

I was just about to say the same thing.  This API is essential for our AR work; 
 the fact that Firefox is different than other browsers is problematic, but 
there are javascript libraries that help with it.  Getting rid of it would be 
really bad.

> On Jul 24, 2017, at 9:57 AM, Ben Kelly  wrote:
> 
> On Mon, Jul 24, 2017 at 5:10 AM, Anne van Kesteren  wrote:
> 
>> * Device orientation
>> 
> 
> Isn't this one required to build a decent web experience on mobile for some
> sites?  It seems pretty common on mobile to adjust the UX based on whether
> the device is in portrait/landscape orientation.
> ___
> 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: Intent to remove: sensor APIs

[Ben Kelly]

On Mon, Jul 24, 2017 at 5:10 AM, Anne van Kesteren  wrote:

> * Device orientation
>

Isn't this one required to build a decent web experience on mobile for some
sites?  It seems pretty common on mobile to adjust the UX based on whether
the device is in portrait/landscape orientation.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove: sensor APIs

[Anne van Kesteren]

As a follow-up to the Ambient Light Sensor API thread, which ended up
not really concluding, I hereby suggest we remove the various sensor
APIs from our code base. Flipping the preference first to make sure
there's no undue impact on web content and quick reversal is possible
and then removing the code in a later release.

This affects these APIs:

* Ambient light
* Proximity
* Device orientation

The rationale:

* These APIs have various privacy leaks, including violating the
same-origin policy, without the user being informed.
* These APIs do not match the current standards for sensor APIs and
some are incompatible with what is being shipped by Chrome (e.g.,
device orientation).
* There's no interest to address these shortcomings. (Mostly in the
sense of engineering resources and having other problems to tackle
first.)
* As these are event-driven APIs the compatibility impact should be
minimal to none. The events simply won't fire.

The bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1359076


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

Intent to Remove: Insecure use of WebCrypto

[Tim Taubert]

Summary: The WebCrypto spec [1] states that window.crypto.subtle
should only be usable from a secure origin (i.e. on a domain being
served over HTTPS). Currently Gecko's implementation works on insecure
origins (i.e. sites served over unencrypted HTTP). To bring our
implementation in line with the spec, we're going to remove access to
crypto.subtle on non-secure origins.

Sites using the WebCrypto API's crypto.subtle interface on a
non-secure origin should switch to HTTPS as soon as possible.

Chrome too is planning to remove access to crypto.subtle on non-secure
origins [2]. Edge seems positive about implementing those restrictions
as well [3].

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

Standard: https://w3c.github.io/webcrypto/Overview.html

Platform coverage: This will affect Windows, MacOS, Linux, and Android.

Estimated target date: This could land as early as Firefox 56, but
should in Firefox 57. We probably want to coordinate with Chrome, they
seem as ready as we are.

Our telemetry [4] indicates that about 9% of crypto.subtle use is
still on insecure origins. This was at around 1-2% - that's not the
percentage of all users, but only of those that visit pages that use
crypto.subtle - but became inflated around two weeks after we started
measuring. The blink-dev thread [2] has a good summary and indicates
that this is caused by Twitter launching AMP support serving from
origins which may be insecure. AMP has a fallback that is lazy-loaded
in case crypto.subtle isn't available, so no one's Twitter would break
when we ship this.


[1] https://w3c.github.io/webcrypto/Overview.html#crypto-interface
[2] 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ZD3NWqkk-bo/discussion
[3] https://github.com/w3c/webcrypto/issues/28#issuecomment-243243989
[4] https://mzl.la/2ttx8aV
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to remove: Insecure use of Encrypted Media Extensions

[Chris Pearce]

Summary: The EME spec [1] states that EME should only be usable from a secure 
origin (i.e. on a domain being served over HTTPS). Currently Gecko's 
implementation works on insecure origins (i.e. sites served over unencrypted 
HTTP). To bring our implementation in line with the spec, we're going to remove 
support for EME on non-secure origins.

Sites using EME that are not using secure origins should switch to HTTPS as 
soon as possible.

Chrome has just removed support for insecure EME in Chrome 58, their most 
recent release.

Motivation: EME makes use of proprietary CDMs that have access to persistent 
storage and that may transmit identifiers to DRM license servers. Requiring 
secure origin and transport makes it harder for the CDM to be attacked by 
others on the channel.

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

Standard: https://www.w3.org/TR/encrypted-media/

Platform coverage: This will affect everywhere that we support EME; Windows, 
MacOS, Linux, Android.

Estimated target date: TBD. Hopefully we can ship this by the end of 2017.

Our telemetry [2] indicates that about 18% of EME use is still on insecure 
origins. We're shipping a deprecation warning in the WebConsole in Firefox 55, 
and given that Chrome have removed this in their latest release I expect we 
should see migration of sites using EME to HTTPS. Once our telemetry indicates 
that use of EME on insecure origins is sufficiently rare, we will go ahead and 
remove support for EME on insecure origins.


[1] https://www.w3.org/TR/encrypted-media/#privacy-secureorigin
[2] https://mzl.la/2rs9maH
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: intent to remove: standalone about:addons UI and tests

[Patrick Dark]

Kris Maglione 於 3/22/2017 6:38 PM 寫道:

On Thu, Mar 23, 2017 at 08:33:56AM +0900, Mike Hommey wrote:

On Wed, Mar 22, 2017 at 02:36:31PM -0700, Robert Helmer wrote:

Currently we support running the about:addons UI in both a standalone
window, and also in a browser tab.

Firefox has only used the latter for many years, but we've continued
to maintain tests for both, which increases both our maintenance
burden and also the time it takes tests to run.

This removal is being tracked in bug 1349723.


Doesn't Thunderbird use the standalone window?


I believe they currently use a tab. If they do use, and want to 
continue using, a standalone window, they can always switch to 
embedding it in a tabbed window with the chrome UI hidden.


Thunderbird uses standalone windows for the address book, message 
composition, and message display (i.e., reading *.eml files), but not 
for the add-ons tab, as far as I know. These should all be tabs, IMO. No 
idea if that relates to this Firefox functionality removal, however.


(I wrote a private add-on that merges the address book into the main 
mail window since I hate the standalone window so much. I never got 
around to publishing it though since I couldn't figure out how to delete 
the mail window menu for the new tab.)

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

Re: intent to remove: standalone about:addons UI and tests

[Kris Maglione]

On Thu, Mar 23, 2017 at 08:33:56AM +0900, Mike Hommey wrote:

On Wed, Mar 22, 2017 at 02:36:31PM -0700, Robert Helmer wrote:

Currently we support running the about:addons UI in both a standalone
window, and also in a browser tab.

Firefox has only used the latter for many years, but we've continued
to maintain tests for both, which increases both our maintenance
burden and also the time it takes tests to run.

This removal is being tracked in bug 1349723.


Doesn't Thunderbird use the standalone window?


I believe they currently use a tab. If they do use, and want to 
continue using, a standalone window, they can always switch to 
embedding it in a tabbed window with the chrome UI hidden.

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

Re: intent to remove: standalone about:addons UI and tests

[Mike Hommey]

On Wed, Mar 22, 2017 at 02:36:31PM -0700, Robert Helmer wrote:
> Currently we support running the about:addons UI in both a standalone
> window, and also in a browser tab.
> 
> Firefox has only used the latter for many years, but we've continued
> to maintain tests for both, which increases both our maintenance
> burden and also the time it takes tests to run.
> 
> This removal is being tracked in bug 1349723.

Doesn't Thunderbird use the standalone window?

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

Re: intent to remove: standalone about:addons UI and tests

[Dave Townsend]

I agree that this has outlived its usefulness and we should remove it and
cleanup the code where we can.

On Wed, Mar 22, 2017 at 2:36 PM, Robert Helmer  wrote:

> Currently we support running the about:addons UI in both a standalone
> window, and also in a browser tab.
>
> Firefox has only used the latter for many years, but we've continued
> to maintain tests for both, which increases both our maintenance
> burden and also the time it takes tests to run.
>
> This removal is being tracked in bug 1349723.
>
>
> -rhelmer
> ___
> Dev-addons mailing list
> dev-add...@mozilla.org
> https://mail.mozilla.org/listinfo/dev-addons
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: intent to remove: standalone about:addons UI and tests

[Kris Maglione]

+1

On Wed, Mar 22, 2017 at 02:36:31PM -0700, Robert Helmer wrote:

Currently we support running the about:addons UI in both a standalone
window, and also in a browser tab.

Firefox has only used the latter for many years, but we've continued
to maintain tests for both, which increases both our maintenance
burden and also the time it takes tests to run.

This removal is being tracked in bug 1349723.


-rhelmer
___
Dev-addons mailing list
dev-add...@mozilla.org
https://mail.mozilla.org/listinfo/dev-addons


--
Kris Maglione
Firefox Add-ons Engineer
Mozilla Corporation

TeX has found at least one bug in every Pascal compiler it's been run
on, I think, and at least two in every C compiler.
--Donald Knuth

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

intent to remove: standalone about:addons UI and tests

[Robert Helmer]

Currently we support running the about:addons UI in both a standalone
window, and also in a browser tab.

Firefox has only used the latter for many years, but we've continued
to maintain tests for both, which increases both our maintenance
burden and also the time it takes tests to run.

This removal is being tracked in bug 1349723.


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

Intent to remove UIEvent.isChar

[Masayuki Nakano]

UIEvent.isChar was (probably) designed for that web apps can distinguish 
the key combination inputs character(s).


However, this is initialized only on macOS (always false on the other 
platforms) and other browsers don't support this.


Unfortunately, Add-on SDK checked this value. Currently, you see garbage 
code of referring this here:

https://dxr.mozilla.org/mozilla-central/rev/f9362554866b327700c7f9b18050d7b7eb3d2b23/addon-sdk/source/lib/sdk/keyboard/hotkeys.js#72
However, nobody refers this variable now.

Some existing add-ons have old code of this. They refer the value but 
fortunately, the behavior after removing this attribute won't be changed 
because when it's false, they refer keyCode value but the value is 
always false even with current build except on macOS.


So, I'd like to remove this non-standard attribute from Gecko.

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

--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove: support for installing multiple xpis simultaneously

[Jorge Villalobos]

On 2/18/17 7:40 AM, bird.freudent...@googlemail.com wrote:
> Unfortunately I'm using this approach to bundle my themes with an extension 
> that extends capability to them. I'm wondering why to remove this feature at 
> this point of development, since for Firefox 57 upwards XUL based addons will 
> not work anymore.
> 

There should be a blog post coming up soon in the Add-ons Blog [1]
explaining our plans for themes. I suggest you also give the latest post
a look [2].

Jorge

[1] https://blog.mozilla.org/addons/
[2]
https://blog.mozilla.org/addons/2017/02/16/the-road-to-firefox-57-compatibility-milestones/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove: support for installing multiple xpis simultaneously

[Kris Maglione]

On Sat, Feb 18, 2017 at 05:40:32AM -0800, bird.freudent...@googlemail.com wrote:
Unfortunately I'm using this approach to bundle my themes with an 
extension that extends capability to them. I'm wondering why to remove 
this feature at this point of development, since for Firefox 57 upwards 
XUL based addons will not work anymore.


The UI and back-end changes that we needed to make for the new add-on 
install flows were not compatible with the multi-extension install flows 
of multi-package XPIs and multi-install InstallTrigger calls. We had to 
make the decision between putting a lot of extra design and engineering 
work into supporting that feature, or dropping it. In the end, after 
determining that both features are very rarely used at this point, and 
don't have many compelling use cases, we decided on the latter.


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

Re: Intent to remove: support for installing multiple xpis simultaneously

[bird . freudenthal]

Unfortunately I'm using this approach to bundle my themes with an extension 
that extends capability to them. I'm wondering why to remove this feature at 
this point of development, since for Firefox 57 upwards XUL based addons will 
not work anymore.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to remove: Ability to specify the Raanana macOS system font by its Hebrew name in CSS

[Geoffrey Sneddon]

On Wed, Jan 18, 2017 at 9:38 AM, Jonathan Kew  wrote:
> Note that the current CSS Fonts 3 spec explicitly says that UAs are required
> to recognize localized font names:
>
> "Some font formats allow fonts to carry multiple localizations of the family
> name. User agents must recognize and correctly match all of these names
> independent of the underlying platform localization, system API used or
> document encoding..."[1]
>
> (The Hebrew name of Raanana is even included in the examples shown there!)
>
> As you've noted, Chrome does not actually support this, so there is not full
> interoperability in this area; but if we decide to remove this support (and
> don't implement any of the possible workarounds) then I think we need to
> bring it up in the CSS WG and see if there is agreement on explicitly
> changing it in the spec. (I'm not sure how readily Apple and Microsoft will
> buy into that, as I believe there is historically some usage of localized
> font names on both macOS and Windows, though clearly Chrome hasn't
> considered it essential.)
>
> Anyway, just wanted to point out that this is a spec issue, not something we
> should decide in isolation.
>
> JK
>
> [1] https://drafts.csswg.org/css-fonts-3/#font-family-prop

Is it currently the case that all major APIs (i.e., CoreFoundation,
GDK, Direct2D, FreeType, etc.) read all localisations of family name?
Like, will Direct2D read MacHebrew encoded names? If not, then the
only way to be compliant with what Fonts 3 says is for the browser to
support every possible character encoding in OpenType (IIRC that's a
closed set?) and convert it to something the system API can read?

I believe it's not, and I doubt anyone is going to implement that,
hence I'd guess the spec needs to change anyway.

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