70 minutes is about what a clobber build takes on my Surface Book. And yes
I agree, it is way too much!
On Tue, Mar 7, 2017 at 3:24 PM, Mike Hommey wrote:
> On Tue, Mar 07, 2017 at 11:29:00AM -0800, zbranie...@mozilla.com wrote:
> > So,
> >
> > I'm on Dell XPS 13 (9350), and I don't think that t
This is awesome, thanks for implementing this!
On Wed, Mar 8, 2017 at 11:09 AM, J. Ryan Stinnett wrote:
> With bug 1275942 in Firefox 55, a new Firefox CLI option was added:
> `--wait-for-jsdebugger`.
>
> Example usage:
>
> 1. Add "debugger;" to top of browser/base/content/browser.js
> 2. $ ./ma
For a long time now we've been writing JS code that waits for promises
using Task.jsm and generator functions. Recently though the JS team added
support for the JS standard way of doing this, async/await:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function
W
t may cause problems as we attempt to automatically rewrite older
code and tests make bad assumptions.
On Thu, Mar 16, 2017 at 3:29 PM, Dave Townsend
wrote:
> For a long time now we've been writing JS code that waits for promises
> using Task.jsm and generator functions. Recently th
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
I remember that Gerv was interested in a similar idea many years ago, you
might want to see if he went anywhere with it.
https://blog.gerv.net/2005/03/link_fingerprin_1/
On Fri, Mar 24, 2017 at 10:12 AM, Gregory Szorc wrote:
> I recently reinstalled Windows 10 on one of my machines. This invol
It looks like the main concern raised about switching over to async/await
where possible is bug 1242505. We're going to try to get some resources for
fixing that bug and it probably blocks doing a mass rewrite of existing
code but I don't think it blocks people starting to use async/await right
now
On Mon, Apr 3, 2017 at 9:38 AM, Joshua Cranmer 🐧
wrote:
> On 3/16/2017 5:29 PM, Dave Townsend wrote:
>
>> For a long time now we've been writing JS code that waits for promises
>> using Task.jsm and generator functions. Recently though the JS team added
>> suppo
TL;DR: We should make each Firefox channel use its own profile data
allowing you to run multiple channels at the same time.
Running multiple channels of Firefox is currently harder than it needs to
be. You can't start more than one channel at a time and either you use the
same profile data for eac
On Fri, Jun 23, 2017 at 4:11 PM, Mike Hommey wrote:
> On Fri, Jun 23, 2017 at 03:43:54PM -0700, Dave Townsend wrote:
> > TL;DR: We should make each Firefox channel use its own profile data
> > allowing you to run multiple channels at the same time.
> >
> > Running mult
On Fri, Jun 23, 2017 at 4:37 PM, Aki Sasaki wrote:
> I'm a Nightly only user who periodically uses Release, and I'm not
> thrilled with the idea of my profile going away. Nightly users are probably
> better suited to dealing with this (using sync, etc) than the Beta
> population. Aiui, some Beta
On Fri, Jun 23, 2017 at 4:45 PM, Richard Newman wrote:
> How we populate the new profile we create for Nightly and Beta channels is
>> an open question. We could simply clone the existing Release profile or use
>> Firefox Refresh to copy across the basic data. In either case we can notify
>> the
We’re getting ready to run through a design review for our XBL replacement
plans. The review will be chaired by Dave Townsend and include a panel of
experts on both Gecko and Firefox. The review process itself is a work in
progress, and our XBL Removal review is a trial run to help us refine it.
L
On Wed, Oct 18, 2017 at 4:51 AM Mark Banner wrote:
> I remember that we had bugs of this kind lurking for years in our
> codebase, in code that was triggered daily and that everybody believed
> to be tested.
>
> I'd like to think that there is a better way to handle these bugs,
> without waiting
es to opt-in to using them, perhaps just as an experiment. Presumably
> most existing modules wouldn't, but new ones being written might.
>
> Dan
> 2017-10-18 9:06 GMT-07:00 Dave Townsend :
>
>> On Wed, Oct 18, 2017 at 4:51 AM Mark Banner wrote:
>>
>>> I r
For some time now we've been talking about moving away from XUL and XBL.
The browser architecture team has been hard at work figuring out how to go
about doing that and we're ready to share the first of our proposals more
widely. We have developed a plan to remove XBL from Firefox. It's been
throug
We have some precedent for overriding a site. Popup blocking and
redirecting new windows to tabs for example. But I'm not sure how we could
technically do this here. If the site is doing some JS work (possibly
including async stuff) ultimately ending with an assignment to
window.location how would
Dave Townsend
wrote:
> For some time now we've been talking about moving away from XUL and XBL.
> The browser architecture team has been hard at work figuring out how to
> go about doing that and we're ready to share the first of our proposals
> more widely. We have develope
Welcome to the exciting fifth instalment in our series of Browser
Architecture Newsletters!
Storage and Sync
We are pleased to report that the Sync and Storage roadmap proposal
successfully passed review by dcamp. Thanks to the 20+ people from around
the organization who helped us build consensus
On Sat, Mar 17, 2018 at 3:51 AM Patrick McManus
wrote:
> DoH is an open standard and for this test we'll be using the DoH server
> implementation at Cloudflare. As is typical for Mozilla, when we
> default-interact with a third party service we have a legal agreement in
> place to look out for th
On Sun, Mar 18, 2018 at 5:27 PM Patrick McManus
wrote:
> Obviously, using a central resolver is the downside to this approach - but
> its being explored because we believe that using the right resolver can be
> a net win compared to the disastrous state of unsecured local DNS and
> privacy and hi
As one of the folks who brought up the initial concern let me be clear that
at this point my only real concern here is one of optics. The DoH service
we're using is likely more private than anything the user is currently
using. I just don't want to see random folks on the web "discover" these
DoH r
My understanding is that it has been effectively unsupported for some time
anyway so I think we should just go ahead and disable it altogether at this
point. If we need bits for automated tests then we should work to switch
tests away from those if we can.
On Tue, Mar 27, 2018 at 8:36 AM Boris Zba
What is the point you're trying to drive home?
On Tue, Mar 27, 2018, 15:58 Steve Fink wrote:
> Just to drive home a point, let's play a game.
>
> First, guesstimate what percentage of our users have systems with 2 or
> fewer cores.
>
> Then visit https://hardware.metrics.mozilla.com/#goto-cpu-an
This is awesome. I understand that we already do some kind of pre-compile
for our chrome code, is there any plan/benefit to switch to this eventually
there?
On Wed, Apr 18, 2018 at 9:50 AM David Teller wrote:
> # Summary
>
> JavaScript parsing and compilation are performance bottlenecks. The
> J
No, super-review has not really been a thing for some time, we should
remove documentation suggesting it is. That said we definitely have room
for this kind of architectural review. Webidl for example already uses
something like this.
On Fri, Apr 20, 2018 at 2:24 PM Kris Maglione wrote:
> I can'
Presumably it supports multiple reviews for a patch, in which case I think
we're fine.
On Fri, Apr 20, 2018 at 3:03 PM Gregory Szorc wrote:
> On Fri, Apr 20, 2018 at 2:51 PM, L. David Baron wrote:
>
> > On Friday 2018-04-20 14:23 -0700, Kris Maglione wrote:
> > > For a lot of these patches, my
On Tue, May 29, 2018 at 10:03 PM Jeff Gilbert wrote:
> I get that, but it reminds me of the reasons people give for "our
> website works best in $browser".
>
I was concerned by this too but found myself swayed by the arguments in
https://blog.mozilla.org/nfroyd/2018/05/29/when-implementation-mon
On Tue, Jun 26, 2018 at 3:06 PM Sebastian Hengst wrote:
> Original-Nachricht
> Betreff: Re: mozilla-inbound backout policy subject to change (become
> similar to autoland)
> Von: Boris Zbarsky
> Datum: 2018-06-24 21:28
> > On 6/19/18 9:04 AM, Sebastian Hengst wrote:
> >> TL;DR:
On Tue, Jun 26, 2018 at 3:54 PM Gregory Szorc wrote:
> On Tue, Jun 26, 2018 at 3:45 PM, Dave Townsend
> wrote:
>
>> On Tue, Jun 26, 2018 at 3:06 PM Sebastian Hengst wrote:
>>
>> > Original-Nachricht
>> > Betreff: Re: mozilla-inbound b
Can we update the bootstrap script to install the necessary development
files?
On Wed, Jul 22, 2015 at 6:38 PM, Mike Hommey wrote:
> Hi,
>
> If you've followed the recent discussion in the "GTK3 linux builds"
> thread, this will come with no surprise, but if not:
>
> - Next Linux nightly will ha
On Wed, Aug 12, 2015 at 1:17 AM, Dirkjan Ochtman wrote:
> On Wed, Aug 12, 2015 at 4:29 AM, Dave Camp wrote:
> > Thanks to the Firefox Architects for stepping up.
>
> Sounds great!
>
> From your addressing, I assume most of the communication from/to this
> group should happen on either firefox-de
> going to be sweeping changes that affect large swaths of code.
>
> We are asking Dave Townsend, Richard Newman, Rob Helmer, Mark Hammond, and
> Robert Strong to explicitly take over technical stewardship of the Firefox
> products. Their responsibilities will be:
>
> * Document and
As of Firefox 41 we no longer support loading binary components from
add-ons.
On Sun, Nov 8, 2015 at 5:44 AM, wrote:
> Hi all.
>
> I am developing firefox addon with a binary component, and until recently
> i was using xulrunner-sdk for linking with required libs. As of version 42
> xulrunner-sd
Then I'm not sure why you need the gecko sdk to build it.
On Sun, Nov 8, 2015 at 10:19 AM, wrote:
> On Sunday, November 8, 2015 at 4:07:22 PM UTC+1, Dave Townsend wrote:
> > As of Firefox 41 we no longer support loading binary components from
> > add-ons.
> >
> >
Current release versions will load page-workers in the main process,
nightly has been updated to load in a child process if e10s is
enabled.
On Mon, Nov 23, 2015 at 10:59 PM, 罗勇刚(Yonggang Luo)
wrote:
> pageWorker = require("sdk/page-worker").Page({ contentScript:
> "console.log(document.body.in
XPCOM is available in the child process but whether the specific
component you want works there or not is a different question. Some
components have proxies in the child process to make them work, some
work just fine and some don't work at all. Which component do you care
about?
On Wed, Nov 25, 20
Thanks to some speedy work by Mark Banner and help from Mike Conley,
Felipe Gomes and Gijs Kruitbosch we've now landed the changes to make
it possible to run "mach eslint" on any directory in the tree.
The default rules for the tree are almost non-existent so this is
mostly checking for syntax err
mistake compared with how we want our code to look.
It's likely we'll land with all these rules disabled anyway and then
back-off/amend them as we try to get existing code to pass.
On Fri, Nov 27, 2015 at 2:53 PM, Dave Townsend wrote:
> Thanks to some speedy work by Mark Banner and hel
So we can keep track of all of the work going on with eslinting the
world I've filed https://bugzilla.mozilla.org/show_bug.cgi?id=1229856.
Please add any bugs that you're working on there and look there if
you're wanting to work on something.
I've also just landed the default eslint rules for brow
The developer edition already ships with e10s so you can test against that.
On Wed, Dec 2, 2015 at 10:32 PM, Yonggang Luo wrote:
> I am looking for it to developing mutli-process based firefox addons/apps
> ___
> dev-platform mailing list
> dev-platform
Assuming you are registering the protocol handler in chrome.manifest
it will only be registered in the parent process but you will probably
need to register it in the child process too and make it do something
sensible in each case. You'll have to do that with JS in a frame or
process script
On Mo
aus5 (the server the app updater checks) is still pinned:
https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/StaticHPKPins.h#739
On Mon, Jan 4, 2016 at 12:54 PM, Robert Strong wrote:
> On Mon, Jan 4, 2016 at 12:46 PM, Jesper Kristensen <
> moznewsgro...@something.to.remove.jesper
Just a heads up, a full ESLint check of the tree is now being run on
every checkin to mozilla-central or the other integration branches.
The check is also available on tryserver [1], you can run it locally
with "mach eslint" or why not make life easy and install the mercurial
extension [2].
Not ma
Is there any reason not to make the link publicly accessible? Then
no-one needs to request access.
On Thu, Jan 21, 2016 at 2:37 PM, Emma Humphries wrote:
> I understand, and if non-mozilla.com community members need access,
> email me or request access from inside the sheet.
>
> Thanks,
>
> -- Em
Should we just add a "and land it" checkbox to the review page, maybe
disabled if there are still open issues?
On Thu, Jan 21, 2016 at 6:35 PM, Gregory Szorc wrote:
> If you have level 3 source code access (can push to central, inbound,
> fx-team) and have pushed to MozReview via SSH, as of a few
Does this mean that window objects will no longer implement
nsIDOMWindow (at least as far as JS is concerned)? Querying for
nsIDOMWindow is something add-ons do a lot and I'd expect to see a lot
of add-ons break if we changed that.
On Thu, Jan 21, 2016 at 9:52 PM, Kyle Huey wrote:
> Early in the
I don't think that this is meant to impact add-on code at all, unless
it is calling browser code and making it do something unsafe, in which
case it would be up to the add-on developer to fix that. It's probably
worth filing a bug to track what is going on there though.
On Thu, Jan 28, 2016 at 6:3
On Fri, Jan 29, 2016 at 7:27 AM, Eric Rescorla wrote:
> On Fri, Jan 29, 2016 at 6:22 AM, Andrew Halberstadt <
> ahalberst...@mozilla.com> wrote:
>
>> On 28/01/16 06:31 PM, Eric Rescorla wrote:
>>
>>> On Thu, Jan 28, 2016 at 10:58 AM, Gregory Szorc
>>> wrote:
>>>
>>> I'd like to thank everyone for
On Fri, Jan 29, 2016 at 3:45 PM, Emma Humphries wrote:
> Bug Program Next Steps
>
> Over the last week, I’ve asked you to step up and identify developers who
> will be responsible for bugs triaged into their component (in Firefox, Core,
> Toolkit, Fennec iOS, and Fennec Android.)
>
> Why This Matt
I'm not sure why that page links to the nightly builds but the release
versions are here: http://archive.mozilla.org/pub/firefox/releases/
Note that Firefox 45 hasn't been released yet so the latest SDK is for
one of the beta versions.
On Wed, Feb 10, 2016 at 7:21 AM, Devan Shah wrote:
> On Wedn
On Wed, Feb 10, 2016 at 8:39 AM, Devan Shah wrote:
> On Wednesday, February 10, 2016 at 10:43:44 AM UTC-5, Dave Townsend wrote:
>> I'm not sure why that page links to the nightly builds but the release
>> versions are here: http://archive.mozilla.org/pub/firefox/releases/
>
Yeah, Firefox 41 and later don't support binary XPCOM components in
extensions. ctypes is still supported and so are binary plugins.
On Wed, Feb 10, 2016 at 5:12 PM, Kyle Huey wrote:
> Ok. I thought we killed binary components in extensions ...
>
> There will be a lot of changes around windows a
I've just landed patches on fx-team which switch the in-tree
configuration and our automatic linting checks to use ESLint 2. If
you're running linting checks locally you will need to update. As
usual "mach eslint --setup" will install the things you need.
___
On Thu, Apr 14, 2016 at 5:22 PM, Gregory Szorc wrote:
> I'm pleased to announce the immediate availability of some *experimental*
> read-only Mercurial repositories containing the combined, useful history of
> the various Firefox repositories, all in chronological order and stored in
> a more eff
Github supports using SMS as the 2nd factor in many countries (Belgium
included) so a smartphone is not always required.
https://help.github.com/articles/countries-where-sms-authentication-is-supported/
On Mon, May 23, 2016 at 3:50 PM, Jared Hirsch <6...@mozilla.com> wrote:
> A smartphone isn't
Does MozillaBuild include the appropriate version of rust?
On Wed, Aug 10, 2016 at 6:18 AM, Nathan Froyd wrote:
> TL; DR: As the subject says, although the patch is not yet on
> mozilla-central. You may want to pre-emptively update your Rust
> before the build system requires you to.
>
> We've
I am working on a patch that takes care of most of the warnings in
toolkit/mozapps/extensions/test/xpinstall in
https://bugzilla.mozilla.org/show_bug.cgi?id=1311459
On Tue, Oct 18, 2016 at 3:28 PM, Blake Kaplan wrote:
> Hello everybody,
>
> I've been seeing a pattern of "unsafe" CPOWs causing ou
One of the things I've been investigating since moving back to the desktop
team is how we can remove XUL from the application as much as possible. The
benefits for doing this are varied, some obvious examples:
* XUL is a proprietary standard and we barely maintain it.
* Shallower learning curve fo
for a new Web Component binding, to
> follow on from MattN's thinking.
>
> -- Mike
>
> On Mon, Jan 16, 2017 at 3:43 PM, Dave Townsend
> wrote:
>
>> One of the things I've been investigating since moving back to the
>> desktop team is how we can remove XUL from the
ne XUL
> document (happens when doing incremental migration), it can be challenging
> to make flex-like layouts work correctly. The standard flex layout and the
> XUL flex (-moz-box) interact in ways that are hard to understand.
>
> Jarda
>
>
>
> On Mon, Jan 16, 2017 at 9:43
good candidate.
>
> Matthew
>
> On Mon, Jan 16, 2017 at 12:43 PM, Dave Townsend
> wrote:
>
>> One of the things I've been investigating since moving back to the
>> desktop team is how we can remove XUL from the application as much as
>> possible. The bene
This is awesome, thanks for writing this up, it's made me spot one more
place where Jetpack is failing.
Can we get some more definition around "Runs on all trees that merge
into mozilla-central"? In particular I want to make that true for
Jetpack but I don't know what all those trees are.
Da
On 3/26/2013 9:17 AM, Benjamin Smedberg wrote:
On 3/26/2013 12:07 PM, Dave Townsend wrote:
This is awesome, thanks for writing this up, it's made me spot one
more place where Jetpack is failing.
Can we get some more definition around "Runs on all trees that merge
into mozilla-ce
On 4/30/2013 8:37 AM, Joshua Cranmer 🐧 wrote:
On 4/30/2013 12:33 AM, Ehsan Akhgari wrote:
On 2013-04-29 1:51 PM, Taras Glek wrote:
Writes of data <= ~64K should just be implemented as atomic whole-file
read/write operations. Those are almost always single blocks on disk.
Writing a whole file a
On 5/2/2013 3:45 PM, Nick Alexander wrote:
On 13-05-02 3:09 PM, Josh Matthews wrote:
According to
http://mxr.mozilla.org/mozilla-central/source/build/dumbmake-dependencies#8,
it is equivalent to the following:
./mach build -X chrome xpcom toolkit/library
That's correct. Or, if you're not a
On 5/2/2013 11:55 PM, Ehsan Akhgari wrote:
On 2013-05-02 7:23 PM, Dave Townsend wrote:
On 5/2/2013 3:45 PM, Nick Alexander wrote:
On 13-05-02 3:09 PM, Josh Matthews wrote:
According to
http://mxr.mozilla.org/mozilla-central/source/build/dumbmake-dependencies#8,
it is equivalent to the
On 5/3/2013 12:21 AM, Mike Hommey wrote:
On Fri, May 03, 2013 at 02:55:09AM -0400, Ehsan Akhgari wrote:
Does it also build browser/app on OSX after every build? Since that is
pretty much required all the time and often missed.
Why is that always required? I never build browser/app and have no
On 5/18/2013 3:09 AM, David Rajchenbach-Teller wrote:
Hi everyone,
As part of the ongoing effort to make (Chrome) Workers useful for
platform refactorings, we have been working on a lightweight module
loader for workers (bug 872421). This loader implements a minimal
version of CommonJ
On 5/28/2013 5:08 AM, David Rajchenbach-Teller wrote:
On 5/27/13 7:34 PM, Jonas Sicking wrote:
The alternative is to use C++ workers. This doesn't work for addons
obviously, but those aren't yet a concern for B2G.
Well, my main concern is front-end- and add-on-accessible code.
Normally, it sho
On 5/30/2013 11:51 AM, Armen Zambrano G. wrote:
Hi all,
We have found that sometimes we fail our reftest tests due to a couple
of pixels getting store in bad sectors on the RAM of our machines.
We have also seen garbage collection crashes due to it.
We have also recently discovered that memtest
On 6/24/2013 6:50 PM, Clint Talbert wrote:
Decoder and Jcranmer got code coverage working on Try[1]. They'd like to
expand this into something that runs automatically, generating results
over time so that we can actually know what our code coverage status is
with our major run-on-checkin test har
On 6/5/2013 3:48 PM, Chris AtLee wrote:
Windows desktop b2g builds have been pretty broken for several weeks
now, since around May 24 [1].
At this week's engineering and b2g meetings we discussed shutting these
off if nobody has a strong reason to keep them around.
If you are currently dependin
On Wed, Jul 17, 2013 at 6:51 PM, Mike Hommey wrote:
> Hi,
>
> As it seems there is a trend towards using in-tree mozconfigs for local
> developer builds, I think a reminder is in order:
>
> In-tree mozconfigs are for buildbot consumption.
>
> For Firefox desktop builds, a mozconfig should
The JS promise implementation came out of a desire to use promises in
add-ons and devtools amongst others. I believe the C++ implementation came
out of the DOM spec. I'm not sure why we need both.
On Tue, Jul 30, 2013 at 7:51 AM, Andreas Gal wrote:
>
> Yeah, I just saw that grepping through the
Hi everyone. I wanted to give you all a quick overview of where we are with
our plans to deliver developer tools targeted at web app developers for
Firefox OS and the web app runtimes on android and desktop.
Developer tools support in Firefox OS
We've been hard at work adding developer tools acto
I would expect that the total server load on hg.mozilla.org is high enough
that whatever you do as a single person isn't going to be even a blip on
the radar so I'd expect just a "hg pull" with a reasonable frequency would
be just fine. If you want to be sure you're up to date make a simple script
This is looking awesome and I'm going to attempt to switch my mxr quick
searches over to it. A couple of immediate things that you might want to
think about:
Right now I think mxr updates from mozilla-central faster than daily. I've
used that on a number of occasions to figure out what has broken
On Wed, Oct 2, 2013 at 1:52 PM, Boris Zbarsky wrote:
> On 10/2/13 3:33 PM, Erik Rose wrote:
>
>> What keeps you off DXR? (What are the MXR things you use constantly? Or
>> the things which are seldom-used but vital?)
>>
>
> Things that drive me nuts about mxr when I've tried to use it:
>
> * When
Frankly I wish the JSM import code didn't do what it does now, returning
the entire global scope of the module to allow anyone outside to change it.
Modules should be well contained and immutable, one piece of code shouldn't
be able to make changes that breaks other code. If we need to allow
extens
As Task.jsm is used more throughout our code it would be good to try to use
similar sorts of patterns to avoid confusion.
One difference I've spotted is in how to write asynchronous functions that
are called by tasks. One way is to simply write the function as a
generator, the other is to write th
tainly a little more verbose with two additional lines of
code and some extra indentation but it is also usable standalone whereas
the first example isn't, you need to know how to call it as a generator.
On Tue, Oct 8, 2013 at 11:47 AM, Dave Townsend wrote:
> As Task.jsm is used more
On Tue, Oct 8, 2013 at 12:20 PM, Ted Mielczarek wrote:
> On 10/8/2013 3:14 PM, Dave Townsend wrote:
> > I was asked to clarify what I meant by my two examples so here are some
> > snippets of code that illustrate it. This is forcibly async but you get
> the
> > point I
On Tue, Oct 8, 2013 at 12:34 PM, Gregory Szorc wrote:
> On 10/8/13 9:14 PM, Dave Townsend wrote:
>
>> I was asked to clarify what I meant by my two examples so here are some
>> snippets of code that illustrate it. This is forcibly async but you get
>> the
>> po
That's a pretty long bug to ask people to read over but...
The original comment about posting to dev-platform seems to be simply
asking that a thread be made to warn people that this change is coming, not
for any discussion as such. It should have happened at the time but it's a
bit late for it no
On Tue, Oct 8, 2013 at 3:30 PM, Marco wrote:
> The bug has regressed a lot of things. To me it looks like the decision
> to land it was a bit rushed. For example, I think we shouldn't have removed
> the Mac notification system, if it supported the necessary features for the
> notifications API. S
There are add-ons using the existing promises implementations. Is there any
reason not to make those wrappers around the DOM promises to avoid
potential bustage?
At least the add-on SDK promises library provides functionality beyond that
that appears to be in the DOM promises (custom prototypes fo
On Thu, Jan 9, 2014 at 9:53 AM, Chris Peterson wrote:
> On 1/9/14, 7:17 AM, Kartikaya Gupta wrote:
>
>> I think the "Target Milestone" field is poorly named, at least with
>> respect to what we use it for. In practice this field is set to the
>> version of m-c on which the patches originally lande
I sadly agree. While I still think there is value in XULRunner existing as
a standalone runtime I don't think it is worth taking any time away from
other work and it would be better to stand up and declare it dead instead
of pretending like it is going to be around long-term.
On Sun, Jan 12, 2014
Everyone who is a preferred reviewer should be a peer, if they aren't it's
likely because I forgot to update the appropriate lists. Who do you see who
is absent from the peer list?
On Sat, Jan 18, 2014 at 11:51 AM, Matthew N. wrote:
> Hello,
>
> What does it mean to be a "Preferred Reviewer" (p
seem to
> be
> >> missing from the Toolkit peer list then.
> >>
> >> Thanks,
> >> Matthew
> >>
> >> On 1/19/14, 8:47 PM, Dave Townsend wrote:
> >>
> >>> Everyone who is a preferred reviewer should be a peer, if they aren
I'm working on a plan, watch this space
On Thu, Jan 23, 2014 at 9:38 AM, Robert Kaiser wrote:
> Dave Townsend schrieb:
>
> Ideally you would have talked to the Toolkit module owner (i.e. me) before
>> adding a new chunk of code to it but Toolkit has basically become
Firefox for android only uploads information when a webpage does a location
request, MozStumbler on the other hand allows you to permanents scan for
data to send so it will send a lot more information
On Sun, Feb 2, 2014 at 10:33 PM, Cameron McCormack wrote:
> Doug Turner wrote:
>
>> In the mea
I assume the second section is actually "getcwd() not in objdir but is in
srcdir"?
I'm crazy enough to want to be able to call mach when getcwd() isn't either
the objdir or srcdir. I have many of both and use various environment flags
to say which is active currently. Perhaps it's implicit, but I
On Thu, Feb 6, 2014 at 10:57 AM, Gregory Szorc wrote:
> On 2/6/14, 9:23 AM, Dave Townsend wrote:
>
>> I assume the second section is actually "getcwd() not in objdir but is
>> in srcdir"?
>>
>
> Yes.
>
>
> I'm crazy enough to want to be able
On Thu, Feb 6, 2014 at 11:24 AM, Gregory Szorc wrote:
> On 2/6/14, 11:21 AM, Dave Townsend wrote:
>
>> On Thu, Feb 6, 2014 at 10:57 AM, Gregory Szorc > <mailto:g...@mozilla.com>> wrote:
>>
>> On 2/6/14, 9:23 AM, Dave Townsend wrote:
>>
>>
I'm guessing this is a result of
https://bugzilla.mozilla.org/show_bug.cgi?id=762556
On Mon, Mar 3, 2014 at 11:17 AM, Boris Zbarsky wrote:
> On 3/3/14 1:54 PM, Jan Honza Odvarko wrote:
>
>> An example of the stack trace:
>>
>> http://example.com/path/file.html:102
>>
>
> Which exact API is this
Since forever Jetpack tests in the Firefox trees have been run using our
custom python CFX tool which is based on a fork of an ancient version of
mozrunner. This causes us a number of problems. Keeping up with tree
visibility rules is hard. Some features from newer versions of mozrunner
like crash
On Tue, Jul 15, 2014 at 12:15 PM, Ted Mielczarek wrote:
> On 7/15/2014 2:49 PM, Dave Townsend wrote:
> > Since forever Jetpack tests in the Firefox trees have been run using our
> > custom python CFX tool which is based on a fork of an ancient version of
> > mozrunner. This
rik Skupin wrote:
> Gregory Szorc wrote on 07/15/2014 09:04 PM:
>
> > On 7/15/14, 11:49 AM, Dave Townsend wrote:
> >> Since forever Jetpack tests in the Firefox trees have been run using our
> >> custom python CFX tool which is based on a fork of an ancient version o
1 - 100 of 162 matches
Mail list logo
