On 2013-11-27 2:36 AM, Gabriele Svelto wrote:
While looking through bugzilla I often stumble in my searches on old
bugs - sometimes very old - which after a quick look I realize have
either already been fixed or won't be (because they pertain to some old,
unsupported platform for example).
Much
On 2013-11-26 5:40 AM, Neil wrote:
Henri Sivonen wrote:
On Windows, do we really need to pay homage to the pre-NT legacy when
doing Save As? How about we just use UTF-8 for "HTML Page, complete"
reserialization like on Mac?
You'll need a BOM, of course.
(MXR turns up so little that it make
On 2014-01-07 6:39 AM, matteosistise...@gmail.com wrote:
On https://bugzilla.mozilla.org/show_bug.cgi?id=641509 in the
comments I can't see any valid argument that backs up the decision to
not fix the issue. At least none that would stand to the objection
which I posted as a comment:
Having a s
On 2014-01-06 7:58 PM, Karl Tomlinson wrote:
smaug writes:
Why this deprecation?
NS_ENSURE_ macros hid return paths.
That was exactly why they were a Good Thing! Normal control flow was
emphasized.
zw
___
dev-platform mailing list
dev-platfo
Count me as another person in favor of an 80-column hard limit because
of being able to open two files side-by-side with that limit, but not
anything wider (even 100 is too wide). I spend a lot of time with an
editor window tiled against a whole bunch of MXR tabs.
I either don't care or can l
Am 15.01.2014 23:08, Marcio Galli wrote:
> Something to check, that resides between engineering and legal, is how
> easy it will be for a third-party to ship the Firefox code (with the
> --app). While I understand that no UI is to be shown, I believe that
> we need to check legal aspects regarding
Hi,
Am 13.01.2014 01:34, Mike Hommey wrote:
> Let's face it: xulrunner is hardly maintained, we barely build and test
> it on automation, and the result is that it is often broken for long
> periods of time.
>
> I propose that we just stop pretending, and terminate xulrunner,
> considering the fol
The good news: bug 813742 has landed on inbound, and enables running reftests
on desktop in parallel. Either:
runreftest.py --run-tests-in-parallel
or:
mach reftest --parallel
whichever you happen to use. By default, it runs #cpus * 2 + 1 jobs, so
prepare for an explosion of windows. F
Starting today [1], you'll see a new symbol on TBPL: "Bn". These are builds
running with unified sources disabled. We're now running these
periodically on 64-bit linux (opt and debug) on all trees on the same
cadence as the PGO builds.
The purpose of these builds is to catch build problems tha
nvoking |make mozmill| TB test suite by running DEBUG BUILD of TB
under valgrind has turned out to be useful in finding memory-related
errors, AND timing-related thread race issues. The issues of second
kind, i.e., timing issues, are not usually noticed, but often they
become obvious due to the la
On Wed, Jan 15, 2014 at 10:24 AM, Dirkjan Ochtman wrote:
> This may be a stupid question, but I just saw this on the webkit
> mailing list: a way to capture network/user input events (with
> "negligible" overhead) for debugging purposes.
>
> https://lists.webkit.org/pipermail/webkit-dev/2014-Janua
This may be a stupid question, but I just saw this on the webkit
mailing list: a way to capture network/user input events (with
"negligible" overhead) for debugging purposes.
https://lists.webkit.org/pipermail/webkit-dev/2014-January/026062.html
I didn't find any bugs about this; it seems interes
12 matches
Mail list logo