Intent to remove intl.uidirection pref

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 "bid

Intent to Remove: Fuzzyfox

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 fuz

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

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-e

Re: Intent to remove: Fennec

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

Re: Intent to remove: Fennec

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 su

Re: Intent to remove: Fennec

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:/

Re: Intent to remove: Fennec

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 aro

Re: Intent to remove: Fennec

pport, 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

Re: Intent to remove: Fennec

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 compone

Re: Intent to remove: Fennec

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 kn

Re: Intent to remove: Fennec

+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

Re: Intent to remove: Fennec

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 (Firefo

Re: Intent to remove: Fennec

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 soun

Re: Intent to remove: Fennec

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 propo

Intent to remove: Fennec

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

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 a

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

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 A

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

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.

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

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 (eve

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

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) Peop

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

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 la

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

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

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

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

Re: Intent to remove DHE ciphers from WebRTC DTLS handshake

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_

Re: Intent to remove DHE ciphers from WebRTC DTLS handshake

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, be

Intent to remove DHE ciphers from WebRTC DTLS handshake

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 Firef

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

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 Nightl

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

+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 l

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

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

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

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 s

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

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

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

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

Intent to remove most XPCOM special directories

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.mozi

Re: Intent to remove Ambient Light and Proximity sensor APIs

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 Orientat

Intent to Remove: privacy.firstparty.isolate.restrict_opener_access

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 b

Re: Intent to remove Ambient Light and Proximity sensor APIs

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:

Intent to remove: Throttling of timeouts from tracking scripts

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 th

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

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

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

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

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

<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. > > Th

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

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

Re: Intent to remove Ambient Light and Proximity sensor APIs

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

Re: Intent to remove Ambient Light and Proximity sensor APIs

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 b

Re: Intent to remove Ambient Light and Proximity sensor APIs

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 Firef

Re: Intent to remove Ambient Light and Proximity sensor APIs

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 t

Re: Intent to remove Ambient Light and Proximity sensor APIs

> 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 impleme

Re: Intent to remove Ambient Light and Proximity sensor APIs

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,

Intent to remove Ambient Light and Proximity sensor APIs

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/#!to

Intent to remove pcast and feed protocols

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 wo

Re: Intent to Remove: Insecure use of WebCrypto

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

Intent to remove: WebVR on insecure contexts

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://w3

Re: Intent to remove client.mk

n 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 >

Intent to remove: elements matching hack

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 no

Re: Intent to remove client.mk

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. > &

Re: Intent to remove client.mk

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 change

Intent to remove client.mk

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

Re: Intent to Remove: Insecure use of WebCrypto

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 makin

Intent to remove CSSStyleDeclaration.getAuthoredPropertyValue()

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)

Re: Intent to remove: EME support on insecure contexts

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 he

Re: Intent to remove:

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 is

Intent to remove: EME support on insecure contexts

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 standa

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

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 extr

Re: Intent to remove: sensor APIs

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 c

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

> 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

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

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

Re: Intent to remove: sensor APIs

> 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.

Re: Intent to remove: sensor APIs

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/orientati

Re: Intent to remove: sensor APIs

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

Re: Intent to remove: sensor APIs

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 th

Re: Intent to remove: sensor APIs

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

Re: Intent to remove: sensor APIs

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

Re: Intent to remove: sensor APIs

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. 201

Re: Intent to remove: sensor APIs

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 incomp

Intent to remove: prerendering

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

Re: Intent to remove: sensor APIs

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

Re: Intent to remove: sensor APIs

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

Re: Intent to remove: sensor APIs

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

Re: Intent to remove: sensor APIs

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,

RE: Intent to remove: sensor APIs

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

Re: Intent to remove: sensor APIs

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/d

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

Re: Intent to remove: sensor APIs

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

Re: Intent to remove: sensor APIs

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 ind

Re: Intent to remove: sensor APIs

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;

Re: Intent to remove: sensor APIs

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:

Re: Intent to remove: sensor APIs

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. _

Intent to remove: sensor APIs

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

Intent to Remove: Insecure use of WebCrypto

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

Intent to remove: Insecure use of Encrypted Media Extensions

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

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

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 l

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

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 continu

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

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 ou

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

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 th

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

+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 ma

intent to remove: standalone about:addons UI and tests

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 remov

Intent to remove UIEvent.isChar

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, yo

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

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

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

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 b

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

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. ___

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

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

  1   2   >