Paolo Amadini wrote:
A new about:config preference named browser.download.useJSTransfer enables
the browser and the Downloads Panel to use the Downloads.jsm module instead of
nsIDownloadManager as the back-end. The browser must be restarted for the preference to
take effect.
Support for
Hi everyone,
There's been a lot of traction recently about our builds getting slower
and what we could do about it, and what not.
Starting with bug 904979, I would like to change the way we're thinking
about default flags and options. And I am therefore opening a discussion
about it.
The main
On Fri, Aug 16, 2013 at 05:43:22PM +0800, Andreas Gal wrote:
First of all, thanks for raising this. Its definitely a problem that
needs fixing.
I am not convinced by your approach though. In a few months from now
disabling WebRTC is like calling for the DOM or JS or CSS to be
disabled in
I think the key argument against this approach is that system components
are never truly isolated. Sure, some of them can be compiled out and
still produce a working system. That doesn't mean that testing without
those components is going to have good test coverage.
What I'm worried about, if
- Original Message -
I think the key argument against this approach is that system components
are never truly isolated. Sure, some of them can be compiled out and
still produce a working system. That doesn't mean that testing without
those components is going to have good test
On 16.08.2013 16:23, Andrew McCreight wrote:
- Original Message -
I think the key argument against this approach is that system components
are never truly isolated. Sure, some of them can be compiled out and
still produce a working system. That doesn't mean that testing without
those
- Remove all conditional feature configuration from configure. WebRTC et al
are always
on. Features should be disabled dynamically (prefs), if at all.
Note that Fabrice has seen sizable memory-usage wins on B2G by
disabling non-web features such as printing and XUL. That alone is,
in my
On 16/08/2013 15:14, Adam Roach wrote:
What I'm worried about, if we start disabling various modules, is that
we're going to have regressions that go unnoticed on developer systems,
blow up on m-i, and then take a _long_ time to track down.
They shouldn't take a long time to track down - a
... goes to Blake Kaplan!
He deleted 11,336 lines of code when he excised the old about:blank
parser in bug 903912.
btw, I didn't write any fancy scripts to scrape hg logs. github has
pretty graphs for mozilla-central. However, the stats are skewed by
merges and backouts.
On 16/08/2013 10.22, Neil wrote:
Paolo Amadini wrote:
A new about:config preference named browser.download.useJSTransfer
enables the browser and the Downloads Panel to use the Downloads.jsm
module instead of nsIDownloadManager as the back-end. The browser must
be restarted for the preference
On 8/15/13 2:50 PM, L. David Baron wrote:
On Thursday 2013-08-15 14:11 -0700, Gregory Szorc wrote:
I feel that having developers develop on the same toolchain as
official builds (producing bit-identical builds if possible) would
cut down on patch development costs due to reducing the frequency
11 matches
Mail list logo
