Hi,
Some recent PLDHashTable changes of note...
https://bugzilla.mozilla.org/show_bug.cgi?id=1201135 renamed
pldhash.{h,cpp} as PLDHashTable.{h,cpp}, to match the name of the type
defined within those files.
https://bugzilla.mozilla.org/show_bug.cgi?id=1121760 removed all the
PL_DHash*() functio
The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).
Typical meetings include news about recent API development progress and
fu
On Wed, Sep 16, 2015 at 1:42 PM, Benoit Girard wrote:
> I just
> hope that we continue to maintain mozregression as a standalone tool and
> that this wrapper doesn't cause us to miss regressions in it.
The mach wrapper essentially just calls "pip install mozregression"[1]
and passes args along, s
This is great point. Mozgression will always be a standalone tool, easy to
use for non developers. We dropped the build bisection support out of
mozregression because it was broken, hard to maintain, and also because
where mozregression really shine is the easy to use bisection of pre-built
binarie
On 9/16/15 3:02 PM, Jeff Muizelaar wrote:
Blame does work on those files locally.
Sure. Locally everything is fine.
As soon as there is good integration between dxr/mxr and local stuff,
and as soon as I can send someone a sane text representation of a local
blame display, we can just drop w
On 9/16/2015 2:32 PM, Gijs Kruitbosch wrote:
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1205376 .
FWIW, part of the reason I've been using tortoisehg is that it used to
make bzexport work, when it didn't work on Windows with the hg that
shipped with mozillabuild. It's a little ironic tha
Blame does work on those files locally. FWIW, fugitive vim's Gblame
command has the ability to jump back to the blame of parent revision
of the current line which makes it much easier to navigate history
than any web based blame tool that I've seen. Even if you only use vim
for GBlame I'd say it's
This probably doesn't need to be mentioned but I'd like to discuss it
anyways:
We often ask bug reporters and various non developers to run bisection for
us. Maintaining mozregression to work well without a code checkout (i.e.
standalone) is important. I nearly feel that it should be so easy to ru
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=1205376 .
FWIW, part of the reason I've been using tortoisehg is that it used to
make bzexport work, when it didn't work on Windows with the hg that
shipped with mozillabuild. It's a little ironic that it's now
(apparently!) the other way arou
On Wed, Sep 16, 2015 at 10:22 AM, Boris Zbarsky wrote:
> On 9/16/15 2:38 AM, Philip Chee wrote:
>
>> But we don't have a working CVS repository any more right?
>>
>
> I could be confused, but I believe the CVS repo exists. It can certainly
> be used in a read-only mode. I don't know whether it
On 9/16/15 2:01 PM, Ehsan Akhgari wrote:
Out of curiosity, which files are you mentioning here?
Here are some lovely links that all produce "This blame took too long to
generate. Sorry about that." for me:
https://github.com/mozilla/gecko-dev/blame/master/layout/base/nsCSSFrameConstructor.c
On 2015-09-15 11:53 AM, Boris Zbarsky wrote:
On 9/15/15 11:11 AM, Ben Hearsum wrote:
I'm pretty sure https://github.com/mozilla/gecko-dev has full history.
Though note that it doesn't have working blame for a lot of files in our
source tree (and especially the ones you'd _want_ to get blame fo
Thanks, exactly what I was looking for.
Axel
On 9/16/15 7:13 PM, Gavin Sharp wrote:
See
https://hg.mozilla.org/mozilla-central/annotate/3e8dde8f8c17/browser/base/content/browser.js#l1017
if you're wondering about Firefox specifically.
Gavin
On Wed, Sep 16, 2015 at 7:26 AM, Axel Hecht wrote:
On 9/16/15 2:38 AM, Philip Chee wrote:
But we don't have a working CVS repository any more right?
I could be confused, but I believe the CVS repo exists. It can
certainly be used in a read-only mode. I don't know whether it allows
commits.
-Boris
__
That sounds great!
Thanks a lot,
David
On 15/09/15 22:32, Nathan Froyd wrote:
> Hi all,
>
> For some intermittent leaks, it's not at all clear where the leaked objects
> are coming from, especially for objects that are widely used across the
> codebase. Bug 1196430 added the ability for our le
See
https://hg.mozilla.org/mozilla-central/annotate/3e8dde8f8c17/browser/base/content/browser.js#l1017
if you're wondering about Firefox specifically.
Gavin
On Wed, Sep 16, 2015 at 7:26 AM, Axel Hecht wrote:
> Hi,
>
> we're trying to find out what the default window size would be for people on
Does window.navigator.mozApps disabled for xulrunner or other reasons?
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Hello all,
Currently service workers are enabled in 42 to support push notifications,
but network interception via the FetchEvent is disabled. We've made a lot
of progress on the issues blocking this interception, however, and we feel
we are ready to move forward.
Therefore, we intend to let ser
I am pretty sure this is due to running hg from a py2exe based Mercurial
distribution on Windows. This is pretty much any hg on Windows that isn't
MozillaBuild 2.0. This includes TortoiseHg.
Things have or will break unless running MozillaBuild 2.0.
Please file a Developer Services product bug
On Windows I still get "No module named Cookie!" after using ./mach
mercurial-setup to update vcs-tools.
~ Gijs
On 15/09/2015 22:52, Jeff Walden wrote:
The Mercurial extensions to interact with Bugzilla -- bzexport and the like --
have been updated to handle 2fa details. No need to add API k
Hi,
we're trying to find out what the default window size would be for
people on screens of 1920x1080 or 1280x1024.
Sadly, I can't find the code that actually computes that for the heck of
it, can anybody help?
Background: We want to ensure that the new about:privatebrowsing has the
panels
21 matches
Mail list logo
