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
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 f
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
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
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 unclea
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
dev-platform@lists.mozilla.org
https://lists.moz
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?)
> > - GPU process (probably
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 processes (probably should?)
> -
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
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, 2
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
>
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 JSON processors ar
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 pro
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
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
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
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
+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
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
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
https://lists.m
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
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 happened to me a few times
because
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 p
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 vol
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 load its data files?
My u
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 Sandbo
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 AM, Henri Sivonen wrote:
>
>
> Withou
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 checkers?
[…], which implements
mo
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
>>> mozISpellCheckingEngine in JS
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 t
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 strikes me that we are going to disable
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
> >> important too, but that doesn't mean the tests have zero
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 the libvoikko[1] back
>> end via j
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:
> I have not been a
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 we are going to disable until they are al
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 j
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 does sound extreme, bu
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 to assume responsibil
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), I plan to delete the
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 th
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
> mozISpellCheckingEngine in JS
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 th
42 matches
Mail list logo