Hi folks,
We’re all pretty overloaded these days and so, sometimes, it can be hard to
get even a small moment of help from a different team when you’re trying to
solve a problem. One example of this is when fixing a bug requires changing
a small piece of UI and, ideally, you might want to get UX i
y to allow this for one-off cases but not
> > long-term usage. Unfortunately I can't settle for a proposal like "allow
> it
> > only in debug or only in nightlies" because I often need to debug actual
> > user-facing builds. Is there any way we could build some auto-
Non-e10s is such a different environment that I don't think we have any
hope of keeping it working without running the full test suite in that mode
and I don't think anyone wants to do that. Now that this has started
breaking I think it is actively harmful to our users for us to allow them
to disab
Aha, someone has pointed out that I skipped over rusttests, which don't
appear to be listed at
https://developer.mozilla.org/en-US/docs/Mozilla/QA/Automated_testing, or
indeed anywhere in our various docs that I can see. I guess that makes it
my job?
On Mon, May 11, 2020 at 3:37 PM Dave Tow
Do we have any standard way to test in-tree Rust code?
Context: We're building a standalone binary in Rust that in the future will
be distributed with Firefox and of course we want to test it. It lives
in-tree and while we could use something like xpcshell to drive the
produced executable and veri
Thank you for doing this.
On Fri, Nov 8, 2019 at 2:44 PM Tom Ritter wrote:
> In https://bugzilla.mozilla.org/show_bug.cgi?id=1592297 I plan/hope to
> remove MOZ_QUIET and turn off the DOCSHELL/DOMWINDOW logging by default.
> It will automatically be enabled in browser-chrome tests where it is
>
JavaScript powers a lot of Firefox but unlike the other languages that ship
code in our product JavaScript uses a dynamic type system. Types for
variables are decided at execution time and can change as new values are
assigned to them. This leaves you open to accidentally passing the wrong
kind of
On Mon, Sep 9, 2019 at 6:01 PM Jeff Walden wrote:
> Those of you longer in the tooth may remember Firefox was successfully
> exploited in Pwn2own 2012...and we didn't have to lift a finger to fix it.
> We already had -- in the Firefox release shipping days later. 🤦
>
> https://bugzilla.mozilla.o
Thanks to a tip I've tracked this down. This seems to only be the case when
I have sccache enabled. Disabling it gives me nice quick incremental builds
again. Of course that isn't an ideal solution but it will do for now.
On Mon, Aug 19, 2019 at 1:55 PM Dave Townsend wrote:
> Fo
For a couple of weeks now I've seen that any attempt to build Firefox, even
incremental builds seem to rebuild an awful lot of rust code. I found this
in the source which seems to suggest why:
https://searchfox.org/mozilla-central/source/config/makefiles/rust.mk#238.
But, this means that now an inc
(If you don't know much about character encodings and how they can cause
issues I just posted the blog post for you:
https://www.oxymoronical.com/blog/2019/07/Please-watch-your-character-encodings
)
I've run into a few bugs recently where non-english characters were causing
things to break because
Prettier will share eslint's list of things to ignore and those tests are
already ignored:
https://searchfox.org/mozilla-central/rev/1133b6716d9a8131c09754f3f29288484896b8b6/.eslintignore#239
.
Of course if you want parts of that directory to be linted and formatted
then you can modify that file a
Which test files are we talking about here? If they are testing UI widgets,
and our long-term goal is to use html and not xhtml for the UI then those
tests should, at some point, be in html.
On Tue, May 14, 2019 at 1:48 PM Brian Grinstead
wrote:
> There isn't any particular reason functionally t
Is there still a configuration (ignoring hidden prefs) that can cause a
user to end up using non-e10s? If so we should turn these tests back on.
On Tue, Apr 23, 2019 at 8:25 AM Joel Maher wrote:
> Here is where we initially turned on non-e10s tests for win7:
> https://bugzilla.mozilla.org/show_b
This is awesome. It is so frustrating to hit issues that stop you from
being able to build and test your work. Glad that we're making it easier to
solve issues as you find them.
On Thu, Apr 11, 2019 at 9:12 AM Bobby Holley wrote:
> TL;DR - In bug 1543241 (alias 'mach-busted'), we now have a cent
I just landed support for MOZ_DBG for nsIFile (shows the path of the file)
and nsIURI (shows the uri spec) onto inbound.
On Sat, Mar 30, 2019 at 8:04 AM Dave Townsend wrote:
> This sounds excellent. I think on Monday I'll go right to work making this
> work for URIs which are p
This sounds excellent. I think on Monday I'll go right to work making this
work for URIs which are probably the things I end up logging the most from
C++.
On Fri, Mar 29, 2019 at 11:16 PM Cameron McCormack wrote:
> Lately I've been finding Rust's dbg!() macro[1] useful for quick
> debugging. It
ed mentioning this post on dev-platform rather than
> the bug where the regression was introduced).
>
> - Marco.
>
>
> Il 13/03/19 22:14, Dave Townsend ha scritto:
> > A quick update here. After hearing some feedback from folks I've filed
> the
> > fol
nstance is
running.
https://bugzilla.mozilla.org/show_bug.cgi?id=1535144 Return -new-instance
to its previous behaviour.
On Mon, Mar 11, 2019 at 11:35 AM Dave Townsend
wrote:
> Woah this email got long. How Firefox considers whether to pass off to an
> existing instance of Firefox or continue lau
Thank you thank you thank you thank you thank you thank you thank you thank
you thank you thank you.
(I appreciate this)
On Tue, Mar 12, 2019 at 11:15 AM Kartikaya Gupta wrote:
> Due to popular demand, searchfox now also has
> mozilla-{beta,release,esr60} repos. Text search only for now; blame
Woah this email got long. How Firefox considers whether to pass off to an
existing instance of Firefox or continue launching a new one turns out to
be more complex than you might expect. I'm mostly interested in making
folks aware of and giving feedback on how this works after I've changed
some thi
Townsend
wrote:
> Just a heads up, we've decided to defer this change to a later release to
> make sure we get the experience right for our users. I'll post another
> update once we have a better idea of when this will land.
>
> On Thu, Oct 18, 2018 at 12:32 PM Dave Townsend
This is wonderful! Thanks especially for back-filling the eslint work.
On Wed, Jan 2, 2019 at 8:58 AM Felipe G wrote:
> If you ran `mach bootstrap` or `mach vcs-setup` in the last month, you
> should already have a new hg command alias called `smart-annotate`, which
> runs `hg annotate` while ig
This suggests that channel.originalURI should help:
https://searchfox.org/mozilla-central/source/netwerk/base/nsIChannel.idl#37
On Fri, Dec 7, 2018 at 9:19 AM Henri Sivonen wrote:
> On Fri, Dec 7, 2018 at 3:23 PM Daniel Veditz wrote:
> >
> > I'm afraid to ask why you want to treat these differe
I would report this to mercurial.
On Sat, Dec 1, 2018 at 11:53 PM ISHIKAWA,chiaki
wrote:
> Hi,
>
> I am developing mozilla patches locally under my local PC running linux.
>
> I often include the GCC's error/warning message in the mercurial
> commit message (in the second and subsequent lines, t
On Thu, Nov 29, 2018 at 4:38 AM Sylvestre Ledru
wrote:
> The experimentation with dom/media highlighted that we need an efficient
> way to automatically rebase patches before the merge.
> To achieve this, we updated the bootstrap process to include an extension
> called hg formatsource.
> This ex
Just a heads up, we've decided to defer this change to a later release to
make sure we get the experience right for our users. I'll post another
update once we have a better idea of when this will land.
On Thu, Oct 18, 2018 at 12:32 PM Dave Townsend
wrote:
> In Firefox 65 we inten
ng I had setup
> just because firefox updated.
>
> On Mon, Oct 22, 2018 at 11:21 PM Dave Townsend
> wrote:
>
>> On Mon, Oct 22, 2018 at 3:20 PM Mike Hommey wrote:
>>
>>> On Thu, Oct 18, 2018 at 12:32:36PM -0700, Dave Townsend wrote:
>>> > In Fire
On Mon, Oct 22, 2018 at 3:20 PM Mike Hommey wrote:
> On Thu, Oct 18, 2018 at 12:32:36PM -0700, Dave Townsend wrote:
> > In Firefox 65 we intend to ship two new features to help prevent user
> > frustration caused by using profiles created by newer versions of
> Fi
gt;
> On Fri, Oct 19, 2018 at 2:43 PM mhoye wrote:
>
>>
>>
>> -- Original Message --
>> From: "Dave Townsend"
>> To: "dev-platform" ; "Firefox Dev" <
>> firefox-...@mozilla.org>
>> Sent: 2018-10-18 3:32:36 PM
On Fri, Oct 19, 2018 at 6:31 AM Tom Ritter wrote:
> Awesome!
>
> > On Thu, Oct 18, 2018 at 3:32 PM Dave Townsend
> wrote:
> > > For cases where users manually downgrade an install of Firefox or
> attempt
> > > to forcefully use an older version of Firefox wi
In Firefox 65 we intend to ship two new features to help prevent user
frustration caused by using profiles created by newer versions of Firefox.
Why
Firefox stores all of its settings in the user’s profile and unless certain
command line arguments are used Firefox always launches with the same
pr
If we've made the decision to stick with clang-cl, why would we continue to
support MSVC builds going forwards?
On Fri, Oct 12, 2018 at 1:06 PM Ryan VanderMeulen
wrote:
> When we made the decision to switch to clang-cl for our Windows builds,
> MSVC builds and tests were kept running as Tier 2 j
This seems to be tracked in
https://bugzilla.mozilla.org/show_bug.cgi?id=1487552
On Tue, Sep 25, 2018 at 5:12 AM J. Ryan Stinnett wrote:
> The Xcode 10 Release Notes[1] in the "Command Line Tools" heading suggests
> that future versions will not provide a *.pkg to install headers to
> /usr/inclu
This is an excellent tool and I'm using it for basically all my
submissions. Just one word of warning though, it doesn't currently support
submitting patches that contain binary files at this time. The binary file
will become truncated at phabricator, so watch out for that.
On Thu, Jul 26, 2018 at
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
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, 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
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
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'
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
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
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
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
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
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
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
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
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
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
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
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
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 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
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: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
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
___
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
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/
>
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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
> >
> >
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
> 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
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
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
The blocklist service also downloads about once a day
On Fri, Jun 26, 2015 at 10:49 AM, Anne van Kesteren
wrote:
> On Fri, Jun 26, 2015 at 10:38 AM, Richard Barnes
> wrote:
> > If anyone has use cases in addition to the above, please let me know.
>
> Public suffix? Getting that updated more fre
Are the platform fields actually useful? Most bugs apply to all platforms
and in the cases that don't it is normally clear from the bug conversation
that it is platform specific. It seems like we rarely go an update the
platform fields to match the actual state of the bug. And then there is the
pro
I would also add that I've seen cases where attempting to allow a blocked
popup doesn't work, you have to allow the site then reload the page that
triggered the popup. Obviously that is a bug in our code that we should fix
but until we do removing the permission option would entirely break these
si
1 - 100 of 162 matches
Mail list logo
