Re: Proposed W3C Charter: Audio Working Group

On Wed, Oct 26, 2016 at 7:25 PM, L. David Baron wrote: > On Friday 2016-10-21 15:01 -0700, Tantek Çelik wrote: >> Support revised charter, with requested changes: >> * Hyperlink the phrase "Community Group" in the charter to the >> specific Community Group they mean, and

Re: Proposed W3C Charter: Audio Working Group

On Friday 2016-10-21 15:01 -0700, Tantek Çelik wrote: > Support revised charter, with requested changes: > * Hyperlink the phrase "Community Group" in the charter to the > specific Community Group they mean, and perhaps title the hyperlink > more specifically as well. > * List the Community Group

Re: Intent to restrict to secure contexts: navigator.geolocation

On Wed, Oct 26, 2016 at 4:26 PM, Jan-Ivar Bruaroey wrote: > On 10/26/16 6:28 PM, Matthew N. wrote: > >> On 2016-10-26 1:40 PM, Jan-Ivar Bruaroey wrote: >> >>> At the risk of sounding pragmatic/opportunistic, why not wait until the >>> usage numbers go down, as they're bound to?

Re: Intent to restrict to secure contexts: navigator.geolocation

On 2016-10-26 1:40 PM, Jan-Ivar Bruaroey wrote: At the risk of sounding pragmatic/opportunistic, why not wait until the usage numbers go down, as they're bound to? And in the meantime we could remove the "always allow" option for geolocation over HTTP like we do for another permission (WebRTC

New presentation of startup crashes on crash-stats

Greetings, The presentation of start-up crashes on crash-stats has improved recently. If you look at the top crashes for Nightly (https://crash-stats.mozilla.com/topcrashers/?product=Firefox=52.0a1=7) you will see three different icons that are next to some crash signatures: a rocket, a red flag,

Re: Intent to restrict to secure contexts: navigator.geolocation

At the risk of sounding pragmatic/opportunistic, why not wait until the usage numbers go down, as they're bound to? .: Jan-Ivar :. On 10/25/16 7:10 PM, Karl Dubost wrote: Interesting thread. Going back to the starting email: Le 22 oct. 2016 à 04:49, Richard Barnes a

Re: Removing the Battery Status API?

On 10/26/2016 9:21 AM, Boris Zbarsky wrote: So I decided to see what sites were doing with it. I set a breakpoint in getBattery() and tried browsing. The first site I tried loading was cnn.com, and it hit the breakpoint. It's hitting it because it's using the "boomerang" library from

Re: Removing the Battery Status API?

On 10/26/16 3:30 AM, Chris Peterson wrote: The BATTERY_STATUS_COUNT probe [4] reports over 200M battery API calls for Firefox 49. The USE_COUNTER2_DEPRECATED_NavigatorBattery_PAGE probe [5] reports that 6% of web pages use the Battery API, IIUC. That seems surprisingly high given the few

Re: Intent to remove: nsIHTMLEditor.setDocumentTitle()

On 26/10/2016 09:50, Masayuki Nakano wrote: nsIHTMLEditor.setDocumentTitle() is used only by Thunderbird, Mail and Composer of SeaMonkey. Additionally, they can set editable document title with |document.title = "foo";|. No problem. Thanks for the heads-up. Already addressed in

Re: Removing the Battery Status API?

On 26/10/2016 08:30, Chris Peterson wrote: What is the use case for the Battery Status API [0], navigator.getBattery()? Can we remove the Battery API or perhaps restrict it to non-web content like browser extensions or privileged web apps? Chrome and Firefox support the Battery API, but neither

Re: Removing the Battery Status API?

On 26/10/2016 08:54, Anne van Kesteren wrote: On Wed, Oct 26, 2016 at 9:30 AM, Chris Peterson wrote: (Could that counter be inadvertently triggered by web content that simply enumerates the navigator object's properties without actually calling navigator.getBattery()?)

Re: Intent to restrict to secure contexts: navigator.geolocation

> > On 10/25/2016 6:26 AM, Ehsan Akhgari wrote: > >> FWIW, and to the extent that my opinion matters on the topic, I strongly >> disagree that breaking the websites that people use silently is the >> right thing to do. >> >> Let's ignore the HTTPS Everywhere part of the thread, and instead pay >>

Re: Proposed W3C Charter: Audio Working Group

We should support this new charter. We've been commenting, specifying and implementing both specs of this Working Group (Although we've not shipped Web MIDI at the moment), and we're participating very actively in the development of those standards (V1.0 and V2.0 for Web Audio API, lighter

Re: Removing the Battery Status API?

On Wed, Oct 26, 2016 at 9:30 AM, Chris Peterson wrote: > (Could that counter be > inadvertently triggered by web content that simply enumerates the navigator > object's properties without actually calling navigator.getBattery()?) That seems unlikely given it's a method so

Intent to remove: nsIHTMLEditor.setDocumentTitle()

nsIHTMLEditor.setDocumentTitle() is used only by Thunderbird, Mail and Composer of SeaMonkey. Additionally, they can set editable document title with |document.title = "foo";|. The only difference of a call of |nsIHTMLEditor.setDocumentTitle()| and |document.title = "foo";| is,

Removing the Battery Status API?

What is the use case for the Battery Status API [0], navigator.getBattery()? Can we remove the Battery API or perhaps restrict it to non-web content like browser extensions or privileged web apps? Chrome and Firefox support the Battery API, but neither Edge nor WebKit have signaled an intent

Re: Intent to restrict to secure contexts: navigator.geolocation

On Tue, Oct 25, 2016 at 8:24 PM, Aryeh Gregor wrote: > By that logic, we should not permit users to submit forms to non-HTTPS > either. And we are starting to flag pages that request passwords over non-HTTPS: