Re: Changing .idl files

On Mon, Aug 07, 2017 at 10:58:11PM -0400, Boris Zbarsky wrote: On 8/7/17 6:17 PM, Nicholas Nethercote wrote: Is there going to be a clear point in time when legacy extensions stop working in Nightly? I was under the impression that there is, and I strongly feel there should be. There

Re: Changing .idl files

On 08/07/2017 08:17 PM, Kris Maglione wrote: Yes, that means that some users and developers will continue to use them, and continue to get upset when they break, but that's what they're signing up for when they flip the preference. I tend to compare this to the rooted Android ecosystem.

Re: Restricting the Notifications API to secure contexts

More than fine, this is an overdue change :) Notifications being available on http:// origins is a source of a small amount of pain for web push, because the two share the same permission. On Tue, Aug 8, 2017 at 2:24 AM, Eric Rescorla wrote: > This seems fine. > > -Ekr > > > On

Re: Changing .idl files

On Mon, Aug 07, 2017 at 08:50:38PM -0700, Fabrice Desre wrote: On 08/07/2017 08:17 PM, Kris Maglione wrote: Yes, that means that some users and developers will continue to use them, and continue to get upset when they break, but that's what they're signing up for when they flip the

Re: Changing .idl files

On 8/7/17 6:17 PM, Nicholas Nethercote wrote: Is there going to be a clear point in time when legacy extensions stop working in Nightly? I was under the impression that there is, and I strongly feel there should be. -Boris ___ dev-platform mailing

Re: Changing .idl files

On 8/7/17 11:17 PM, Kris Maglione wrote: There isn't. Not as such, anyway. By the end of the week, legacy extensions that aren't specially signed will be disabled by default. That fits what I want. That being a notification to nightly users that says "These are now officially unsupported; if

Re: Changing .idl files

On Tue, Aug 8, 2017 at 7:12 AM, Boris Zbarsky wrote: > > So if right now we land a patch that breaks addons, and a nightly user > updates, they get a broken browser and have to try to figure out whether > it's because we broken an addon (and this may not be the first thing they

Re: Changing .idl files

On Mon, Aug 07, 2017 at 07:03:52PM +0100, Jonathan Kew wrote: On 07/08/2017 18:05, Kris Maglione wrote: At the moment, legacy add-ons are allowed on nightly, but are officially unsupported. We're planning to disable them by default on nightlies, but it will still be possible to enable them by

Re: More Rust code

On Tue, Aug 08, 2017 at 07:12:13AM +0900, Mike Hommey wrote: > On Fri, Aug 04, 2017 at 08:45:14AM +0300, Henri Sivonen wrote: > > I guess I buried my questions in too long a post, so extracting them: > > > > On Mon, Jul 31, 2017 at 1:02 PM, Henri Sivonen wrote: > > >

Re: More Rust code

On Fri, Aug 04, 2017 at 08:45:14AM +0300, Henri Sivonen wrote: > I guess I buried my questions in too long a post, so extracting them: > > On Mon, Jul 31, 2017 at 1:02 PM, Henri Sivonen wrote: > > Naïvely, one would think that it should be possible to do that with > > clang

Re: Changing .idl files

On 8/7/17 1:05 PM, Kris Maglione wrote: So what is the state of things at the moment? Should we just turn off old-style addons on nightly? If not, then we should probably stop breaking them until we _do_ turn them off. I don't think so. Extension authors know the score here. OK, I thought

Re: Changing .idl files

Just for reference. With latest NoScript View Source is broken and it throws an exception now and then. Still on Beta because of this one. I won't browse the web without it. For me Web Extensions do not cut it yet and Classic Extensions are unsupported and go away. Bad timing even on a

[Firefox Desktop] Issues found: July 31st to August 4th

Hi everyone, Here's the list of new issues found and filed by the Desktop Release QA Team last week, *July 31 - August 4* (week 31). Additional details on the team's priorities last week, as well as the plans for the current week are available at:

Re: 64-bit Firefox progress report: 2017-07-18

On 8/7/2017 3:51 AM, Chris Peterson wrote: Do we test 32-bit Firefox on Win32 or Win64 today? Our Win32 tests run on 32-bit Windows 7 instances. I don't know offhand if we're using the /3GB switch or not. -Ryan ___ dev-platform mailing list

Re: webidl: partial interfaces and build-time configuration

On 07.08.2017 10:31, Gabriele Svelto wrote: On 06/08/2017 21:56, Enrico Weigelt, metux IT consult wrote: For example, I'm currently working on making the whole wakelock stuff optional (eg. only built on android). Navigator.webidl references MozWakeLock, which wouldn't exist w/o wakelocks. Do

Restricting the Notifications API to secure contexts

Chrome wants to restrict the Notifications API https://notifications.spec.whatwg.org/ to secure contexts: https://github.com/whatwg/notifications/issues/93 https://github.com/w3c/web-platform-tests/pull/6596 Given that the API involves prompting the user as well as a permission that remains

Re: 64-bit Firefox progress report: 2017-07-18

On Thu, Jul 20, 2017 at 10:42 AM, Chris Peterson wrote: > Users with only 2 GB and 5 minute browser sessions would probably have a > faster user experience with 32-bit Firefox than with 64-bit, but how do we > weigh that experience versus the security benefits of ASLR? Not

Re: 64-bit Firefox progress report: 2017-07-18

I think the 2GB "requirement" from Microsoft should be ignored, because plenty of our users are ignoring it. Nick On Mon, Aug 7, 2017 at 5:51 PM, Chris Peterson wrote: > On 2017-08-06 11:26 PM, Henri Sivonen wrote: > >> On Thu, Jul 20, 2017 at 10:42 AM, Chris

Re: webidl: partial interfaces and build-time configuration

On 06/08/2017 21:56, Enrico Weigelt, metux IT consult wrote: > For example, I'm currently working on making the whole wakelock > stuff optional (eg. only built on android). Navigator.webidl > references MozWakeLock, which wouldn't exist w/o wakelocks. Do you mean navigator.requestWakeLock()?

Re: 64-bit Firefox progress report: 2017-07-18

On 2017-08-06 11:26 PM, Henri Sivonen wrote: On Thu, Jul 20, 2017 at 10:42 AM, Chris Peterson wrote: Users with only 2 GB and 5 minute browser sessions would probably have a faster user experience with 32-bit Firefox than with 64-bit, but how do we weigh that experience

Re: webidl: partial interfaces and build-time configuration

On 8/6/17 3:56 PM, Enrico Weigelt, metux IT consult wrote: is there a way to use the partial interfaces for build-time configurable features ? Not without #ifdef. Can I move that stuff to a separate webidl file, which is only added in dom/webidl/moz.build when wakelocks enabled ? (so no

Re: webidl: partial interfaces and build-time configuration

On 8/7/17 11:28 AM, Enrico Weigelt, metux IT consult wrote: hmm, then what are the partial interfaces actually for ? They're for use in specifications that want to add things to an existing interface. They're a specification device, basically. I had the impression that distributing

Re: Restricting the Notifications API to secure contexts

This seems fine. -Ekr On Mon, Aug 7, 2017 at 6:45 AM, Anne van Kesteren wrote: > Chrome wants to restrict the Notifications API > https://notifications.spec.whatwg.org/ to secure contexts: > > https://github.com/whatwg/notifications/issues/93 >

Re: Restricting the Notifications API to secure contexts

On 07.08.2017 15:45, Anne van Kesteren wrote: Chrome wants to restrict the Notifications API https://notifications.spec.whatwg.org/ to secure contexts: wait a second ... it was wide open all the time ? --mtx ___ dev-platform mailing list

Re: webidl: partial interfaces and build-time configuration

On 07.08.2017 17:17, Boris Zbarsky wrote: Can I move that stuff to a separate webidl file, which is only added in dom/webidl/moz.build when wakelocks enabled ? (so no #ifdef's in Navigator.webidl needed) If you try to do this, you will get a message from binding codegen that explicitly says

Re: Changing .idl files

On 6/14/17 9:02 AM, Benjamin Smedberg wrote: Given that old-style addons are going away for 57, if it's possible to delay addon-breaking IDL changes by one release until 57 that's probably the easiest way to deal with this. We're already causing the addon community a lot of churn. I'd like to

Re: Changing .idl files

On Mon, Aug 07, 2017 at 12:31:30PM -0400, Boris Zbarsky wrote: On 6/14/17 9:02 AM, Benjamin Smedberg wrote: Given that old-style addons are going away for 57, if it's possible to delay addon-breaking IDL changes by one release until 57 that's probably the easiest way to deal with this. We're

Re: Changing .idl files

On Mon, Aug 7, 2017 at 10:05 AM, Kris Maglione wrote: > At the moment, legacy add-ons are allowed on nightly, but are officially > unsupported. We're planning to disable them by default on nightlies, but it > will still be possible to enable them by flipping a pref. And

Re: Changing .idl files

On 07/08/2017 18:05, Kris Maglione wrote: At the moment, legacy add-ons are allowed on nightly, but are officially unsupported. We're planning to disable them by default on nightlies, but it will still be possible to enable them by flipping a pref. Will that pref still be available in 57 once