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:
> >>
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
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
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
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
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:
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
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
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
>
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
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
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
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
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
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
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
>
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 Firefox 6
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 intend to ship
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
>
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
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
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,
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
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 pr
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.
ntioning 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
> > following bug
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
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
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 launching a n
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
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
(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
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:
>
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
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:
> For a cou
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. 臘
>
>
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
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 Townsend
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
ut 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-expiration
> > into this setting,
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
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
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
> wrot
101 - 146 of 146 matches
Mail list logo