On 7 June 2016 at 07:18, Mike Hommey wrote:
> MXR is already taking too long to fade out of existence, do we really
> want yet another different tool?
For some contributors (like me) this may be, because they simply don't
know that DXR is meant to replace MXR. If you want people to use DXR,
you s
On Mon, Jun 06, 2016 at 09:35:34PM -0700, Bill McCloskey wrote:
> Hi everyone,
>
> I would like to announce a new tool I've been working on for source
> code searching called Searchfox (http://searchfox.org). If you use MXR
> or DXR, I recommend you try Searchfox. Here are some of the benefits:
I
Hi everyone,
I would like to announce a new tool I've been working on for source
code searching called Searchfox (http://searchfox.org). If you use MXR
or DXR, I recommend you try Searchfox. Here are some of the benefits:
- Besides C++ code, Searchfox indexes JavaScript, XBL, and IDL. You
can s
BTW, you can tell if a crash report was triggered by this new feature
by looking for the presence of the "submitted from infobar" field.
On Sat, Jun 4, 2016 at 2:37 AM, Ehsan Akhgari wrote:
> FYI
>
> -- Forwarded message --
> From: Lawrence Mandel
> Date: Thu, Jun 2, 2016 at 6:10
That works for me. If you'd make the ticket to remove the component from
bmo dependent on the ticket to remove the code from moz-central and cc me
on the latter as we discussed, that'd be awesome. Thanks.
On Mon, Jun 6, 2016 at 1:48 PM, Brian Grinstead
wrote:
>
> > On Jun 6, 2016, at 1:20 PM, Em
> On Jun 6, 2016, at 1:20 PM, Emma Humphries wrote:
>
> There's 77 open bugs in the component, http://mzl.la/1YbBKto, how would you
> like to handle those?
The majority of these look like frontend-related bugs and feature requests
which could be closed once the code is removed. I suggest a
The fix for bug 1272772 [1] makes some minor changes to the OS X content
sandbox which is only enabled on Nightly. More changes will come as we
whittle down and simplify the sandbox rules. If you think you are hitting a
regression due to sandboxing on OS X, it's a good idea to check the OS X
Consol
On 6/3/16 11:41 AM, Boris Zbarsky wrote:
* Chrome: has been shipping the behavior I'm proposing to change to
since Chrome 50, I believe. Current Chrome release version is 51.
One note: earlier versions of Chrome claimed [object Object] for DOM
prototypes. So the claim the Google folks are ma
There's 77 open bugs in the component, http://mzl.la/1YbBKto, how would you
like to handle those?
-- Emma
On Mon, Jun 6, 2016 at 1:04 PM, Brian Grinstead
wrote:
> There is an Error Console feature in toolkit that's been replaced by the
> Browser Console. We'd like to remove associated code in
On 06/06/16 21:57, smaug wrote:
On 06/06/2016 09:24 PM, Jan Varga wrote:
On 06/06/16 17:30, smaug wrote:
On 06/06/2016 02:25 PM, Jan Varga wrote:
I landed a fix for bug 1195930 ( Use origin in QuotaManager) today,
it's now on m-c.
We had to do backwards-incompatible changes under /storage
There is an Error Console feature in toolkit that's been replaced by the
Browser Console. We'd like to remove associated code in
toolkit/components/console/ and the component in bugzilla (Toolkit: Error
Console). This will also remove the —jsconsole command line flag for consumers
that don’t
On 06/06/2016 09:24 PM, Jan Varga wrote:
On 06/06/16 17:30, smaug wrote:
On 06/06/2016 02:25 PM, Jan Varga wrote:
I landed a fix for bug 1195930 ( Use origin in QuotaManager) today, it's now on
m-c.
We had to do backwards-incompatible changes under /storage directory,
so once a profile is u
Ok, I've filed this bug to use @@toStringTag in the debugger instead of
Debugger.Object.prototype.class:
https://bugzilla.mozilla.org/show_bug.cgi?id=1278310
On Mon, Jun 6, 2016 at 10:35 AM, Boris Zbarsky wrote:
> On 6/6/16 12:23 PM, Nick Fitzgerald wrote:
>
>> Yes (via the `Debugger.Object.prot
On Thu, Jun 2, 2016 at 9:47 PM, Jean-Yves Avenard
wrote:
> On Wednesday, May 25, 2016 at 9:00:48 AM UTC+10, Gregory Szorc wrote:
> > This change was tracked in bug 1275297. Bug 1275419 tracks a follow-up to
> > allow disabling their generation.
>
> so when is xcode support coming too ? :)
>
>
Pat
On 06/06/16 17:30, smaug wrote:
On 06/06/2016 02:25 PM, Jan Varga wrote:
I landed a fix for bug 1195930 ( Use origin in QuotaManager) today,
it's now on m-c.
We had to do backwards-incompatible changes under /storage
directory, so once a profile is used with newest nigthly, then any
storage
On Mon, Jun 6, 2016 at 1:47 PM, Jared Wein wrote:
> We shouldn't hold back on providing a link to 64-bit Dev Edition users en
> masse. I worry that running an A/B test will slow down the full release
> without telling us much of anything that we don't already know.
>
> The user agent string says
On Fri, Jun 3, 2016 at 11:02 AM, Javaun Moradi wrote:
> +Clarkbw, who runs Dev Edition.
>
> Expansion of 64 bit was on hold pending the release of 47, where we had
> some critical sandboxing issues fixed and (conveniently) the Widevine CDM
> also hit that timeframe for video support.
>
> It’s an
On 6/6/16 12:23 PM, Nick Fitzgerald wrote:
Yes (via the `Debugger.Object.prototype.class` getter) but unless I've
misunderstood the scope of this proposal, the class name exposed by that
getter should not change, only the `Object.prototype.toString.call(thing)`
would change.
You misunderstood t
Well, the Debugger.Object.prototype.class getter shouldn't change, but
perhaps devtools shouldn't use it any more. Devtools should be displaying
objects in a way that doesn't surprise developers.
It seems to me the ideal behavior would be for Devtools to show objects in
the way that the ES6 standa
Yes (via the `Debugger.Object.prototype.class` getter) but unless I've
misunderstood the scope of this proposal, the class name exposed by that
getter should not change, only the `Object.prototype.toString.call(thing)`
would change.
On Mon, Jun 6, 2016 at 12:18 AM, Panos Astithas wrote:
> On Fri
On 06/06/2016 02:25 PM, Jan Varga wrote:
I landed a fix for bug 1195930 ( Use origin in QuotaManager) today, it's now on
m-c.
We had to do backwards-incompatible changes under /storage directory,
so once a profile is used with newest nigthly, then any storage API
controlled by Quota Manager (I
Many of the proposed output specifications for this seem quite useful
for the kinds of work we are doing in Servo. While this is aimed at
web developers, it seems very useful for browser vendors to be
measuring things the same way. Having standard ways of doing this
means we'll be able to get more
FYI
-- Forwarded message --
From: Lawrence Mandel
Date: Thu, Jun 2, 2016 at 6:10 PM
Subject: [desktop] Heads up: Tons of IPCError-browser | ShutDownKill
reports incoming
To: release-drivers
-- Forwarded message --
From: Andrew McCreight
Date: Thu, Jun 2, 2016
I landed a fix for bug 1195930 ( Use origin in QuotaManager) today, it's
now on m-c.
We had to do backwards-incompatible changes under /storage
directory, so once a profile is used with newest nigthly, then any
storage API controlled by Quota Manager (IndexedDB, DOM cache, asmjs
cache) won't
Hi everyone,
Here's the list of new issues found and filed by the Desktop Release QA
Team last week, *May 30 - June 03* (week 22).
Additional details on the team's priorities last week, as well as the
plans for the current week are available at:
https://public.etherpad-mozilla.org/p/Desk
On Fri, Jun 3, 2016 at 8:21 PM, Nick Fitzgerald
wrote:
> On Fri, Jun 3, 2016 at 8:41 AM, Boris Zbarsky wrote:
>
> > Devtools bug: none so far, but maybe we need one? Does devtools rely on
> > the JSClass name or Object.prototype.toString anywhere?
> >
>
> I think we are fine. There are certain
26 matches
Mail list logo
