Re: Rationalising Linux audio backend support

On Wednesday, March 22, 2017 at 1:35:06 PM UTC-5, Botond Ballo wrote: > Based on this new information, might there be room to reconsider this > decision? Even if you do not reconsider the full decision, could you at least turn it back on for v52, so it can ride the ESR train? This has also been

Re: Please do NOT hand-edit web platform test MANIFEST.json files

On 3/22/17 8:11 PM, gsquel...@mozilla.com wrote: (Is the ~10s extra build time unacceptable?) I just checked on my local machine, and a full manifest update takes over a minute. I rather doubt your machine is actually 6x faster than mine, so I have to assume that you didn't actually time a

Re: Preferences::RegisterCallback and variants will now do exact, not prefix, matches

On 3/22/17 6:17 PM, zbranie...@mozilla.com wrote: On Tuesday, March 21, 2017 at 7:46:07 PM UTC-7, Boris Zbarsky wrote: Are you properly handling the fact that AddStrongObserver watches all prefs starting with the prefix you pass it? ;) I don't, and I'd love not to. I know perfectly well this

Re: e10s-multi update and tests

On Thursday, March 23, 2017 at 2:37:18 PM UTC+13, Nicholas Nethercote wrote: > On Thu, Mar 23, 2017 at 12:12 PM, Andrew McCreight > wrote: > > > > > Though maybe you are asking which processes count against the limit of 4. > > > > Yes, that's what I am asking. > > Nick I think there's only one

Re: unowned module: Firefox::New Tab Page, help me find an owner

Benjamin Smedberg writes: > This is not the list for this question. Please respect this question to the > firefox-dev list. https://wiki.mozilla.org/Firefox/firefox-dev says "Anyone can post. By default, posts will be reviewed by a moderator before being sent to the list." bit in fact some

Re: e10s-multi update and tests

On Thu, Mar 23, 2017 at 12:12 PM, Andrew McCreight wrote: > > Though maybe you are asking which processes count against the limit of 4. > Yes, that's what I am asking. Nick ___ dev-platform mailing list

Re: e10s-multi update and tests

On Wed, Mar 22, 2017 at 9:12 PM, Andrew McCreight wrote: > On Wed, Mar 22, 2017 at 6:00 PM, Nicholas Nethercote < > n.netherc...@gmail.com > > wrote: > > > Do we have a clear definition of "content process"? I.e. does/will it > > include: > > > > - GMP processes (no?) > >

Re: e10s-multi update and tests

On Wed, Mar 22, 2017 at 6:00 PM, Nicholas Nethercote wrote: > Do we have a clear definition of "content process"? I.e. does/will it > include: > > - GMP processes (no?) > - GPU process (probably not?) > - file:// URL processes (probably should?) > - Web Extensions

Re: Revocation protocol idea

This seems a little like the idea WOT(https://www.mywot.com/) had, Showing the user that they might be looking at a website that isn't considered great but isn't perhaps bad enough to be blocked. I agree that one web actor owning this power isn't a great place to be in and that in itself might be

Re: e10s-multi update and tests

Do we have a clear definition of "content process"? I.e. does/will it include: - GMP processes (no?) - GPU process (probably not?) - file:// URL processes (probably should?) - Web Extensions processes (probably should?) - ServiceWorker processes (probably should?) Thanks. Nick On Thu, Mar 23,

Re: Please do NOT hand-edit web platform test MANIFEST.json files

On Saturday, March 18, 2017 at 5:01:17 AM UTC+11, Boris Zbarsky wrote: > We have tools for this: "mach wpt-manifest-update" will do the right thing. > > The typical result of hand-edits is that later changesets that do use > the tools end up conflicting with each other, as they all fix up the >

Re: Please do NOT hand-edit web platform test MANIFEST.json files

On Tue, Mar 21, 2017 at 7:44 PM, Boris Zbarsky wrote: > On 3/21/17 6:41 PM, Jeff Gilbert wrote: > >> JSON allows comments if all the JSON processors we use handle comments. :) >> > > JSON.parse in JS does not. > > The Python "json" module does not as far as I can tell. > > What

e10s-multi update and tests

Hello all, As some of you might have noticed, we are now defaulting to 4 content processes on Nightly builds! We're continuing to collect data and planning on running experiments with different numbers of processes to generate more data and allow us to fine-tune our defaults and strategies for

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

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

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

Re: Preferences::RegisterCallback and variants will now do exact, not prefix, matches

On Tuesday, March 21, 2017 at 7:46:07 PM UTC-7, Boris Zbarsky wrote: > Are you properly handling the fact that AddStrongObserver watches all > prefs starting with the prefix you pass it? ;) I don't, and I'd love not to. I know perfectly well this two strings I want to watch only them. I don't

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

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

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 3/22/17 3:27 PM, Boris Zbarsky wrote: On 3/22/17 2:38 PM, Mats Palmgren wrote: Does that sound reasonable? Yes, thank you! Seconded. -- Mike Taylor Web Compat, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 3/22/17 2:38 PM, Mats Palmgren wrote: Does that sound reasonable? Yes, thank you! -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform

Re: Sheriff Highlights and Summary in February 2017

Also sprach Andrew Halberstadt : > I don't have any data to back this up, but my suspicion is that a > large percentage of backouts had try runs, but said try runs > didn't run the jobs that failed and caused the backout. I ascribe to this explanation. This has

Re: Intent to implement and ship CSS 'appearance' with '-webkit-appearance' as an alias. Unship '-moz-appearance'.

On 02/17/2017 03:22 AM, Boris Zbarsky wrote: I thought about this a fair bit the last few days, and I think it would be a mistake to tie shipping appearance/-webkit-appearance to the removal of -moz-appearance. We should ship the no-prefix version and the -webkit version. Then we should get

Re: Rationalising Linux audio backend support

Now that this change has hit the release channel, we've started receiving feedback from a wider range of users, a lot of it in bug 1345661 [1]. I believe the feedback in that thread brings some new information to the table that we weren't aware of when this decision was made: - Based on the

Re: Future of out-of-tree spell checkers?

On Wed, Mar 22, 2017 at 11:08 AM, Henri Sivonen wrote: > > dlopening libvoikko, if installed, and having thin C++ glue code > in-tree seems much simpler, except maybe for sandboxing. What are the > sandboxing implications of dlopening a shared library that will want > to

Re: Future of out-of-tree spell checkers?

Hey Henri, Freddy pointed me to the sandboxing part of the question, here is my impression. In general, if the Sandbox is running any additional code that is not in the tree could also be accomplished with a compromised child process. However in case of dlopen() it is important to know our

Re: Future of out-of-tree spell checkers?

On Wed, Mar 22, 2017 at 4:45 PM, Axel Hecht wrote: > Am 22.03.17 um 15:39 schrieb Jorge Villalobos: >> >> On 3/22/17 8:10 AM, Henri Sivonen wrote: >>> >>> On Wed, Mar 22, 2017 at 3:52 PM, Nicolas B. Pierron >>> wrote: On 03/22/2017 09:18

Re: Future of out-of-tree spell checkers?

Am 22.03.17 um 15:39 schrieb Jorge Villalobos: On 3/22/17 8:10 AM, Henri Sivonen wrote: On Wed, Mar 22, 2017 at 3:52 PM, Nicolas B. Pierron wrote: On 03/22/2017 09:18 AM, Henri Sivonen wrote: Without XPCOM extensions, what's the story for out-of-tree spell

Re: Future of out-of-tree spell checkers?

On 3/22/17 8:10 AM, Henri Sivonen wrote: > On Wed, Mar 22, 2017 at 3:52 PM, Nicolas B. Pierron > wrote: >> On 03/22/2017 09:18 AM, Henri Sivonen wrote: >>> >>> Without XPCOM extensions, what's the story for out-of-tree spell checkers? >>> >>> […], which implements

Re: unowned module: Firefox::New Tab Page, help me find an owner

On 22/03/2017 13:22, jma...@mozilla.com wrote: I have not been able to find an owner for the Firefox::New Tab Page bugzilla component (bug 1346908). There are 35 tests in the tree and without anyone to assume responsibility for them when they are intermittent (bug 1338848), I plan to delete

Re: unowned module: Firefox::New Tab Page, help me find an owner

On Wed, Mar 22, 2017 at 10:00 AM, David Burns wrote: > On 22 March 2017 at 13:49, Ben Kelly wrote: > >> Finding someone to own the feature and investigate intermittents is >> important too, but that doesn't mean the tests have zero value. >> > > This just

Re: unowned module: Firefox::New Tab Page, help me find an owner

On Wed, Mar 22, 2017 at 10:33 AM, Ben Kelly wrote: > On Wed, Mar 22, 2017 at 10:00 AM, David Burns wrote: > > > On 22 March 2017 at 13:49, Ben Kelly wrote: > > > >> Finding someone to own the feature and investigate intermittents is >

Re: Future of out-of-tree spell checkers?

On Wed, Mar 22, 2017 at 3:52 PM, Nicolas B. Pierron wrote: > On 03/22/2017 09:18 AM, Henri Sivonen wrote: >> >> Without XPCOM extensions, what's the story for out-of-tree spell checkers? >> >> […], which implements >> mozISpellCheckingEngine in JS and connects to

Re: unowned module: Firefox::New Tab Page, help me find an owner

This is not the list for this question. Please respect this question to the firefox-dev list. Also I recommend that another way to get traction in this sort of question is to contact the moisture owner, in the case Dave Townsend. --BDS On Wed, Mar 22, 2017 at 9:25 AM wrote:

Re: unowned module: Firefox::New Tab Page, help me find an owner

On 22 March 2017 at 13:49, Ben Kelly wrote: > On Wed, Mar 22, 2017 at 9:39 AM, wrote: > > > Finding someone to own the feature and investigate intermittents is > important too, but that doesn't mean the tests have zero value. > This just strikes me that

Re: Future of out-of-tree spell checkers?

On 03/22/2017 09:18 AM, Henri Sivonen wrote: Without XPCOM extensions, what's the story for out-of-tree spell checkers? […], which implements mozISpellCheckingEngine in JS and connects to the libvoikko[1] back end via jsctypes. […] Would compiling libvoikko to WebAssembly remove the need for

Re: unowned module: Firefox::New Tab Page, help me find an owner

On Wed, Mar 22, 2017 at 9:39 AM, wrote: > On Wednesday, March 22, 2017 at 9:35:35 AM UTC-4, Ben Kelly wrote: > > You plan to delete all the tests? This seems somewhat extreme for a > > shipped feature. Why not disable just the tests that are intermittent? > > I agree that

Re: unowned module: Firefox::New Tab Page, help me find an owner

On Wednesday, March 22, 2017 at 9:35:35 AM UTC-4, Ben Kelly wrote: > On Wed, Mar 22, 2017 at 9:22 AM, wrote: > > > I have not been able to find an owner for the Firefox::New Tab Page > > bugzilla component (bug 1346908). There are 35 tests in the tree and > > without anyone

Re: unowned module: Firefox::New Tab Page, help me find an owner

On Wed, Mar 22, 2017 at 9:22 AM, wrote: > I have not been able to find an owner for the Firefox::New Tab Page > bugzilla component (bug 1346908). There are 35 tests in the tree and > without anyone to assume responsibility for them when they are intermittent > (bug 1338848),

unowned module: Firefox::New Tab Page, help me find an owner

I have not been able to find an owner for the Firefox::New Tab Page bugzilla component (bug 1346908). There are 35 tests in the tree and without anyone to assume responsibility for them when they are intermittent (bug 1338848), I plan to delete them all if I cannot get an owner by the end of

Re: Future of out-of-tree spell checkers?

On Wed, Mar 22, 2017 at 11:18 AM, Henri Sivonen wrote: > Without XPCOM extensions, what's the story for out-of-tree spell checkers? > > Finnish spell checking in Firefox (and Thunderbird) has so far been > accomplished using the mozvoikko extension, which implements >

Future of out-of-tree spell checkers?

Without XPCOM extensions, what's the story for out-of-tree spell checkers? Finnish spell checking in Firefox (and Thunderbird) has so far been accomplished using the mozvoikko extension, which implements mozISpellCheckingEngine in JS and connects to the libvoikko[1] back end via jsctypes. (Even