Re: Intent to remove Ambient Light and Proximity sensor APIs
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
Documentation for IPDL needs some edit
I have started to learn about IPDL and am reading IPDL Tutorial (https://developer.mozilla.org/en-US/docs/Mozilla/IPDL/Tutorial). It looks like the document is old and needs some edits, but this is an area I'm still learning so I want to make sure: 1. Nearly all of the examples lack explicit modifier before message names. AFAIK messages are required to have `async` or `sync` before them since Bug 1240871, am I right? 2. The document says `rpc` shouldn't be used for general purpose but still the example in "Subprotocols and Protocol Management" section uses it for no explicit reason. I think it should use async instead as suggested, what do you think? 3. `rpc` is mainly for NPAPI per the document, but NPAPI is dead. Why do we still need it? Not sure this is the right place to discuss about documentations, if I posted to a wrong one please inform me. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: Ensure your favorite components are up-to-date in codetribute
I was wondering why some of the bugs which I mark as good first bugs / mentored weren't appearing in codetribute[1]. Turns out that the recent (ish, :/) reorg of the Layout and DOM components made them just silently disappear from the tool, which is pretty unfortunate (as it both makes bugs unfindable, and the lack of activity on existing bugs discourage people to mark more bugs as good-first-bugs / mentored). I've fixed the stuff that I found broken in this PR[2]. Basically, fixed all the "Web Platform" / Core submodules that were missing, and added the build system product / components to "Internals", along with other nits. But please double-check me if you have the time :) If you tag yourself as a mentor of a bug, or tag a bug as a good-first-bug, or similar, please double-check that it shows up in codetribute, and fix it otherwise. Similarly, please try to remember when renaming or updating bugzilla components that it'll affect the tool. I wish the tool could do a bit better. If we could auto-include some of the components like "Layout: *" or such, the recent reorgs wouldn't have caused so much breakage. For that I filed [3]. Cheers, -- Emilio [1]: https://codetribute.mozilla.org/ [2]: https://github.com/mozilla-frontend-infra/codetribute/pull/320 [3]: https://github.com/mozilla-frontend-infra/codetribute/issues/321 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Documentation for IPDL needs some edit
On Saturday, August 10, 2019 at 11:10:58 PM UTC+9, sasch...@gmail.com wrote: > I have started to learn about IPDL and am reading IPDL Tutorial > (https://developer.mozilla.org/en-US/docs/Mozilla/IPDL/Tutorial). It looks > like the document is old and needs some edits, but this is an area I'm still > learning so I want to make sure: > > 1. Nearly all of the examples lack explicit modifier before message names. > AFAIK messages are required to have `async` or `sync` before them since Bug > 1240871, am I right? > > 2. The document says `rpc` shouldn't be used for general purpose but still > the example in "Subprotocols and Protocol Management" section uses it for no > explicit reason. I think it should use async instead as suggested, what do > you think? > > 3. `rpc` is mainly for NPAPI per the document, but NPAPI is dead. Why do we > still need it? > > Not sure this is the right place to discuss about documentations, if I posted > to a wrong one please inform me. Or rpc semantics has already been removed since Bug 1049879? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
