Re: Adopting the black Python code style

[Andrew McCreight]

On Mon, Oct 12, 2020 at 10:05 AM Ricky Stewart  wrote:

> Hello everyone,
>
> If you don't write Python code in mozilla-central, you can stop reading
> now.
>
> On October 19, 2020 we will be officially adopting the black Python style
> for all our Python code in mozilla-central.
>
> black (https://black.readthedocs.io/en/stable/) is an opinionated, fast,
> and correct auto-formatter for Python. It is an increasingly popular
> autoformatter which might be considered the de facto standard for Python
> code (like clang-format and jslint are for C++ and JS). It is already used
> by several Mozilla projects, including Release Engineering, Lando, and
> moz-phab.
>
> black makes it easy for us to reliably format all our Python code in a
> consistent way, making the codebase easier to read on the whole and
> allowing us to spend more time in code review discussing substantive issues
> over trivial formatting matters.
>
> This policy change will affect all Python code in-tree, including
> sandboxed Python code used by the build system (.configure, .build, and
> .mozbuild files).
>
> As part of this policy change, we plan on doing a one-time auto-reformat
> on October 19 of all Python code in the entire repository. In addition,
> mach lint (
> https://firefox-source-docs.mozilla.org/code-quality/lint/linters/black.html)
> and reviewbot will be updated to print warnings for Python source files
> that violate the black style. Just like with C/C++ or Rust, we won’t
> backout offending changes but instead will do regular refreshes of the tree.
>
> If there are any questions, please let me know!
>

Is there some way we can see the results of this change before it lands in
the tree? I would like to review the results of formatting for Python files
I care about to make sure nothing gets too messed up by it. For instance,
clang-format did some kind of line wrapping for wide comments that broke a
lot of ASCII diagram comments, and I and others had to spend a fair amount
of time fixing that.

Relatedly, is there some way to disable formatting for specific lines of
code, in case there's something that gets mangled by the formatting and
there's no easy way to fix it?

What does "all Python code in-tree" mean? Does that mean that this is going
to be run on all files that end in .py? I assume that this doesn't apply to
any third party code we have in the tree (either under the third-party
directory, or included in whatever other list I think we have)?

Thanks,
Andrew


> Ricky
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: A new testing policy for code landing in mozilla-central

[Andrew McCreight]

On Wed, Sep 16, 2020 at 5:10 AM Eric Rescorla  wrote:

> I certainly have some sympathy for this, but I'm not sure that it needs to
> be
> addressed via tools. What I would generally expect in cases like this is
> that the reviewer says "why isn't there a test for X" and the author says
> "for reason Y" and either the reviewer does or does not accept that.
> That's certainly been my experience on both sides of this interaction
> in previous instances where there were testing policies but not this
> machinery.
>

Sure, but it just adds latency to the whole process. Hopefully requiring an
extra round trip will be rare.


> Also, contrary to what ahal said, I don't know that tests being an official
>> requirement relieves the burden of guilt of asking for tests, as everybody
>> already knows that tests are good and that you should always write tests.
>>
>
> I also don't know about how this will impact people's internal states; I
> see
> this as having two major benefits:
>
> 1. It tells people what we expect of them
> 2. It gives us the ability to measure what's actually happening and adjust
> accordingly.
>
> To expand on (2) a bit, if we look back and find that there was a lot of
> code
> landed without tests but where exceptions weren't filed, then we know we
> need to work on one set of things. On the other hand, if we see that there
> are a lot of exceptions being filed in cases we don't think there should
> be (for whatever reason) then we need to work on a different set of things
> (e.g., improving test frameworks in that area).
>

Yeah, I think gathering data about what the actual level of testing is a
great output of this process. I'm curious to see what it will turn up.
Presumably it could also be bucketed by Bugzilla components and so forth.


>
>
>> My perspective might be a little distorted as I think a lot of the patches
>> I write would fall under the exceptions, either because they are
>> refactoring, or I am fixing a crash or security issue based on just a
>> stack
>> trace.
>>
>> Separately, one category of fixes I often deal with is fixing leaks or
>> crashes in areas of the code I am unfamiliar with. I can often figure out
>> the localized condition that causes the problem and correct that, but I
>> don't really know anything about, say, service workers or networking to
>> write a test. Do I need to hold off on landing until I can find somebody
>> who is willing and able to write a test for me, or until I'm willing to
>> invest the effort to become knowledgeable enough in an area of code I'm
>> unlikely to ever look at again? Neither of those feel great to me.
>>
>
> Agreed that it's not an ideal situation. I think it's important to step
> back and
> ask how we got into that situation, though. I agree that it's not that
> productive
> for you to write the test, but hopefully *someone* at Mozilla understands
> the
> code and is able to write a test and if not we have some other problems,
> right?
> So what I would hope here is that you were able to identify the problem,
> maybe write a fix and then hand it off to someone who could carry it over
> the
> line.
>

I mean, everybody has their own priorities. Part of the reason I'm fixing
leaks in random code is because I understand the leak fixing tools very
well, but part of it is also that I care more about leaks than the average
person. If I've fixed a leak in an obscure error case in some web API,
maybe the experts in that API are willing to review a patch to fix the
leak, but if they have to weigh trying to figure out how to write a test
for the leak versus meeting some important deadline or their H2 goal, maybe
they aren't going to be able to get to it quickly. I can't even say that's
the wrong decision for them to make.


>
>
>> Another testing difficulty I've hit a few times this year (bug 1659013 and
>> bug 1607703) are crashes that happen when starting Firefox with unusual
>> command line or environment options. I think we only have one testing
>> framework that can test those kinds of conditions, and it seemed like it
>> was in the process of being deprecated. I had trouble finding somebody who
>> understood it, and I didn't want to spend more than a few hours trying to
>> figure it out for myself, so I landed it without testing. To be clear, I
>> could reproduce at least one of those crashes locally, but I wasn't sure
>> how to write a test to create those conditions. Under this new policy, how
>> do we handle fixing issues where there is not always a good testing
>> framework already? Writing a test is hopefully not too much of a burden,
>> but obviously having to develop and maintain a new testing framework could
>> be a good deal of work.
>>
>
> As a general matter, I think we need to be fairly cautious about landing
> code
> where we aren't able to test. In some cases that means taking a step back
> and doing a lot of work on the testing framework before you can write some
> comparatively trivial code, which obviously is 

Re: A new testing policy for code landing in mozilla-central

[Andrew McCreight]

On Tue, Sep 15, 2020 at 8:03 AM Brian Grinstead 
wrote:

> (This is a crosspost from firefox-dev)
>
> Hi all,
>
> We’re rolling out a change to the review process to put more focus on
> automated testing. This will affect you if you review code that lands in
> mozilla-central.
>
> ## TLDR
>
> Reviewers will now need to add a testing Project Tag in Phabricator when
> Accepting a revision. This can be done with the “Add Action” → “Change
> Project Tags” UI in Phabricator. There's a screenshot of this UI at
> https://groups.google.com/g/firefox-dev/c/IlHNKOKknwU/m/zl6cOlT2AgAJ.
>

I of course think having more tests is a good thing, but I don't like how
this specific process places all of the burden of understanding and
documenting some taxonomy of exceptions on the reviewer. Reviewing is
already a fairly thankless and time consuming task. It seems like the way
this is set up is due to the specifics of our how reviewing process is
implemented, so maybe there's no way around it.

Also, contrary to what ahal said, I don't know that tests being an official
requirement relieves the burden of guilt of asking for tests, as everybody
already knows that tests are good and that you should always write tests.
The situation is different from the linters, as the linters will fix almost
all issues automatically, so asking somebody to fix linter issues isn't
much of a burden at all. I guess it is impossible to make testing better
without somebody directly pressuring somebody, though.

My perspective might be a little distorted as I think a lot of the patches
I write would fall under the exceptions, either because they are
refactoring, or I am fixing a crash or security issue based on just a stack
trace.

Separately, one category of fixes I often deal with is fixing leaks or
crashes in areas of the code I am unfamiliar with. I can often figure out
the localized condition that causes the problem and correct that, but I
don't really know anything about, say, service workers or networking to
write a test. Do I need to hold off on landing until I can find somebody
who is willing and able to write a test for me, or until I'm willing to
invest the effort to become knowledgeable enough in an area of code I'm
unlikely to ever look at again? Neither of those feel great to me.

Another testing difficulty I've hit a few times this year (bug 1659013 and
bug 1607703) are crashes that happen when starting Firefox with unusual
command line or environment options. I think we only have one testing
framework that can test those kinds of conditions, and it seemed like it
was in the process of being deprecated. I had trouble finding somebody who
understood it, and I didn't want to spend more than a few hours trying to
figure it out for myself, so I landed it without testing. To be clear, I
could reproduce at least one of those crashes locally, but I wasn't sure
how to write a test to create those conditions. Under this new policy, how
do we handle fixing issues where there is not always a good testing
framework already? Writing a test is hopefully not too much of a burden,
but obviously having to develop and maintain a new testing framework could
be a good deal of work.

Anyways those are some disjointed thoughts based on my experience
developing Firefox that probably don't have good answers.

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

You can delete ipc/ipdl/ipdl/ipdl_lextab.py and ipdl_yacctab.py

[Andrew McCreight]

In case like me you've had these files staring back at you whenever you do
git status or whatever the equivalent is in hg, according to discussion in
bug 1630362, as of about May 7th you can delete these files and they won't
come back.

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecation notice - change to Treeherder's jobdetail API

[Andrew McCreight]

On Thu, Apr 9, 2020 at 6:51 PM Sarah Clements  wrote:

> Hello,
>
> As part of maintenance work and performance improvements to Treeherder,
> we're making changes to some of the data that's stored in our database. On 
> *April
> 30th*, we will no longer be retrieving uploaded artifacts for jobs and
> storing them in the JobDetail table.
>
> Uploaded artifacts can be retrieved via a taskcluster API, with the
> appropriate rootUrl, taskId and runId. TaskId and runId (synonymous with
> retryId in Treeherder) can be surfaced from any of our /jobs/ API's. See
> this
> 
> for implementation details.
>

As somebody who has dumped files to MOZ_UPLOAD_DIR and used the job detail
tab to download those files (just this week, in fact!), but has only a
vague idea of what the "taskcluster API" even is, let alone a "rootURL" or
the rest of it, is there any introductory documentation about how I might
retrieve files written to MOZ_UPLOAD_DIR? Am I going to have to write some
kind of Python script to retrieve my files in the future? That GitHub issue
seems to require a lot of background information that I do not have.


> We're also planning to deprecate the parsing and storage of TinderboxPrint
> log lines in the JobDetail table. They'll no longer be shown in
> Treeherder's job detail panel but you can still read them in the raw logs
> via the log-viewer.
>
> If you have any questions or concerns (or need a longer timeline to make
> changes that rely on this data), don't hesitate to reach out.
>
> Sarah
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Removing support for non-nsISupports XPIDL interfaces

[Andrew McCreight]

In times of old, you could declare an XPIDL interface that didn't inherit
from nsISupports, as long as it only had constants in it. I'm not sure why
it was really such a burden to make it inherit from nsISupports. Anyways,
it appears that our de-COM efforts have proceeded far enough that this
feature is not needed any more, so I am removing support for it in bug
1611173. If you do have such an interface, it will fail to compile. You
should be able to fix it by making the interface inherit from nsISupports.

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Finding windows and docshells leaked until shutdown

[Andrew McCreight]

On Wed, Oct 2, 2019 at 2:35 PM Geoff Lankow  wrote:

> Hi all, I need some advice.
>
> I'm trying to enable Mochitest on debug builds of Thunderbird. It works
> fine, except for the leak check, which finds a number of leaked windows
> and docshells. Obviously we don't want to leak these things, but I can't
> find what's holding onto them.
>
> I've ruled out a number of likely candidates and I'm quickly running out
> of ideas. Can you offer any tips or tricks that might help?
>
> Here's an example log:
>
> https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=267576044=try-comm-central=8051


What this leak checker means is that a docshell or window was created while
the test was running, but was not destroyed until after the test finished
(and we ran a bunch of GCs and CCs). However, these docshells and windows
don't show up in the leakcheck output, which means that they were cleaned
up before we shut down.

A typical cause for these is that there's some top level data structure,
often in JS but it could be in C++, too, that keeps track of every docshell
or window that is created, and does so by just adding a reference to it.
When we start shutdown, the data structure gets torn down, and we don't
leak things forever.

One small tip is that if you look at the line after the "leaked until
shutdown" message and you'll see something like this:
[task 2019-09-20T03:42:16.942Z] 03:42:16 INFO - TEST-INFO |
comm/calendar/test/browser/browser_calendarList.js | windows(s) leaked:
[pid = 1155] [serial = 38], [pid = 1155] [serial = 36], [pid = 1155]
[serial = 39], [pid = 1155] [serial = 37]

The entries like "[pid = 1155] [serial = 38]" are the descriptors we use
for windows (and docshells have a similar thing). If you search for "[pid =
1155] [serial = 38]" in the log, you can see where exactly each window was
created and destroyed. Sometimes that can give a hint about what is going
wrong.

Like Emilio said, the best approach to fixing these leaks is going to be
getting GC/CC logs from the point where it complains about the window being
alive, and then you can figure out from there what is keeping the window
alive, which may or may not point at what the leak is.

In practice, doing all of this leak fixing is rather a big project by
itself, so I'd recommend that you disable this leak checking in Thunderbird
somehow, and then just try to get the rest of the debug tests up and
running, and then maybe come back to it later. This leak checking is done
in this file (by doing postprocessing of the browser log):
testing/mochitest/leaks.py



>
> GL
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Documentation for IPDL needs some edit

[Andrew McCreight]

On Sat, Aug 10, 2019 at 7:15 AM  wrote:

> I have started to learn about IPDL and am reading IPDL Tutorial (
> https://developer.mozilla.org/en-US/docs/Mozilla/IPDL/Tutorial). It looks
> like the document is old and needs some edits, but this is an area I'm
> still learning so I want to make sure:
>

Yeah, unfortunately most of this documentation was written around 2010, and
it hasn't been updated to keep up with the changes that have happened in
the last 9 years. Probably the most direct way to see what the current
syntax is is to look at the IPDL parser code:
https://searchfox.org/mozilla-central/source/ipc/ipdl/ipdl/parser.py
You can look at the commit history of that file to find the bug numbers for
when things were removed and maybe get some context for that.


> 1. Nearly all of the examples lack explicit modifier before message names.
> AFAIK messages are required to have `async` or `sync` before them since Bug
> 1240871, am I right?
>
Yes, that is right.

>
> 2. The document says `rpc` shouldn't be used for general purpose but still
> the example in "Subprotocols and Protocol Management" section uses it for
> no explicit reason. I think it should use async instead as suggested, what
> do you think?
>

As you found in your followup message, this was replaced with some kind of
priority stuff. I don't remember the specifics.


> 3. `rpc` is mainly for NPAPI per the document, but NPAPI is dead. Why do
> we still need it?
>

NPAPI isn't dead quite yet. It is still used for Flash, which is going to
be supported for at least a few more years, if I remember correctly.


> Not sure this is the right place to discuss about documentations, if I
> posted to a wrong one please inform me.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Crash reports with Fission enabled are now indicated by DOMFissionEnabled = 1

[Andrew McCreight]

On Fri, Jul 5, 2019 at 7:50 PM Masatoshi Kimura 
wrote:

> On 2019/07/06 6:54, Andrew McCreight wrote:
> >> Here's an example of a crash report with DOMFissionEnabled:
> >>
> https://crash-stats.mozilla.org/report/index/dac0a91a-ad57-4446-9a82-505a80190705#tab-metadata
>
> I could not find `DOMFissionEnabled` in this crash report (although
> `DOMIPCEnabled` is found). Does it require some privileges due to
> privacy reasons?
>

I think crash report fields are hidden by default, so you may need crash
dump access to see it. I think it'll be made public as part of the Soccoro
bug I filed. Sorry about that.

Andrew

___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Crash reports with Fission enabled are now indicated by DOMFissionEnabled = 1

[Andrew McCreight]

On Fri, Jul 5, 2019 at 1:12 PM Andrew McCreight 
wrote:

> I landed bug 1560977 a few days ago, so you can now see in a crash report
> if Fission was enabled. If it was, the "meta data" tab will have a value of
> 1 for DOMFissionEnabled. The behavior is modeled after DOMIPCEnabled which
> indicates when e10s is enabled. There is no explicit indicator if Fission
> is not enabled. The field isn't indexed or whatever yet, but I've filed bug
> 1563317 for that.
>
> Here's an example of a crash report with DOMFissionEnabled:
> https://crash-stats.mozilla.org/report/index/dac0a91a-ad57-4446-9a82-505a80190705#tab-metadata
>

I should have mentioned that the first build with my change in it is
20190703094734,
so anything from a build before that without DOMFissionEnabled = 1 might
still have Fission enabled.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Crash reports with Fission enabled are now indicated by DOMFissionEnabled = 1

[Andrew McCreight]

I landed bug 1560977 a few days ago, so you can now see in a crash report
if Fission was enabled. If it was, the "meta data" tab will have a value of
1 for DOMFissionEnabled. The behavior is modeled after DOMIPCEnabled which
indicates when e10s is enabled. There is no explicit indicator if Fission
is not enabled. The field isn't indexed or whatever yet, but I've filed bug
1563317 for that.

Here's an example of a crash report with DOMFissionEnabled:
https://crash-stats.mozilla.org/report/index/dac0a91a-ad57-4446-9a82-505a80190705#tab-metadata
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

XPIDL interfaces with [notxpcom] methods or attributes must declare [builtinclass]

[Andrew McCreight]

I just landed bug 1550770 which makes it an error to have an XPIDL
interface with a [notxpcom] method or attribute that is not [builtinclass].
Previously, we would just silently make it builtinclass. The new approach
makes it easier to see if an interface is really builtinclass or not, but
if you have a patch in progress that adds a notxpcom thing then this might
break your patch, so be aware.

Here's the XPIDL documentation for anybody who hasn't seen it:
  https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XPIDL

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving our usage of Bugzilla

[Andrew McCreight]

On Tue, Mar 12, 2019 at 3:55 AM Sylvestre Ledru 
wrote:

> With this change, we are going to extend Bugzilla to add a new field with
> three new values:
>
>-
>
>Defect - an issue in one of our products
>-
>
>Enhancement - a new feature or an improvement
>-
>
>Task - a developer task. For example: refactor code foo.
>
>
Could please you explain more what these three values are supposed to
represent, possibly with some examples? It feels like there's a lot of
overlap between them. For instance, isn't any task I work on as a developer
a developer task? Isn't refactoring both a task and an improvement (and
thus also an enhancement)?

Maybe the idea is something like:
* Defect: the current implementation does not match the current intended
behavior, and the former should be changed to match the latter.
* Enhancement: the current intended behavior should be changed (and the
implementation changed to match the new intended behavior).
* Task: the current implementation should be changed, but the intended
behavior remains the same.

This breakdown is guided by what I remember of advice from I think David
Baron on how to structure a review: you need to review what a patch intends
to do (this being the "intended behavior" above), and also review whether
the patch actually does what it intends to do (this being the
"implementation" above). Maybe there's a better phrase than "intended
behavior".

Secondly, to bikeshed a little, could there be some name besides "task" for
that third category? Like I said above, everything we work as developers is
a developer task. "Refactor" seems like a clearer name, though maybe it is
a little limiting. "Side grade"? :)

Thirdly, what category should "organizational" bugs like meta bugs be
assigned to? I guess if you have a meta bug for a bunch of enhancements, it
would be an enhancement?

3) Adding a new field called “Regressed by”
>

This is great! The weird encoding of "regressed by" in the "depends on"
field is one of the more confusing aspects of Bugzilla, given how important
it is. I spend a ton of time setting regressions for bugs, and even still I
have to stop occasionally to make sure I'm doing it the right way.

Thanks,
Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What is future of editor mode-lines after the switch to clang-format?

[Andrew McCreight]

On Fri, Nov 30, 2018 at 10:00 AM  wrote:

> Now that all of mozilla-central is been migrated to use clang-format
> automated code formatting, the question of what should happen with editor
> modelines at the top of files should be considered.
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=clang-format
>
> Here are some options and some arguments I've heard. Please reply with
> further ideas or rationale. I've not classified points as pro/con and leave
> that up to the reader's interpretation.
>
> Option 1: Remove mode lines
>   - Devs are expected to run clang-format anyways (hopefully automated
> with a hook of sorts)
>   - Devs are free to set their modeline configuration elsewhere
>   - If they aren't providing value, they deserve to be removed.
>   - Many of these were already inconsistent/wrong, so this might be an
> opportunity to phase out
>   - Not all devs use vim/emacs, so we should think about workflows help
> that doesn't need stuff in every single source file.
>   - The editorconfig project (https://editorconfig.org/) aims to solve
> this for a variety of editors without marking each file
>
> Option 2: Fix mode lines
>   - A correct text-width mode-line gives a closer first approximation for
> devs
>   - Certain files (eg. moz.build, obj-C headers) use a non-standard file
> types.
>
> A hybrid of these is also very possible, such as removing certain
> attributes or only using when file type is non-standard.
>
> I had originally intended this discussion for js/ components, but it turns
> out to be a question across the whole tree (even if the solution chosen is
> per-module).
>

I don't know what the right answer is, but I'll mention (as I probably have
before) that I have a modeline fixing script that I've used before, and
that I could probably hack up to make whatever change. Though the heuristic
for fixing them will likely be different than I was using before to convert
them to the (former) standard Mozilla mode line (the script tried to guess
if the file was 2 space or 4 space indented).

https://github.com/amccreight/moz-source-tools/blob/master/modeline.py/


Andrew


> --Ted
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The upcoming C/C++ coding style change

[Andrew McCreight]

On Thu, Nov 29, 2018 at 8:44 AM Honza Bambas  wrote:

> OTOH, if the changes are only whitespace changes, maybe there is some
> way `patch --ignore-whitespace --fuzz N` could apply the patches.  Then
> just re-format and your patches are OK.
>

The changes that clang-format makes include things like moving a { to a
different line, which I believe ignore-whitespace doesn't recognize as a
whitespace only change, because it is across multiple lines, and things
like reflowing comment blocks to reduce their width to 80 characters, which
of course will also not be counted as whitespace only.

Andrew



>
> >* Do a one-time translation of your mq queue back to a series of
> patches.
>
> That doesn't make much sense, because the commit history will look
> something like (newest to oldest):
> - merge of my patches with the formatted changes, having two parents
> (formatted code default + my mq tip)
> - formatted code `tip` (or `default`)
> - my mq committed [ ]
> - pre-formated parent
> - ...
>
> You can't just recreate your mq from such changeset tree and you also
> can't avoid the likely quite complicated merge anyway.
>
> -hb-
>
> >
> > Cheers,
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: assignment between related nsCOMPtrs<> now works

[Andrew McCreight]

On Tue, Oct 2, 2018 at 9:33 AM Bobby Holley  wrote:

> This is awesome - great papercut fix. Thanks Andrew!
>
> Any chance of fixing it for RefPtr too?
>

That should already work:
https://searchfox.org/mozilla-central/rev/6ddb5fb144993fb5de044e2e8d900d7643b98a4d/mfbt/RefPtr.h#142



> On Tue, Oct 2, 2018 at 9:30 AM Andrew McCreight 
> wrote:
>
>> I've landed bug 1494765, which allows you to do assignments between
>> nsCOMPtrs for classes that are related by subtyping.
>>
>> For instance:
>>
>> class A { ... ];
>> class B : public A { ... };
>>
>> nsCOMPtr b = ...;
>> nsCOMPtr a = b; // this works now
>>
>> This is a step towards bug 1493226, which is going to statically ban
>> trivial do_QueryInterface calls like this:
>>
>> nsCOMPtr a2 = do_QueryInterface(b);
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

assignment between related nsCOMPtrs<> now works

[Andrew McCreight]

I've landed bug 1494765, which allows you to do assignments between
nsCOMPtrs for classes that are related by subtyping.

For instance:

class A { ... ];
class B : public A { ... };

nsCOMPtr b = ...;
nsCOMPtr a = b; // this works now

This is a step towards bug 1493226, which is going to statically ban
trivial do_QueryInterface calls like this:

nsCOMPtr a2 = do_QueryInterface(b);
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Enabling (many) assertions in opt builds locally and eventually Nightly

[Andrew McCreight]

On Wed, Sep 19, 2018 at 5:44 PM Kris Maglione  wrote:

> On Wed, Sep 19, 2018 at 05:37:46PM -0700, Bobby Holley wrote:
> >So, I don't think we need to do anything fancy with forking - we'd just
> >need to capture stacks and send them via telemetry rather than as a crash
> >report. This was the idea behind bug 1209131, which got pretty far along
> >but never made it to the finish line.
>
> This would actually potentially even give us better information
> than fork-and-crash, since we should be able to include JS
> stacks in that setup too. We've never been able to do that in
> ordinary crash reports, since breakpad doesn't know how to
> unwind JS stacks, and we can't safely ask the JS runtime to do
> it while we're crashing.
>

Though keep in mind that any stack that includes content JS is going to
likely count as PII, so it would have to be hidden by default on Soccorro.


> >On Wed, Sep 19, 2018 at 5:05 PM Randell Jesup 
> wrote:
> >
> >> >On Thu, Sep 20, 2018 at 09:22:12AM +1000, Cameron McCormack wrote:
> >> >> On Thu, Sep 20, 2018, at 1:52 AM, Ehsan Akhgari wrote:
> >> >> > While it may be the case that we may need to be more stable for
> >> >> > MOZ_RELEASE_ASSERTs, I very much doubt that every single MOZ_ASSERT
> >> in our
> >> >> > codebase is actually a guaranteed to never fail, so promoting them
> >> all to
> >> >> > be enabled in something like Nightly is extremely dangerous in
> terms
> >> of the
> >> >> > stability of Nightly for users who are trying to use the browser to
> >> get
> >> >> > their normal work done.
> >> >>
> >> >> If it's truly useful to know whether Nightly users are failing these
> >> >> MOZ_ASSERT assertions, we could use Telemetry to report their failure
> >> >> instead of crashing.>
> >> >> (I wonder if we could collect all the same data, and use the same
> crash
> >> reporting infrastructure, for non-crashing crash reports like this.)
> >> >
> >> >On Linux and Mac, we could make MOZ_ASSERT fork and crash in the child,
> >> >and continue in the parent process.
> >>
> >> Oooh, tricky.  (though threads aren't preserved in forks, but the
> >> current thread's stack is, so if we care about all threads, we might
> >> need to grab pointers to their stacks/etc and store pointers to the
> >> stacks before fork()).  But even without that it would be good.
> >>
> >> And yes, we don't have to have it crash the browser (though if it later
> >> crashes we'd want to know about assertions we'd hit).  Telemetry isn't
> >> quite appropriate for reporting it; it could however save a crash report
> >> at ASSERT(), then (probably) disable MOZ_ASSERT reports and let the
> >> browser continue (and it may well now really crash).  This disabling
> >> would avoid the cascade effect, but still get us crashreports.  This
> >> would be a bunch(?) of work in crashreporter - ted?  It might be easy
> >> invoke a crashreport sampling, and continue, but I suspect it's not, and
> >> might be quite hard.
> >>
> >> --
> >> Randell Jesup, Mozilla Corp
> >> remove "news" for personal email
> >> ___
> >> dev-platform mailing list
> >> dev-platform@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-platform
> >>
> >___
> >dev-platform mailing list
> >dev-platform@lists.mozilla.org
> >https://lists.mozilla.org/listinfo/dev-platform
>
> --
> Kris Maglione
> Senior Firefox Add-ons Engineer
> Mozilla Corporation
>
> Common sense is the collection of prejudices acquired by age 18.
> --Albert Einstein
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Web Replay landed in Firefox nightly

[Andrew McCreight]

On Sun, Jul 29, 2018 at 7:35 PM, Anthony Jones  wrote:

> I'm chuffed to announce that Web Replay has finally made its way into
> nightly. It brings tardis like functionality (or perhaps rr like) to
> Firefox Devtools, enabling recording and replaying of tab behavior, and
> best of all, stepping backwards and running backwards. This could be
> transformative for Web Developers using Firefox. For more detail you can
> watch Jason Laster's talk at JS conf[1], or see bug 1422587[2].
>
> The project has been a roller coaster of excitement, architectural concern
> and finally relief. We've now got something to try out, for SpiderMonkey
> devs to work around and for everyone to think about its impact. As with any
> work-in-progress, it has some caveats:
>
> * It is only supported on Mac
> * It is pref'ed off
> * It doesn't support certain web features, such as video playback
>
> For now it is considered tier-3 until we've got more information about how
> it fits into Firefox. Try to avoid regressing its functionality, but if you
> need to do so (to get your work done) then file a bug in the Web Replay
> component.
>
> It is still in as-is-where-is condition but you're welcome to try it
> out[3]. Please let me know your thoughts if you do.
>

It is linked from the bug, but just to make it easier to find: if you want
a fairly digestible overview of how it works, the wiki page for it is
pretty good.
  https://developer.mozilla.org/en-US/docs/Mozilla/Projects/WebReplay


Andrew


>
> Anthony
>
> [1] https://www.youtube.com/watch?list=PL37ZVnwpeshG2YXJkun_
> lyNTtM-Qb3MKa_continue=1327=rDq1AN1kSn4
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1422587
> [3] https://gist.github.com/jasonLaster/1e220992c294a571dd9b59abd084ccf2
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

[Andrew McCreight]

On Thu, Jul 12, 2018 at 3:57 AM, Emilio Cobos Álvarez 
wrote:

> Thanks for doing this!
>
> Just curious, is there a bug on file to measure excess capacity on
> nsTArrays and hash tables?
>
> WebKit has a bunch of bugs like:
>
>   https://bugs.webkit.org/show_bug.cgi?id=186709
>
> Which seem relevant.
>

njn looked at that kind of issue at some point (he changed how arrays grow,
for instance, to reduce overhead), but it has probably been around 5 years,
so there may be room for improvement for things added in the meanwhile.
However, our focus here is really on reducing per-process memory overhead,
rather than generic memory improvements, because we've had a lot of focus
on the latter as part of MemShrink, but not the former, so there's likely
easier improvements to be had.

Andrew


>  -- Emilio
>
> On 07/10/2018 08:19 PM, Kris Maglione wrote:
>
>> Welcome to the first edition of the Fission MemShrink newsletter.[1]
>>
>> In this edition, I'll sum up what the project is, and why it matters to
>> you. In subsequent editions, I'll give updates on progress that we've made,
>> and areas that we'll need to focus on next.[2]
>>
>>
>> The Fission MemShrink project is one of the most easily overlooked
>> aspects of Project Fission (also known as Site Isolation), but is
>> absolutely critical to its success. And will require a company- and
>> community-wide effort effort to meet its goals.
>>
>> The problem is thus: In order for site isolation to work, we need to be
>> able to run *at least* 100 content processes in an average Firefox session.
>> Each of those processes has its own base memory overhead—memory we use just
>> for creating the process, regardless of what's running in it. In the
>> post-Fission world, that overhead needs to be less than 10MB per process in
>> order to keep the extra overhead from Fission below 1GB. Right now, on our
>> best-cast platform, Windows 10, is somewhere between 17 and 21MB. Linux and
>> OS-X hover between 25 and 35MB. In other words, between 2 and 3.5GB for an
>> ordinary session.
>>
>> That means that, in the best case, we need to reduce the memory we use in
>> content processes by *at least* 7MB. The problem, of course, is that there
>> are only so many places we can cut memory without losing functionality, and
>> even fewer places where we can make big wins. But, there are lots of places
>> we can make small and medium-sized wins.
>>
>> So, to put the task into perspective, of all of the places we can cut a
>> certain amount of overhead, here are the number of each that we need to fix
>> in order to reach 1MB:
>>
>> 250KB:   4
>> 100KB:  10
>> 75KB:   13
>> 50KB:   20
>> 20KB:   50
>> 10KB:  100
>> 5KB:   200
>>
>> Now remember: we need to do *all* of these in order to reach our goal.
>> It's not a matter of one 250KB improvement or 50 5KB improvements. It's 4
>> 250KB *and* 200 5KB improvements. There just aren't enough places we can
>> cut 250KB. If we fall short in any of those areas, Project Fission will
>> fail, and Firefox will be the only major browser without site isolation.
>>
>> But it won't fail, because all of you are awesome, and this is a totally
>> achievable goal if we all throw our effort behind it.
>>
>> Essentially what this means, though, is that if we identify an area of
>> overhead that's 50KB[3] or larger that can be eliminated, it *has* to be
>> eliminated. There just aren't that many large chunks to remove. They all
>> need to go. And if an area of code has a dozen 5KB chunks that can be
>> eliminated, maybe they don't all have to go, but at least half of them do.
>> The more the better.
>>
>>
>> To help us triage these issues, we have a tracking bug (
>> https://bugzil.la/memshrink-content), and a per-bug whiteboard tag
>> ([overhead:...]) which gives an estimate of how much per-process overhead
>> we believe fixing that bug would eliminate. Please feel free to add
>> blockers to the tracking bug if you think they're relevant, and to add or
>> update [overhead] tags if you have reasonable estimates.
>>
>>
>> With all of that said, here's a brief update of the progress we've made
>> so far:
>>
>> In the past month, unique memory per process[4] has dropped 3-4MB[5], and
>> JS memory usage in particular has dropped 1.1-1.9MB.
>>
>> Particular credit goes to:
>>
>> * Eric Rahm added an AWSY test suite to track base content process memory
>>(https://bugzil.la/1442361). Results:
>>
>> Resident unique: https://treeherder.mozilla.org
>> 

Re: Fission MemShrink Newsletter #1: What (it is) and Why (it matters to you)

[Andrew McCreight]

On Wed, Jul 11, 2018 at 5:42 AM, David Bruant  wrote:

>
>
> * Andrew McCreight created a tool for tracking JS memory usage, and
>> figuring
>>   out which scripts and objects are responsible for how much of it
>>   (https://bugzil.la/1463569).
>>
> How often is this code run? Is there a place to find the daily output of
> this tool applied to a nightly build for instance?
>

You have to manually run this using a special build (hopefully I'll be able
to at least land code so that a special build is not needed). It isn't
clear from that description, but the focus here is on the chrome JS that is
part of the browser, rather than on websites. Reducing content process
chrome JS memory usage is going to have to be a big focus for this effort,
because I believe other browsers don't write their UI in JS, and the way
JIT stuff works it is harder to share code memory between processes than
with AOT compiled code.

If you look at about:memory, there's already a decent breakdown of how much
memory is used in JS for different things, but that doesn't help you figure
out which individual scripts are taking up memory. JSMs and content scripts
are run in only a few globals (to save memory), but that means that looking
up how much memory a global uses doesn't tell you much.


Andrew


> Thanks again,
>
> David
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Fwd: Bugs being resolved as INACTIVE

[Andrew McCreight]

For people who aren't subscribed to dev-firefox, be aware that open bugs
that haven't been modified in a year have been set to "inactive" without
any bugmail being generated, in bug 1445054. It is probably better to  that
thread rather than creating a new parallel thread on this list...

Andrew

-- Forwarded message --
From: Erin Lancaster 
Date: Thu, May 24, 2018 at 11:52 AM
Subject: Re: Bugs being resolved as INACTIVE
To: Marco Bonardo , Tom Ritter ,
Firefox Dev 
Cc: Emma Humphries 


Hi Everybody,

Emma is out for the next few days so I want to share some information in
the meantime. The spec of this "change" includes the following:

   1.

   Introducing an ‘Inactive’ state as a bug resolution in Bugzilla
   2.

   Moving tickets that haven’t been modified in 12 months to ‘Inactive’
   3.

   The query excluded P1 bugs and included Firefox-related products
   4.

   Why did we do this? To balance the signal:noise ratio in Firefox
   Bugzilla searches



   -

   If this mass-modify
    has disrupted
   your workflow to the point you need to a virtual ‘undo’ button, please file
   a ticket
   
and
   we will work with you to repair your workflow. Your bugs will be back to
   the ‘Active’ state as quickly as possible if that is what you require.
   Otherwise, we can evaluate what action is needed on a case-by-case basis.



   -

   The above changes were meant to improve the way we operate and did have
   support across the Firefox org; however, we totally missed the mark here by
   surprising you and mass-modifying without warning. For that we apologize
   and will be certain to not let that happen in the future.



   -

   We want to be more efficient with the way we work together and
   ‘together’ is one of key pieces of this. I’ll be collaborating with Emma to
   create a larger roadmap/plan of record to give people visibility into
   triage/Bugzilla policy and work flow changes so you are well informed
   before they happen.


We welcome your ongoing feedback and again apologize for the surprise.

Best,

Erin


On Thu, May 24, 2018 at 7:48 AM, Marco Bonardo  wrote:

> On Thu, May 24, 2018 at 4:34 PM, Tom Ritter  wrote:
>
>> I would :)  We have a lot of P5 bugs in Anti-Fingerprinting we'd like
>> to keep around. Granted, they aren't 1+ year old (yet) and they have
>> had some activity on them (so they might be considered 'triaged') but
>> yea, P5s would still be of interest I think.
>>
>
> Well, on the other side the new triage process requires each new bug to
> get a priority, and if we'd never resolve bugs having ANY priority, we'd
> never resolve anything. Untriaged, P4 and P5 importance is low enough to be
> good candidates to be automatically handled after 1 year. If they are
> active it's not a big deal. There could maybe still be a way to opt-out
> single bugs.
> My concern was mostly about the fact P1-3 are supposed to be important
> bugs that someone should be working on, and the fact we lack the resources
> to do that does not lower their importance.
>
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>

___
firefox-dev mailing list
firefox-...@mozilla.org
https://mail.mozilla.org/listinfo/firefox-dev
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Investigating leaks using DMD heap scan mode

[Andrew McCreight]

A few years ago I came up with an approach for using a combination of cycle
collector logs and DMD (which tracks all live blocks of heap allocated
memory) to investigate leaks of refcounted objects. I've only had to use it
about a half dozen times (most recently in bug 1451985), but it is very
handy when you have no other ideas. I think it is an easier-to-use
alternative to refcount logging in most situations.

Anyways, I've now written up the (many) steps involved in using it:
https://developer.mozilla.org/en-US/docs/Mozilla/Performance/DMD/Heap_Scan_Mode

Hopefully somebody else will find this useful. Feel free to ask me if you
have any questions about it.

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using WebIDL objects in XPIDL

[Andrew McCreight]

On Thu, Apr 19, 2018 at 12:53 PM, Gijs Kruitbosch 
wrote:

> Dumb question because I don't do this very often - sorry!
>
> I am intending to async-ify a sync JS-implemented idl-defined API (which
> currently returns an unsigned long), that has a few C++ consumers. I was
> thinking the simplest solution would be a separate method definition in the
> idl that took a separate interface (nsIFooCallback) that then got the long
> and/or any other data we needed to pass. This because returning a promise
> seems to previously have involved returning jsval and then things get more
> complicated from there. The only in-tree .idl uses I saw for Promise are in
> the wpt test idl files, which I presume don't reflect our ability to
> implement that as a return type.
>
> If I understand correctly, with these changes I could now just use Promise
> instead. Is that correct? Can I declare it including the resolution result
> of the promise, ie can I now use:
>
> Promise asyncGetFoo()
>
> in xpidl? Because that would make my life considerably easier...
>

Bug 1455217 by Nika is going to add a Promise type to XPIDL.  So I think
you have to wait for that.


> ~ Gijs
>
> On 19/04/2018 04:19, Nika Layzell wrote:
>
>> Yesterday, bug 1444991
>>  landed on inbound,
>> which adds support for using WebIDL defined objects directly inside of
>> XPIDL definition files.
>>
>> This allows us to avoid using nsISupports to pass WebIDL objects which
>> don't have corresponding XPIDL interfaces through XPIDL defined methods.
>>
>> WebIDL objects must be forward declared, like XPIDL types, in the .idl
>> file
>> which uses them:
>>
>>// C++ 'nsFrameLoader', from FrameLoader.webidl
>>webidl FrameLoader;
>>
>>// C++ 'mozilla::dom::DataTransfer', from DataTransfer.webidl
>>webidl DataTransfer;
>>
>> These types may then be used like XPIDL types in method and attribute
>> declarations. These types can be used from both C++ and JS code. They are
>> exposed into Rust as '*const ::libc::c_void`.
>>
>> - NIka
>>
>>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

XPT files shouldn't be added to package-manifest.in any more

[Andrew McCreight]

I recently landed bug 1438688, which makes it so that we don't ship XPT
files any more, so they don't need to be added to a package-manifest.in
file. (Instead, the XPT information is compiled into the binary.) I think
it'll give you an error if you add it anyways, but I haven't tested it. We
still use XPT files during the build process, so you'll see them appear in
your build log spam as usual.

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Most definitions of Ci, Cr, Cc, and Cu have been removed from the tree

[Andrew McCreight]

 Following up on my previous post, I have just landed (in bug 1432992) the
removal of most of the definitions of Ci, Cr, Cc, and Cu. This touched
almost 2000 files, so it may affect your patches, but hopefully rebasing is
easy. Thank you to Florian for reviewing a nearly-unreviewable patch and
suggesting a number of improvements, and to Raul and Aryx for shepherding
the patch's landing.

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Ci, Cr, Cc, and Cu are now automatically defined in all chrome scopes

[Andrew McCreight]

Bug 767640 just merged to mozilla-central. This patch makes it so that Ci,
Cr, Cc, and Cu are automatically defined in any chrome scope that has a
Components object. Rejoice, because you no longer need to add "var Ci =
Components.interfaces" into every file.

I have a followup bug, bug 1432992, that removes almost all of the existing
definitions of these variables.

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Announcing the next Extended Support Release of Firefox - ESR60 with policy engine

[Andrew McCreight]

On Wed, Jan 10, 2018 at 6:22 AM, Romain Testard  wrote:

> Some enterprises may indeed find that enabling site isolation is worth the
> trade-offs (memory usage seems to be the main one on Chrome's
> implemenation).
>

Just to be clear here, we do not support the same kind of site isolation
that Chrome does. Firefox has only just shipped multiprocess at all, and
Chrome has been working on site isolation for around 5 years, so it will
likely be a lot of work to support in Firefox.

Our current goal is to make sure enterprise users retain the same feature
> set with the next ESR and that we deliver a capability that allows easy
> integration of new policies and third party management tools. We'll be
> reaching out to enterprise users to collect feedback that should help
> prioritize our next features, right now it's it's pretty hard to assess how
> critical stronger security isolation is when compared to customization
> features we're considering in the medium term like the ability to disable
> printing.
>
> On Fri, Jan 5, 2018 at 7:09 PM, Gijs Kruitbosch 
> wrote:
>
> > On 04/01/2018 18:06, Tom Ritter wrote:
> >
> >> I am curious what Enterprise users are asking for.  I'd like to
> >> think/hope that a primary concern of enterprise is "Security" (or the
> >> separate topic of Privacy); but I'm not certain it is.
> >>
> >> In particular, I am curious if enterprise users would be interested in
> >> flipping preferences that would provide stronger security isolation at
> >> the cost of more resources (like process/memory).  This is basically
> >> what Chrome is providing with command-line flags for site isolation. A
> >> company can decide that domains of their choosing get allocated into
> >> per-origin processes, at the potential cost of a bunch of additional
> >> processes.
> >>
> >
> > Yes, in fact this (process-per-site) has specifically already come up on
> > the enterprise list in the last few days.
> >
> > ~ Gijs
> >
> >
> >> -tom
> >>
> >> On Thu, Dec 21, 2017 at 10:09 AM, Mike Kaply 
> wrote:
> >>
> >>> We currently do not plan to allow arbitrary preferences, but if certain
> >>> preferences are important, we can add policies for them.
> >>>
> >>> We could also add policies that set groups of preferences for specific
> >>> purposes.
> >>>
> >>> Mike
> >>>
> >>> On Thu, Dec 21, 2017 at 10:03 AM, Luke Crouch 
> >>> wrote:
> >>>
> >>> On Wednesday, December 20, 2017 at 9:42:50 AM UTC-6, Sylvestre Ledru
>  wrote:
> 
> > First, as Dave Camp mentioned during the Firefox All Hands, we are
> >
>  started some developments to improve
> 
> > our support for enterprise users.
> > More information can be found on the wiki: https://wiki.mozilla.org/
> >
>  Firefox/EnterprisePolicies
> 
>  The first example configuration.json I saw on the page only shows some
>  custom policy configs - e.g., bookmarks_on_toolbar, allow_popups_from,
>  etc.
> 
>  Will the policy config allow admins to set other/any about:config
> prefs
>  to
>  custom values?
> 
>  I'm thinking specifically it would be cool to let Enterprise+InfoSec
>  admins set some security + privacy about:config prefs to more hardened
>  defaults.
>  ___
>  dev-platform mailing list
>  dev-platform@lists.mozilla.org
>  https://lists.mozilla.org/listinfo/dev-platform
> 
>  ___
> >>> dev-platform mailing list
> >>> dev-platform@lists.mozilla.org
> >>> https://lists.mozilla.org/listinfo/dev-platform
> >>>
> >>
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Next year in web-platform-tests

[Andrew McCreight]

On Fri, Dec 15, 2017 at 9:38 AM, James Graham 
wrote:

> Following the summary of what we achieved in wpt in the last year, I'd
> like to solicit input from the gecko community to inform the
> priorities of various pieces of wpt work for the next year.
>
> In order to maximise the compatibility benefit we have two long term
> objectives for the web-platform-tests work at Mozilla:
>
> * Make writing writing web-platform-tests the default for all
>   web-exposed features, so that we only write unshared tests in
>   exceptional cases (e.g. where there is a need to poke at Gecko
>   internals).
>
> * Ensure that gecko developers are using the web-platform-tests
>   results to avoid interoperability issues in the features they
>   develop.
>
> Obviously we are some way from achieving those goals. I have a large
> list of things that I think will make a difference, but obviously I
> have a different perspective to gecko developers, so getting some
> feedback on the priorities that you have would be good (I know I have
> already have conversations with several people, but it seems good to
> open up the question to a broader audience). In particular
> it would help to hear about things that you would consider blockers to
> removing tests from non-wpt suites that are duplicated in wpt
> (assuming exact duplication), and limitations either in the
> capabilities of wpt or in the workflow that lead to you writing other
> test types for cross-browser features.
>

For me, a blocker to only having WPT is leak checking, both in terms of
XPCOM leak checking and LeakSanitizer. (The latter is probably going to
automatically work if you run them in ASan, but it would be good to check.)
I know there's a bug for XPCOM leak checking open already.


> Thanks
>
> (Note: I set the reply-to for the email version of this message to be
> off-list as an experiment to see if that avoids the anchoring effect where
> early replies set the direction of all subsequent discussion. But I'm very
> happy to have an on-list conversation about anything that you feel merits a
> broader audience).
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

new helper class to avoid leaks when using DOM promises in non-window-related data structures

[Andrew McCreight]

I just landed a patch for bug 1409115 that fixes a leak where a global data
structure (some per-process service worker queue) holds alive a DOM
promise, which ends up leaking the window forever. Fundamentally, holding
alive a DOM promise, which holds alive its window, from a data structure
that is not in turn held alive by the window is prone to leaking the
window, which leads to bad performance issues (both memory usage and speed).

To make this easier to avoid, I added a new class, PromiseWindowProxy, that
lets you use a promise in this way without having to worry about leaking.
It is a kind of weak reference, but it is strong enough to keep the promise
alive as long as the window and proxy are both alive.

If you know of any other places that might be using this problematic
pattern, please file bugs.

Here's my comment in the code that goes into a little more detail:

// When a data structure is waiting to resolve a promise from a//
window, but that data structure is not owned by that window, there//
exists a dilemma: 1) If the promise is never resolved, and the
non-window data// structure is keeping alive the promise, the
promise's window will// be leaked. 2) Something has to keep the
promise alive from native code in case// script has dropped all direct
references to it, but the promise is// later resolved.
PromiseWindowProxy solves this dilemma for the non-window data//
structure. It solves (1) by only keeping a weak reference to the//
promise. It solves (2) by adding a strong reference to the promise//
on the window itself. This ensures that as long as both the//
PromiseWindowProxy and the window are still alive that the promise//
will remain alive. This strong reference is cycle collected, so it//
won't cause the window to leak.

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Better triage for intermittent leaks in tests?

[Andrew McCreight]

I half-heartedly keep an eye on intermittent leaks, so I can more active in
looking at them. We'll need more logging for them to be actionable, but I
guess the high frequency ones are easier to catch.

Andrew


On Thu, Oct 26, 2017 at 10:20 AM, Geoffrey Brown  wrote:

> Some of our most troublesome intermittent test failures are leak bugs
> ("Intermittent LeakSanitizer | leak at ..." or "Intermittent leakcheck
> | default process:  bytes leaked ...") Even when they fail
> frequently, these bugs often seem to remain unresolved for many weeks.
> Leaks are sometimes not strongly associated with a particular test,
> making it difficult to assign to a useful bugzilla component, or find
> a motivated triage owner or assignee.
>
> I feel like these bugs are not being connected to the "right" people
> effectively. Could we do better?
>
> For instance, could we assign all leak bugs to a specific bugzilla
> component, with a "leak guru" as triage owner? Volunteers??
>
> - Geoff
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to require `mach try` for submitting to Try

[Andrew McCreight]

On Tue, Sep 19, 2017 at 8:49 AM, Eric Rescorla  wrote:

> Generally no, but this is an unfortunate consequence of Mozilla's decision
> a while ago to pick a VCS which has not turned out to be the dominant
> choice (not placing blame here, but I think it's clear that's how it's
> turned out). The result is that a lot of people want to use git and that
> means git needs to have a first class experience.
>

I've been using git for years now to develop Firefox, and I feel like it is
a first class experience. There's a one time cost to setting up cinnabar,
but after that, everything just works, including |mach try| and |mach
mozreview|. It is still probably less setup than Mercurial users have to go
through to install enough extensions to make hg usable. ;) Sure, there's a
bit of "wacky custom machinery", but developers using hg also have to deal
with some of that, so that's more of a Firefox developer problem than a git
Firefox developer problem.

Andrew



> -Ekr
>
>
> > Originals to end.
> >
> >
> > On Mon, Sep 18, 2017 at 5:16 AM, Eric Rescorla  wrote:
> >
> >> On Mon, Sep 18, 2017 at 2:56 AM, James Graham 
> >> wrote:
> >>
> >> > On 18/09/17 04:05, Eric Rescorla wrote:
> >> >
> >> > But that's just a general observation; if you look at this specific
> >> case,
> >> >>> it might not be much effort to support native git for richer/future
> >> try
> >> >>> pushing. But that's very different from requiring all the tools to
> >> >>> support
> >> >>> native git on an equal basis. And it seems reasonable to evaluate
> the
> >> >>> utility of this specific support via a poll, even one known to be
> >> biased.
> >> >>>
> >> >>>
> >> >> I don't think that's true, for the reasons I indicated above. Rather,
> >> >> there's a policy decision about whether we are going to have Git as a
> >> >> first-class thing or whether we are going to continue force everyone
> >> who
> >> >> uses Git to fight with inadequate workflows. We know there are plenty
> >> of
> >> >> people who use Git.
> >> >>
> >> >
> >> > I don't entirely understand what concrete thing is being proposed
> here.
> >> As
> >> > far as I can tell the git-hg parameter space contains the following
> >> points:
> >> >
> >> >  1. Use hg on the server and require all end users to use it
> >> >  2. Use git on the server and require all end users to use it
> >> >  3. Use hg on the server side and use client-side tooling to allow git
> >> > users to interact with the repository
> >> >  4. Use git on the server side and use client-side tooling to allow hg
> >> > users to interact with the repository
> >> >  5. Provide some server side magic to present both git and hg to
> clients
> >> > (with git, hg, or something else, as the on-disk format)
> >> >
> >> > These all seem to have issues relative to the goal of "vanilla git
> with
> >> no
> >> > custom code":
> >> >
> >> >  1. Doesn't allow git to be used at all.
> >> >  2. Requires a multi-year transition away from hg. Probably not
> popular
> >> > with hg fans.
> >> >  3. The status quo. Requires using a library for converting between hg
> >> and
> >> > git (i.e. cinnabar) or some mozilla-specific custom scripts (the old
> >> > moz-git-tools)
> >> >  4. Like 3. but with an additional multi-year transition and different
> >> > custom tooling.
> >> >  5. Allows vanilla git and hg on the client side, but requires
> something
> >> > complex, custom, and scary on the server side to allow pushing to
> either
> >> > repo. Could be possible if we eliminate ~all manual pushes (i.e.
> >> everything
> >> > goes via autoland), but cinnabar or similar is still there in the
> >> > background.
> >> >
> >>
> >> This is what I meant. And having something complex and scary on the
> server
> >> side is (at least to me) obviously better than having something complex
> >> and
> >>  scary (and did I mention constantly out of date) on the client side,
> >> because it's all in one place and externally just looks like the thing
> the
> >> client is expecting. Note that we already have half of this because we
> >> have
> >> one-way synching to gecko-dev on the server side. Perhaps one could also
> >> rip off some of the servo-gecko synching stuff here, but I don't know
> much
> >> about how that's architected.
> >>
> >>
> >> Given none of those options seem to fit, the only other possibility I
> can
> >> > think of is to skip the general problem of how to interact with the
> VCS
> >> for
> >> > try specifically by making submitting to try not look like a VCS push,
> >> but
> >> > like some other way of sending a blob of code to a remote machine
> (e.g.
> >> > using some process that generates a patch file). But unless there's
> some
> >> > extant way to achieve that it seems like it would be replacing
> >> > known-working code (cinnabar) with new custom code.
> >> >
> >>
> >> > So my best guess is that you mean that all pushes should go via
> autoland
> >> > and we should provide 

Re: Canonical cinnabar repository

[Andrew McCreight]

On Mon, Sep 18, 2017 at 7:05 AM, Kartikaya Gupta  wrote:

> I've tried using cinnabar a couple of times now and the last time I
> tried, this was the dealbreaker for me. My worfklow often involves
> moving a branch from one machine to another and the extra hassle that
> results from mismatched SHAs makes it much more complicated than it
> needs to be. gecko-dev doesn't have this problem as it has a canonical
> upstream that works much more like a regular git user expects.
>

For what it is worth, I regularly pull from one machine to another with
git-cinnabar, and it works just fine without any problems from mismatched
SHAs. For me, the switch from a clone of gecko-dev to git-cinnabar has been
totally transparent.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Incoming JS module (JSM) / component loader changes

[Andrew McCreight]

On Thu, Aug 31, 2017 at 11:14 AM, Kris Maglione <kmagli...@mozilla.com>
wrote:

> A quick heads-up on some incoming changes to the JS component loader that
> may affect some existing JSM or JS component code:
>
> 1) As of bug 1394556[1], all JS module and component scripts are
> automatically compiled in strict mode[2]. While I fixed all of the
> resulting issues that showed up in automated tests, new issues may turn up
> in code with incomplete test coverage. Please be on the lookout for errors
> like "TypeError: this is null", "TypeError: setting a property that has
> only a getter", and "ReferenceError: assignment to undeclared variable",
> and if you see any, file bugs blocking bug 1394556.
>
> 2) Andrew McCreight has been working on changing the component loader to
> load most modules and components into a single global[3], with each module
> still getting its own top-level variable scope (similar to a with() block).
> Most of the blockers for this have been resolved, and it should hopefully
> be ready to land within the next week.
>
> This change will significantly reduce the memory overhead of JS modules,
> along with the performance overhead of creating dozens module globals at
> startup, and of creating thousands of cross-compartment object wrappers at
> runtime.
> But it does so at the cost of decreased isolation among module scripts.
> All (non-add-on) modules will now share prototypes for built-in objects. It
> will be possible to define objects on the shared global that affect all
> modules. getGlobalForObject will no longer return the root scope for a
> module. In short, it's possible we will see subtle issues as a result of
> this change (as we often saw on b2g, which its module loader differed from
> the desktop module loader), so please be on the look-out over the next few
> weeks.
>

This has now landed on autoland, as part of bug 1381961.

Here are some notes on what to expect, written by Ted Campbell and Kris
Maglione:


Notes to JSM Authors

Your global vars, lets, consts, and |this| will now belong to a scope
within a shared JS global. JSMs will behave 99% unchanged.

The |(1,eval)(...)| and |new Function(...)| patterns now run in the context
of the shared global and are thus DEPRECATED. In future it is likely that
CSP will be used to deny all eval/Function usage.

The shared global namespace will become become polluted by
Cu.importGlobalProperties and WebIDL classes. If you need one of these
names, assume it isn't available and continue to load it normally. If you
define a variable in your JSM with the same name, yours will cover and so
you shouldn't worry.

Functions such as Cu.getGlobalForObject(...) will return the shared global
and should primarily only be used for compartment-related matters.

In the devtools debugger, you may see a scope labelled
|NonSyntacticVariablesObject|. This is the per-JSM environment and the
BackstagePass is the shared global.

There is an environment variable MOZ_LOADER_SHARE_GLOBAL=0/1 to control
enable/disable shared global support. This can be useful in certain testing
scenarios. The jsloader.shareGlobal pref exists in about:config as well and
only takes effect on restart.

You now share prototypes and constructors for built-in objects like Object,
Array, Function, ... with all other system JSMs. They don't belong solely
to you anymore. Do not add properties to them, or modify them in any other
way.

Beware using the subscript loader to load scripts into objects from other
JSMs. They'll be executed in the context of your pseudo-global scope. Also
beware of creating wrappers around the subscript loader that take a
non-global scope object, for the same reason. Their scopes will be
determined by the location of the loadSubScript call.


>
> Thanks.
>
> -Kris
>
> [1]: https://bugzil.la/1394556
> [2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe
> rence/Strict_mode
> [3]: https://bugzil.la/1186409
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Coding style question: Meaningless argument names in declarations

[Andrew McCreight]

On Thu, Sep 7, 2017 at 5:07 AM, Emilio Cobos Álvarez 
wrote:

> Hi,
>
> I have a coding style question which I don't see addressed in the coding
> style page.
>
> Given there have been a few threads lately on coding style, I guess I
> should just ask.
>
> We have a lot of meaningless argument names in function declarations, like:
>
>   void DoFoo(Element& aElement);
>
> Or:
>
>   enum class Operation {
>  // ..
>   };
>
>   void DoBar(Operation aOperation);
>
> I personally think those argument names are mostly noise (the type gives
> you the same information), and C++ allows omitting them.
>
> That would make the signature more concise, like:
>
>   void DoBar(Operation);
>
> Which is helpful specially in long signatures.
>
> I don't see anything mentioned in the style guide about this, should it be?
>

I don't know if it rises to the level of something that should be in the
style guide, but I find the names very useful as a form of lightweight
documentation. Sure, if you are naming your Foo arguments aFoo the names
aren't useful, but for many widely used types like JSObject* and bool
knowing whether the argument is the global or something else is very useful.


>  -- Emilio
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION_INHERITED is gone

[Andrew McCreight]

Just use NS_INTERFACE_MAP_BEGIN_CYCLE_COLLECTION instead.

These have been identical for years, so I just removed the _INHERITED
variant in an attempt to make the CC macros a little simpler to deal with,
in bug 1391005.

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving visibility of compiler warnings

[Andrew McCreight]

On Thu, May 25, 2017 at 4:03 PM,  wrote:

> On Friday, May 26, 2017 at 6:03:02 AM UTC+12, Chris Peterson wrote:
> > On 2017-05-25 5:31 AM, Ehsan Akhgari wrote:
> > > On 05/19/2017 02:44 PM, Gregory Szorc wrote:
> > >> `mach build` attempts to parse compiler warnings to a persisted
> > >> "database."
> > >> You can view a list of compiler warnings post build by running `mach
> > >> warnings-list`. The intent behind this feature was to make it easier
> to
> > >> find and fix compiler warnings. After all, something out of sight is
> > >> out of
> > >> mind.
> >
> > Given that we treat warnings as errors on CI and most directories that
> > opt out of warnings-as-errors are third-party code
> > (ALLOW_COMPILER_WARNINGS in moz.build [1]), I don't think we need to
> > make the warning list any more visible. A warning regression in nearly
> > all first-party code is already treated as an error.
> >
> >
> > [1]
> > https://searchfox.org/mozilla-central/search?q=ALLOW_
> COMPILER_WARNINGS=true=moz.build
>
> Tangentially: "we treat warnings as errors on CI" -- It'd be great if
> local builds could have that behavior by default, so we (or just I?) don't
> get caught by surprise when warnings-as-errors appear after landing.
>
> Or at least: Can I opt-in locally? (I tried 'ac_add_options
> --enable-warnings-ar-errors' in mozconfig, but that was not recognized.)
>

This has worked for me before:
ac_add_options --enable-warnings-as-errors


___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is it OK to make allocations that intentionally aren't freed?

[Andrew McCreight]

On Mon, May 22, 2017 at 4:45 PM, Karl Tomlinson <mozn...@karlt.net> wrote:

> Andrew McCreight writes:
>
> > On Fri, May 19, 2017 at 7:38 PM, Nicholas Nethercote <
> n.netherc...@gmail.com
> >> wrote:
> >
> >> There's also a pre-processor constant that we define in
> Valgrind/ASAN/etc.
> >> builds that you can check in order to free more stuff than you otherwise
> >> would. But I can't for the life of me remember what it's called :(
> >>
> >
> > NS_FREE_PERMANENT_DATA.
>
> I understand the need to clean up objects for
> NS_BUILD_REFCNT_LOGGING, but how important is this for objects not
> tracked with NS_BUILD_REFCNT_LOGGING, but only MOZ_VALGRIND and/or
> MOZ_ASAN?
>
> I thought I'd seen enough unfreed allocations that can be
> referenced from a root in static storage, that I assumed that
> valgrind and ASAN ignored these allocations in their leak report.
>

That is correct for LSan. I don't know how Valgrind reports leaks.

Is the inclusion of MOZ_VALGRIND and MOZ_ASAN in the value of
> NS_FREE_PERMANENT_DATA merely to make leak detection easier for
> valgrind and ASAN, or will such allocations be reported as leaks
> by these tools?
>

It will let you clean up things that are not referred to by static storage,
and change behavior in other ways that are needed for leak checking. For
instance, we do our shutdown CCs when it is defined, and disables the
timeout for shutting down a child process.

___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is it OK to make allocations that intentionally aren't freed? (was: Re: Is Big5 form submission fast enough?)

[Andrew McCreight]

On Fri, May 19, 2017 at 7:38 PM, Nicholas Nethercote  wrote:

> There's also a pre-processor constant that we define in Valgrind/ASAN/etc.
> builds that you can check in order to free more stuff than you otherwise
> would. But I can't for the life of me remember what it's called :(
>

NS_FREE_PERMANENT_DATA.

Please don't just cobble together your own, as this will work in all of the
various configurations we care about for leak checking, present and future,
without any further work.


Nick
>
> On Sat, May 20, 2017 at 5:09 AM, Jeff Muizelaar 
> wrote:
>
> > We use functions like cairo_debug_reset_static_data() on shutdown to
> > handle cases like this.
> >
> > -Jeff
> >
> > On Fri, May 19, 2017 at 1:44 AM, Henri Sivonen 
> > wrote:
> > > On Tue, May 16, 2017 at 7:03 AM, Tim Guan-tin Chien
> > >  wrote:
> > >> According to Alexa top 100 Taiwan sites and quick spot checks, I can
> > only
> > >> see the following two sites encoded in Big5:
> > >>
> > >> http://www.ruten.com.tw/
> > >> https://www.momoshop.com.tw/
> > >>
> > >> Both are shopping sites (eBay-like and Amazon-like) so you get the
> idea
> > how
> > >> forms are used there.
> > >
> > > Thank you. It seems to me that encoder performance doesn't really
> > > matter for sites like these, since the number of characters one would
> > > enter in the search field at a time is very small.
> > >
> > >> Mike reminded me to check the Tax filing website:
> > http://www.tax.nat.gov.tw/
> > >> .Yes, it's unfortunately also in Big5.
> > >
> > > I guess I'm not going to try filing taxes there for testing. :-)
> > >
> > > - -
> > >
> > > One option I've been thinking about is computing an encode
> > > acceleration table for JIS X 0208 on the first attempt to encode a CJK
> > > Unified Ideograph in any of Shift_JIS, EUC-JP or ISO-2022-JP, for GBK
> > > on the first attempt to encode a CJK Unified Ideograph in either GBK
> > > or gb18030, and for Big5 on the first attempt to encode a CJK Unified
> > > Ideograph in Big5.
> > >
> > > Each of the three tables would then remain allocated through to the
> > > termination of the process.
> > >
> > > This would have the advantage of not bloating our binary footprint
> > > with data that can be computed from other data in the binary while
> > > still making legacy Chinese and Japanese encode fast without a setup
> > > cost for each encoder instance.
> > >
> > > The downsides would be that the memory for the tables wouldn't be
> > > reclaimed if the tables aren't needed anymore (the browser can't
> > > predict the future) and executions where any of the tables has been
> > > created wouldn't be valgrind-clean. Also, in the multi-process world,
> > > the tables would be recomputed per-process. OTOH, if we shut down
> > > rendered processes from time to time, it would work as a coarse
> > > mechanism to reclaim the memory is case Japanese or Chinese legacy
> > > encode is a relatively isolated event in the user's browsing pattern.
> > >
> > > Creating a mechanism for the encoding library to become aware of
> > > application shutdown just in order to be valgrind-clean would be
> > > messy, though. (Currently, we have shutdown bugs where uconv gets used
> > > after we've told it can shut down. I'd really want to avoid
> > > re-introducing that class of bugs with encoding_rs.)
> > >
> > > Is it OK to create allocations that are intentionally never freed
> > > (i.e. process termination is what "frees" them)? Is valgrind's message
> > > suppression mechanism granular enough to suppress three allocations
> > > from a particular Rust crate statically linked into libxul?
> > >
> > > --
> > > Henri Sivonen
> > > hsivo...@hsivonen.fi
> > > https://hsivonen.fi/
> > > ___
> > > dev-platform mailing list
> > > dev-platform@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-platform
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Have you run 'mach bootstrap' lately?

[Andrew McCreight]

On Fri, May 12, 2017 at 11:34 AM, Ted Mielczarek  wrote:

> On Fri, May 12, 2017, at 10:45 AM, Sylvestre Ledru wrote:
> > Would it be possible to add a check like:
> > "You haven't updated your local configuration since XX days, please
> > consider running
> > mach bootstrap ?"
>
> We've had mach produce nag messages like that in the past and they have
> been universally disliked, FWIW.
>

Obviously it has less users, but moz-git-tools has a similar thing and I
find it handy and nobody has complained about it, AFAIK.

Andrew


> -Ted
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Fwd: Changes to code review tools and processes

[Andrew McCreight]

This was posted on mozilla.tools yesterday but doesn't seem to have made it
to dev.platform. It is likely to be of interest to many people on this
list. Note the comment "If you have questions or concerns beyond those
addressed below, please
use the mozilla.tools group and/or #phabricator on IRC and Slack to raise
them. " in the message

Andrew


-- Forwarded message --
Subject: Fwd: Changes to code review tools and processes

On Thursday, May 11, 2017 at 1:46:49 PM UTC-7, mc...@mozilla.com wrote:
>
> tl;dr Splinter and MozReview will be fully replaced by Differential,
> Phabricator’s code-review tool, in Q3.
>
>
> Why the change?
>
> Code review is a critical part of the Firefox engineering process but
> hasn’t changed much since Mozilla’s early days. Our home-developed
> tools have worked well for us but are increasingly dependent upon
> scarce resources to maintain, build and customize. Using our own tool,
> something that isn’t used by other organizations, also makes
> onboarding new people, staff and volunteers much more time-consuming
> than it needs to be.
>
> As with our decision to move forward with Project Dawn, this change is
> an investment we need to make now (so we get the benefits as soon as
> possible) to ensure the long-term health of Firefox. We are confident
> the short-term/immediate costs incurred—standing up a new tool, having
> to shift expectations and refactor workflows—will be more than paid
> back with surplus time and energy available for process automation
> (and later, with faster onboarding).
>
> If you have questions or concerns beyond those addressed below, please
> use the mozilla.tools group and/or #phabricator on IRC and Slack to
> raise them.
>
>
> ~ Laura Thomson & Mark Côté
>
> ===
> FAQs
>
> * Why did we choose Differential?
>
> Differential, originally developed at Facebook and currently used by
> many organizations, both open- and closed-source, has been trialled by
> several teams at Mozilla over the last few months. Although no code
> review tool is perfect, we believe it addresses several of the
> deficiencies in Review Board and is better suited to the Firefox
> engineering process. It is also an opportunity to decouple our
> automation pieces in order to focus on them after Differential’s
> launch, where we believe we will have a greater impact to Firefox
> development.
>
> * What will go out in the initial launch?
>
> 1. Deployment of a central Differential (code review) installation,
> supported by CloudOps, along with supporting tools like Diffusion
> (repository browser) and Herald (event-driven notifications). We will
> continue to use our Bugzilla instance, bugzilla.mozilla.org (aka BMO),
> for issue tracking for the foreseeable future.
>
> 2. Lightweight integration of Differential with BMO. This will include:
> - Authentication/identity.
> - Links from Differential revisions to BMO bugs.
> - Mirroring approvals (only) of Differential revisions back to BMO
> bugs as r+s on stub attachments, for record-keeping purposes. Aside
> from this, the code-review process will occur only in Differential to
> avoid fragmenting the discussion.
> - Security-group mapping to support reviews of security and otherwise
> confidential patches as seamlessly as possible.
> - Integration with and improvements to the Autoland service, which is
> currently used for around 50% of commits to mozilla-central and an
> integral part of the Quantum Stylo project.
>
> * What will happen to Splinter and MozReview?
>
> After a short trial period, MozReview will be shut down, and Splinter
> will be turned off for the main Firefox products on BMO: Core,
> Firefox, and Toolkit. Contribution guides and documentation will be
> updated to refer to Phabricator for code-change submissions. The exact
> archival procedures are will be figured out soon.
>
> * Will I be able to request customizations in Differential?
>
> We plan to limit customizations, but not to zero. We’re making this
> change (to using a third-party tool) to reduce the support burden on
> internal teams. The fewer customizations we make the more that
> happens. Any customizations will generally use Phabricator’s Conduit
> API; extensions will be limited to changes that are not possible to
> implement via the API. We have no intention of forking any Phabricator
> tools.
>
> * How will I get patches/commits up for review?
>
> We intend to keep the general Phabricator workflow, including use of
> the Arcanist command-line tool, although we will likely provide easy
> installation and some abstraction via mach and MozillaBuild.
>
> * Where will the flags for feedback/review/ui-review be?
>
> We’re going with the review flow built into Differential, which does
> not support multiple types of flags as Bugzilla’s attachment-flag
> system does. However, the actions that a reviewer can perform in
> Differential are more straightforward: rather than setting “r+” or
> “r-”, Differential’s options include “resign as 

Watch out for a rogue nsILayoutHistoryState.h

[Andrew McCreight]

I updated my tree this morning and did a build, and I ended up with a new
untracked
nsILayoutHistoryState.h file. Be sure to not accidentally commit it.

I deleted the file, and then had to do a clobber build to fix everything.

I filed bug 1351461 for the clobber issue or whatever it is.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

IPDL error/ unit tests now require a failure reason

[Andrew McCreight]

Note: this only affects you if you write tests in the
ipc/ipdl/test/ipdl/error/ directory.

In bug 1319620, I added checking of expected failures for IPDL error unit
tests. This will ensure that changes like renaming IPDL keywords won't make
the error tests silently start failing for the wrong reason.

Every test in error/ must contain one or more line starting with "//error:"
like the following:

//error: |manages| declaration in protocol `ForgottenManager' does not
match any |manager| declaration in protocol `ManageeForgot'

The stderr of the program must contain this output (minus the "//").
Multiple annotations are allowed, and all of them must be present in the
stderr.

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: e10s-multi update and tests

[Andrew McCreight]

On Wed, Mar 22, 2017 at 6:00 PM, Nicholas Nethercote  wrote:

> Do we have a clear definition of "content process"? I.e. does/will it
> include:
>
> - GMP processes (no?)
> - GPU process (probably not?)
> - file:// URL processes (probably should?)
> - Web Extensions processes (probably should?)
> - ServiceWorker processes (probably should?)
>

The most operational definition is that a content process is a process
where XRE_IsContentProcess() returns true. From the enum GeckoProcessType,
you can see the various other possibilities. So the answers to your
questions are then probably that GMP and GPU are not, but the others are.
Though maybe you are asking which processes count against the limit of 4.

Andrew


> Thanks.
>
> Nick
>
> On Thu, Mar 23, 2017 at 10:45 AM, Blake Kaplan  wrote:
>
> > Hello all,
> >
> > As some of you might have noticed, we are now defaulting to 4 content
> > processes on Nightly builds! We're continuing to collect data and
> > planning on running experiments with different numbers of processes to
> > generate more data and allow us to fine-tune our defaults and
> > strategies for process allocation.
> >
> > As part of our effort to enable e10s-multi on Nightly, we disabled a
> > few tests that were misbehaving. We've re-enabled most of them and are
> > on track to finish re-enabling them (after verifying that the problem
> > was in the test and not the underlying code).
> >
> > As we get to the end of that effort, I'd like to ask everybody to
> > think about any areas that they feel are not tested with multiple
> > content processes that should be. Obviously, as we find regressions
> > related to multiple content processes we'll add regression tests, but
> > I would like to avoid having any last-minute panics over missing
> > tests.
> >
> > Thanks.
> > --
> > Blake
> > ___
> > firefox-dev mailing list
> > firefox-...@mozilla.org
> > https://mail.mozilla.org/listinfo/firefox-dev
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

FYI: git-cinnabar and a "Intermittent IndexError: tuple index out of range" error

[Andrew McCreight]

If you are seeing this error when you try to do |git mozreview push|,
update your version-control-tools. Then you'll see a different error. Work
related to that is being looked at in
https://bugzilla.mozilla.org/show_bug.cgi?id=1338530

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please write good commit messages before asking for code review

[Andrew McCreight]

On Thu, Mar 9, 2017 at 1:55 PM, Nicholas Alexander 
wrote:

> On Thu, Mar 9, 2017 at 1:48 PM, Boris Zbarsky  wrote:
>
> > On 3/9/17 4:35 PM, Eric Rescorla wrote:
> >
> >> I'm in favor of good commit messages, but I would note that current m-c
> >> convention really pushes against this, because people seem to feel that
> >> commit messages should be one line.
> >>
> >
> > They feel wrong, and we should tell them so.  ;)  The first line should
> > include a brief summary of the change.  The rest of the commit message
> > should explain details as needed.
>
>
> Greg Szorc has been a vocal proponent of descriptive commit messages -- I
> consider https://bugzilla.mozilla.org/show_bug.cgi?id=1271035 a work of
> art
> -- and has converted many, including myself, to the cause.  I'm thrilled to
> see this practice get traction!
>

While that is certainly entertaining to read, personally I don't think it
is a great commit message. Anybody who wants to figure out what the patch
is actually doing and why it is doing it has to read through paragraphs
about barleywine to find that out.

On the subject of long commit messages, here's a commit message I wrote
that had 3 paragraphs to explain a patch that just changed a 0 to a 1:
https://hg.mozilla.org/integration/autoland/rev/bf059ec2bdc9
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: All the processes

[Andrew McCreight]

On Mon, Mar 6, 2017 at 4:45 PM, Eric Rahm  wrote:

> I'd suggest looking at the memory overhead of Chrome's individual processes
> as compared to ours, it's pretty impressive. My blog posts on our own e10s
> memory usage [1] and comparison to other browsers [2] have further details.
> I'm planning on performing the same measurements again to see how we do a
> year later with e10s-multi enabled (along with the GPU process, etc).
>

There's also been a big push in Chrome to reduce their memory usage, so
it'll be interesting to see how that affects things, too.


>
>
> > After that, of course for each machine there may be a limit we would want
> > to enforce, so this discussion here is still needed.
> >
>
> Sure, this is a harder number to nail down.
>
> -e
>
> [1]
> http://www.erahm.org/2016/02/11/memory-usage-of-firefox-with-e10s-enabled/
> [2] http://www.erahm.org/2016/02/12/are-they-slim-yet/
>
> Thanks,
> > Gerald
> >
> > On Tuesday, March 7, 2017 at 9:13:26 AM UTC+11, Nicholas Nethercote
> wrote:
> > ...
> > > Now for the reason I raised this: the major downside of using multiple
> > > processes is that it increases memory usage. Recent-ish measurements
> > showed
> > > that for e10s-multi we could probably go up to 4 content processes
> > without
> > > blowing it out too badly, but 8 would be a major problem.
> > ...
> > > Nick
> > >
> > >
> > >
> > > On Sat, Mar 4, 2017 at 11:15 AM, Nicholas Nethercote <
> > n.neth...@gmail.com
> > > > wrote:
> > >
> > > > Hi,
> > > >
> > > > I want to understand all the different processes that we can and will
> > have
> > > > in Firefox. Here's a list I constructed off the top of my head.
> > > >
> > > > - main process
> > > >
> > > > - content process(es): 1 on release for most users; 2 on Nightly
> > > >
> > > > - plugin process: just for Flash now?
> > > >
> > > > - gfx compositor process (bug 1264543, in Fx53)
> > > >
> > > > - file:// URL access process (bug 1147911, in Fx53)
> > > >
> > > > IIRC there was a proposal for a thumbnail generation process a while
> > back
> > > > but judging by bug 1187441 that was scrapped.
> > > >
> > > > Do I have any of these details wrong? Have I missed any?
> > > >
> > > > Thanks.
> > > >
> > > > Nick
> > > >
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: All the processes

[Andrew McCreight]

On Fri, Mar 3, 2017 at 4:15 PM, Nicholas Nethercote 
wrote:

> Hi,
>
> I want to understand all the different processes that we can and will have
> in Firefox. Here's a list I constructed off the top of my head.
>
> - main process
>
> - content process(es): 1 on release for most users; 2 on Nightly
>
> - plugin process: just for Flash now?
>
> - gfx compositor process (bug 1264543, in Fx53)
>

I think this is generally referred to as the "GPU process". One relevant
detail is that I believe it is Windows-only right now.


>
> - file:// URL access process (bug 1147911, in Fx53)
>
> IIRC there was a proposal for a thumbnail generation process a while back
> but judging by bug 1187441 that was scrapped.
>

I think in non-e10s a content process is used for thumbnail generation, but
it is run in the regular content process in e10s.


>
> Do I have any of these details wrong? Have I missed any?
>
> Thanks.
>
> Nick
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

IPDL support for spawns, opens, and bridges being removed

[Andrew McCreight]

In bug 1316755, I'm working on removing support for the IPDL keywords
spawns, opens and bridges. These have been superseded by endpoints, a more
general mechanism for starting up IPDL actors. The only drawback is that
endpoints don't allow for static analysis of the relationships between
processes, but it isn't clear how useful this analysis is.

I have patches up for review for removing all of the existing uses of these
in the tree. If you have any patches in progress that use any of these, you
can look at the patches in the bugs blocking 1316755 to see how to convert
them, or feel free to ask me for help. The changes are pretty mechanical.

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Runnable labeling for Quantum DOM

[Andrew McCreight]

On Thu, Dec 1, 2016 at 8:21 PM, Boris Zbarsky  wrote:

> If you want to get started before that, please make sure to
>> file a bug on what you're doing before you start. That should avoid
>> duplicating work.
>>
>
> Is there an overall tracking bug people could check to see which things
> are already filed or in-progress?
>

I filed bug 1321812 just now to use as a meta bug.



>
> -Boris
>
> P.S.  This is awesome.  ;)
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

removing about:bloat

[Andrew McCreight]

In bug 1308652, I'm planning on removing about:bloat. It disables XPCOM
leak tracking while it is running, so running it can cause false negative
leaks (bug 1271182). I don't think anybody uses it much any more, so I'm
going to remove it.

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Would "Core :: Debugging: gdb" be a good bugzilla component?

[Andrew McCreight]

You could also just file things like that in the corresponding component,
and maybe create some kind of meta bug for gdb hooks. So debugging for
nsTArray would be filed in XPCOM, etc. I think that's the way it works for
Javascript engine related debugging hooks. Failing that, having the nested
gdb inside Debugger seems like overkill given that no top level
Core::Debugger component exists right now. Maybe if in the future there's a
flood of gdb and lldb bugs it would be further subdivided.

On Fri, Sep 16, 2016 at 7:50 AM, Andrew Sutherland <
asutherl...@asutherland.org> wrote:

> Right now the gecko gdb pretty-printers have been tracked using bugs in
> "Core :: Build Config" because that's where the bug that first added them
> lived.  That component currently has 1773 bugs in it, 3 of which involve
> gdb, and with daily activity of ~10 bugs a day.  I think a more targeted
> component could be useful since gdb users could watch the component without
> getting the comparative fire hose of Build Config.  Right now notifications
> would need to come via explicit CC or watching for changes in dependencies
> of the existing bugs.
>
> The component would presumably cover not just the gdb pretty printers but
> also other gdb related issues.
>
> The triggering factor is that I made a foolish mistake with the
> nsTHashtable pretty-printer.  It has been telling lies, see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1303174 (fix on inbound,
> with apologies to anyone misled by the broken pretty-printer).
>
> Andrew
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Reorganization of Firefox-UI tests in mozilla-central

[Andrew McCreight]

On Fri, Sep 2, 2016 at 12:11 PM, Ryan VanderMeulen <rya...@gmail.com> wrote:

> On 9/2/2016 2:56 PM, Andrew McCreight wrote:
>
>> In DOM triage, we've just set up our list to not include bugs with the
>> keyword intermittent failure. Ideally, we'd see intermittent failures that
>> have a high rate, but given that sheriffs keep an eye on oranges, they can
>> look for somebody to fix frequent ones as needed.
>>
>
> I guess that explains why trunk's OrangeFactor is pushing 30 these days.


No, that is unrelated. We have only recently started systematically
triaging DOM bugs at all, so it isn't like we stopped triaging intermittent
oranges.


>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: mozilla/unused.h renamed to mozilla/Unused.h

[Andrew McCreight]

On Fri, Aug 26, 2016 at 8:16 PM, Gregory Szorc  wrote:

> What I'm trying to say is thank you for reminding me to implement the
> hook. And congratulations on likely being the last person to perform a case
> only rename on the repo.
>

Sarcastic commentary on an innocent mistake is not helpful.



> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Alternative to Bonsai?

[Andrew McCreight]

Searchfox works pretty well for blame including the CVS history, including
large files that github won't show you.

On Thu, Aug 25, 2016 at 12:09 PM, Philip Chee  wrote:

> On 16/09/2015 01:01, smaug wrote:
> > On 09/15/2015 06:53 PM, 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 for, in my experience), so it's of pretty limited use if
> >> you're trying to do the sorts of things you used to be able to do
> >> with bonsai.
> >>
> >> I believe gps is working on standing up a web front end for the CVS
> >> repo blame to replace bonsai...
> >
> > I guess that is unofficially http://52.25.115.98/viewvc/main/
>
> This is fine until I ran into a revision that said "Landed Aviary
> (browser part) which is just a very large diff. I remember MXR had an
> Aviary branch tree...
>
> Phil
>
> --
> Philip Chee , 
> http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
> Guard us from the she-wolf and the wolf, and guard us from the thief,
> oh Night, and so be good for us to pass.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Heads up: valgrind/memcheck issues

[Andrew McCreight]

We regularly run AddressSanitizer and Valgrind on mozilla-central, so it
seems likely this is Thunderbird specific. Please file security bugs in
bugzilla with any reports you have found.

Andrew

On Thu, Aug 25, 2016 at 10:59 AM, ISHIKAWA,chiaki 
wrote:

> Hi,
>
> I occasionally check C-C TB by running |make mozmill| test suite under
> valgrind/memcheck for detecting memory issues.
>
> I ran such a test the day before and saw a flurry of memcheck warnings
> which I did not see in the test that was run back on May 12th.
>
> So in three months between, some memory errors were introduced.
>
> I checked them briefly and saw many errors related to wrappers for
> getenv().
> But I also saw some other issues which seemed rather disturbing.
> I am tied with a big project with a day job and not sure if I can follow
> up on these issues in a timely manner before it is too late.
>
> If anyone occasionally checks C-C TB or M-C FF using valgrind/memcheck by
> running xpcshell tests and mozmill test in the case of C-C TB), I urge such
> people to do the tests NOW so that we can figure out which patch sets
> introduced such memory issues before it becomes difficult to figure out the
> culprit.
>
> To wit, the frequency and types of warnings from a partial log (partial
> since it takes more than 24 hours to run the test, I had to quit it
> halfway).
>
>  12Memcheck:Addr1
> 284Memcheck:Addr2
>   4Memcheck:Addr8
>  39Memcheck:Cond
>   1Memcheck:Param
>
> The number at the beginning of the line is the frequency of appearance in
> the log. (But do note that there are different errors reported under the
> same heading, Memcheck:Addr2, for example. This is disturbing enough since
> usually a known false positive often reports only the same code path.
>
> Yes, valgrind/memcheck can report false failures sometimes.
> But this time, the warnings are varied enough and some did look
> a problem like the access AFTER free (!) in one case. That should not be
> overlooked!!!
>
> TIA
>
> CI
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: mach and ccache failure?

[Andrew McCreight]

I'm not sure of the particulars, but I believe ccache doesn't share the
results between two object directories unless you set it up explicitly to
use relative paths. Or something like that.

https://ccache.samba.org/manual.html#_compiling_in_different_directories

On Fri, Aug 19, 2016 at 3:45 PM,  wrote:

> I'm currently trying to build two builds at once and place them in
> different directories based on MOZ_OBJDIR.
>
> So, I'm doing sth like this:
>
> 1) rm -rf ./obj1;rm -rf ./obj2;
> 1) set MOZ_OBJDIR=@TOPSRCDIR@/obj1
> 2) ./mach build
> 3) set MOZ_OBJDIR=@TOPSRCDIR@/obj2
> 4) ./mach build
>
>
> My full mozconfig looks like this:
>
> mk_add_options MOZ_MAKE_FLAGS="-j8"
> mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/obj1
> mk_add_options PYTHON=/usr/bin/python2
> ac_add_options --disable-debug
> ac_add_options --enable-optimize
> ac_add_options --enable-debug-js-modules
> ac_add_options --with-ccache=/usr/bin/ccache
>
> The first build finishes with:
>
> 46:48.98 ccache (direct) hit rate: 1.0%; (preprocessed) hit rate: 0.8%;
> miss rate: 98.2%
>
> The second build finishes with:
>
> 43:57.64 ccache (direct) hit rate: 0.8%; (preprocessed) hit rate: 0.9%;
> miss rate: 98.3%
>
> Both builds take around 43-46 minutes, with ccache hit rate 0.8-1.0%.
>
> This is the same source - mozilla-central from today.
>
> What am I doing wrong?
> zb.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Checkin-needed requests - Please include complete information in the commit message :)

[Andrew McCreight]

On Sun, Jul 10, 2016 at 7:29 PM, Martin Thomson  wrote:

> Is now the right time to start talking about retiring checkin-needed,
> or is it still heavily used?
>

It is useful for anybody who doesn't use MozReview. FWIW I see 14 bugs with
it set right now.






>
> On Sat, Jul 9, 2016 at 4:58 AM, Gregory Szorc  wrote:
> > On Fri, Jul 8, 2016 at 11:39 AM, Felipe G  wrote:
> >
> >> Is there a way to make the checkin-needed flag generate a template
> comment
> >> (like the approval-* ones do) with something like this? (Or encourage
> >> people to use the per-patch checkin? flag)
> >>
> >> """
> >> Has this patch been through try? [ Yes / No, I believe it's not
> necessary ]
> >> Does this patch contain the correct author / commit message? [ Yes
> >> (preferred) / No, but I'm providing it here: ]
> >> Are there any other dependencies that should be landed together? [ Yes,
> ...
> >> / No ]
> >> """
> >>
> >> Probably just asking if the information is present will reduce the
> number
> >> of requests made without it
> >>
> >
> > My knee jerk reaction is we shouldn't bother: MozReview handles most of
> > this "validation" and usage of MozReview has been steadily increasing.
> > We're trending towards a world where the only patches on Splinter are for
> > security-sensitive bugs (MozReview can't handle those yet) and the people
> > submitting patches to security bugs tend to know what they're doing so I
> > don't think these added checks will help.
> >
> >
> >>
> >> On Fri, Jul 8, 2016 at 10:47 AM, Ryan VanderMeulen 
> >> wrote:
> >>
> >> > FWIW, there's also an MDN page that documents a lot of this as well:
> >> >
> >> >
> >>
> https://developer.mozilla.org/en-US/docs/Mercurial/Using_Mercurial#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F
> >> >
> >> > -Ryan
> >> >
> >> >
> >> > On 7/8/2016 2:32 AM, Carsten Book wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> someone might not know that doing checkins for checkin-needed
> request is
> >> >> not automated yet and completely a fully human task :) (no we
> Sheriffs
> >> are
> >> >> not bots ;)
> >> >>
> >> >> It would help us a lot if a checkin needed request would contain
> >> complete
> >> >> Author/Patch information like:
> >> >>
> >> >>
> >> >>- Author (use the information from their Bugzilla account if
> needed)
> >> >>with Name *and *Emailadress.
> >> >>- Bug number
> >> >>- Commit message (keeping in mind that the commit message should
> be a
> >> >>brief description of what the patch is *doing*)
> >> >>   - Format should be something like "Bug 123456 - Add a null
> check
> >> to
> >> >>   XYZ to avoid a crash. r=somebody"
> >> >>
> >> >>
> >> >> And also if there is a specific sequence/dependency you want to
> checkin
> >> >> the
> >> >> patches it would help also a lot  if you could make a short comment
> in
> >> the
> >> >> Bug like please checkin part x then patch y or like first bug 123
> then
> >> >> this
> >> >> bug and then bug 8910.
> >> >>
> >> >> This would help us a lot :)
> >> >>
> >> >> Thanks!
> >> >>
> >> >> - Tomcat
> >> >>
> >> >>
> >> > ___
> >> > dev-platform mailing list
> >> > dev-platform@lists.mozilla.org
> >> > https://lists.mozilla.org/listinfo/dev-platform
> >> >
> >> ___
> >> dev-platform mailing list
> >> dev-platform@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-platform
> >>
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Gecko shutdown (London session)

[Andrew McCreight]

On Thu, Jun 30, 2016 at 8:41 AM, Aaron Klotz  wrote:

> Did the now-defunct exit(0) project ever come up in this discussion?
>
> See bugs 662444 and 826143. This was a perf team project back in the
> Snappy days where the objective was to write important data to disk ASAP,
> then exit(0) without doing a bunch of cleanup. The argument for this was
> that, yes, during development we want to make sure that we are properly
> cleaning up after ourselves, but there is no reason for end users with opt
> builds to be waiting around while Firefox spends a bunch of time destroying
> things that are going to be wiped anyway by process termination.
>

We already do _exit(0) in content processes in non-debug e10s,
in ContentChild::ActorDestroy(). A lot of the mess that Nicolas has had to
deal with in shutdown is in debug builds (see bug 1215265 and friends), so
exit(0) won't help with that.



>
> Aaron
>
>
> On 6/30/2016 2:49 AM, Nicolas Silva wrote:
>
>> Hi dev-platform,
>>
>> We had a session about shutdown problems during the London workweek. I
>> did a writeup of what was discussed and as it grew into a large-ish
>> piece, I put it in a wiki page (instead of the email I intended to send
>> initially) [1].
>> There's been a lot of work on reducing shutdown crashes/hangs
>> (especially with e10s) this year, but we still have a lot of work to do
>> [2].
>>
>> The page contains some discussions about the kinds of issues we ran into
>> in the gfx team and of how we went about addressing some of them. If you
>> are working on shutdown problems, you may (or may not) find useful
>> information in there. If you have some experience with dealing with
>> shutdown bugs, I encourage you to do a brain dump on that wiki page.
>>
>> There's also a two-phase shutdown proposal briefly described in there
>> [3], that is worth discussing because it would involve some cooperation
>> between different modules.
>>
>> Cheers,
>>
>> Nical
>>
>> [1] https://wiki.mozilla.org/Gecko:Shutdown_issues
>> [2]
>>
>> https://crash-stats.mozilla.com/search/?product=Firefox_progress=shutdown&_facets=signature&_columns=date&_columns=signature&_columns=version&_columns=build_id&_columns=platform&_columns=shutdown_progress#facet-signature
>> [3]
>> https://wiki.mozilla.org/Gecko:Shutdown_issues#Two-phase_shutdown_proposal
>>
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Notes about implementing DOM APIs in Rust

[Andrew McCreight]

On Wed, Jun 22, 2016 at 1:05 PM, Henri Sivonen  wrote:

> Now that I'm looking at the hand-written notes that I made in the
> meeting, I notice that the above paragraph fails to say how the
> AddRef, Release and associated cycle collection-related calls are
> routed from C++ to Rust or from Rust to C++. There was some talk about
> vtable hacks, but my recollection is that those got rejected along
> with XPCOM. So as far as I can tell, we are left with the meeting not
> concluding how exactly these calls across the language boundary.
>

C++ CCed objects don't even all use COM. Maybe the existing non-nsISupports
CC infrastructure could be used for Rust objects. If that doesn't work,
adding explicit support for Rust objects to the CC, like we have for JS,
doesn't seem like it would be too difficult. The CC used to nominally
support arbitrary languages.

Andrew



> (A remark of mine that was not discussed in the meeting and that I'm
> just adding onto the notes now as hopefully relevant to the last
> paragraph: If we don't want to hack vtables to make direct virtual
> calls between C++ and Rust, one way to use C linkage and FFI but still
> have the C++-side calls syntactically look like C++ method invocations
> that fit into existing C++-side smart pointers (etc.) is to interpret
> pointers returned from Rust as pointers to instances of a C++ class
> whose methods do nothing but call FFI functions with "this" as the
> first argument as seen in
>
> https://github.com/hsivonen/encoding-rs/blob/master/include/encoding_rs_cpp.h
> .)
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Top crash list is odd right now

[Andrew McCreight]

blassey landed a patch to suggest that users submit unsubmitted crash
reports. This is going to make various kinds of crashes, like shutdown
crashes, grossly overrepresented in the crash-stats "Top Crashers" list.
You probably want to use "By build date" instead of the default "By report
date" for the next week or so until that settles out.

Presumably the same thing will happen the first week or two of Aurora, on
that channel, and likewise with beta.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: All about crashes

[Andrew McCreight]

On Fri, Jun 3, 2016 at 6:57 AM, Ted Mielczarek  wrote:

> BugHunter[1] attempts to reproduce crashes from crash-stats by loading
> the URLs from the crash reports, which is sometimes successful.
>

Of note, BugHunter also uses both debug and AddressSanitizer builds, which
occasionally turns up some interesting stuff.

Andrew


>
> -Ted
>
> 1. https://wiki.mozilla.org/Auto-tools/Projects/BugHunter
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Andrew McCreight]

On Tue, May 31, 2016 at 7:14 PM, Nicholas Nethercote  wrote:

> If you use your favourite source code search tool to look for
> "Shutdown too long", you'll find that this crash is occurring in
> toolkit/components/terminator/nsTerminator.cpp. For example, here's a
> DXR link:
>

Sure, you can individually search for each assertion failure, but that's
not useful if you are just trying to skim the list looking for assertions
in code you are familiar with. The crash stack contains file information,
so it would be nice if that could be exposed somehow in a search. I don't
think you can do that right now, but I could be wrong.

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Andrew McCreight]

On Mon, May 30, 2016 at 11:22 PM, Nicholas Nethercote <
n.netherc...@gmail.com> wrote:

> 6  MOZ_RELEASE_ASSERT(pi->mInternalRefs < pi->mRefCount) (Cycle
> collector found more references to an object than its refcount)509
> 0.04 %
>

That's bug 1266882.

15 MOZ_RELEASE_ASSERT(aRefCount != 0) (CCed refcounted object has zero
> refcount)   113 0.01 %
>

That's odd. I'll file a bug on it.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: pushPrefEnv/popPrefEnv/flushPrefEnv now return Promises

[Andrew McCreight]

On Thu, May 19, 2016 at 4:09 PM, Matthew N.  wrote:

> As a reminder, the nice thing about pushPrefEnv is that the pref changes
> are reverted at the end of the test file which avoids them leaking into
> other tests unintentionally.
>

Another good thing about it is that set*Pref isn't actually synchronous in
the e10s content process, so you can end up with the pref not being set at
the right time. (IIRC the set pref sends a message to the parent telling it
to update the pref, but then continues running before the parent sends a
message back down to the child to actually set the child process pref.)

Andrew


> There are various places in the tree which wrote their own Promise
> wrappers for pushPrefEnv so feel free to file follow-up bugs blocking bug
> 1197310 to remove them.
>
> Cheers,
> Matthew N. (:MattN)
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1197310
>
> P.S. For those of you who didn't hear (since there was no announcement),
> you can use add_task in mochitest-plain and mochitest-chrome thanks to bug
> 1187701 if you load …/tests/SimpleTest/SpawnTask.js.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: IPCStream landed in mozilla-central

[Andrew McCreight]

On Thu, May 19, 2016 at 8:04 AM, Ben Kelly  wrote:

> 3) Supports async pipe streams using a new PSendStream actor from
> *child-to-parent*.  I have plans to add support for parent-to-child, but I
> don't have a consumer yet and we need to figure out some issues with
> PBackground targeting worker threads.
>

One place that this would be very useful would be for networking. Right
now, the various networking protocols send data to the child by calling
NS_ReadInputStreamToString(), then copying the string into an IPC message,
which is bad because it requires a lot of contiguous memory addresses, and
also has a fair bit of bloat from all of the copies (bug 1110596, bug
1263028).

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Updating 32-bit Windows users to 64-bit Windows builds?

[Andrew McCreight]

On Fri, May 13, 2016 at 1:02 PM,  wrote:

> Why do you developers keep insisting breathlessly that 64-bit builds are
> memory hogs? I'm a power user who has 3 windows and 1,565 tabs open. I have
> a 4 GB laptop and a 16 GB desktop replaced a 6 GB desktop. I like to think
> that I use Firefox close to its breaking point. On any given day, Firefox
> takes between 2.4 GB and 3.1 GB no matter whether it was the 32-bit build
> or is the 64-bit build. Only one time while I was using the 64-bit build
> did I notice it climb on its own all the way up to 5.9 GB, but then the
> memory was released and it settled down to 3.l GB again and, I repeat, that
> was only ONE TIME. Microsoft has a 64-bit version of Edge that I use. Also,
> I downloaded the 64-bit beta version of Google Chrome and use it with
> little problem compared to its 32-bit version. Under what I consider normal
> circumstances, I just don't see 64-bit versions eating memory like Mozilla
> developers keep insisting they do.
>

On 64-bit systems, pointers take 8 bytes of memory instead of 4. A lot of
the contents of memory is pointers. Thus a 64-bit build consumes more
memory for a given workload. It isn't as bad as, say, twice as much memory,
but it is enough that if you are close to the limits of your system it
could cause problems.

Andrew



>
> Now to be fair, I understand not wanting to put the 64-bit version of
> Firefox on low memory systems. I left the 32-bit version on my 4 GB laptop.
> I would personally say that x64 OS's with 6GB or more memory should be able
> to be upgraded to the 64-bit version of Firefox.  After NPAPI support goes
> away, there really should be no excuse to leave such systems on the 32-bit
> version as the 32-bit version doesn't take advantage of all of the 64-bit
> OS features and 64-bit processor's features. And as I have said previously,
> the 64-bit version is way more stable than the 32-bit version.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ignoring viewpoints of non-Mozilla-employees can't be the way to go for a OSS project!

[Andrew McCreight]

Thank you for opening a discussion thread rather than posting more in the
bug.

On Mon, May 9, 2016 at 11:23 AM, Tobias B. Besemer <
tobias.bese...@googlemail.com> wrote:

> Hi!
>
> Ignoring viewpoints of non-Mozilla-employees can't be the way to go for a
> OSS Project!
> The same mistake made Oracle with OpenOffice!
> Now the project is almost death!
> Think Mozilla should find his way back to his roots!
> Would be nice, if some people think about it!
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1114647
> I removed the marker that my comments are "Offtopic" ... (because I write
> my viewpoint to this topic!)
> ...and re-opened my attachment!
> Even if the employees are not interested how other OSS-Geeks see things
> that belong to the integration for Mozilla Products into Windows, this
> opinions of not-employees are anyway not "Offtopic", or "Spam"!
>

I did not mark your posts off topic because you are not a Mozilla employee,
I marked them off-topic (comments 144, 145, and 146) because they are not
relevant to the technical discussion in the bug. The subject of the
bug is "Rename
the content process to something intelligible". Your posts are talking
about extensions breaking with e10s, how you are fine with breaking
Silverlight and Flash, and saying that Windows breaks software. None of
these advance the state of the discussion in the bug.

Andrew


>
>
> Greets, Tobias.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Andrew McCreight]

Emma can correct me if I'm wrong, but I think she is using "Firefox" in the
non-jargony sense of the entire thing we're shipping in Firefox, including
Gecko. We've been using this system for a month or so in DOM. I think it
has been going well. Anybody who is interested can ask Andrew Overholt or I
for details.

Andrew

On Fri, Apr 8, 2016 at 10:52 AM, Douglas Turner  wrote:

> Emma,
>
> Thanks for doing this.
>
> I'm not sure whether something like this would work for platform
> engineering, but we'll keep an eye how things develop with Firefox and
> might consider it once we have some experience there.  I encourage you to
> report back here when Firefox starts using this system and has some lessons
> learned.
>
> I also want to thank all of the people that participated in this
> conversation.
>
> Doug
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Andrew McCreight]

On Fri, Apr 1, 2016 at 8:33 AM, Milan Sreckovic <msrecko...@mozilla.com>
wrote:

> Valid point.
>
> Being able to tell the status of “other team’s bugs” is critical for some
> number of people that look at bugs across all teams.  A number of
> directors, release management, I’m sure a sizeable number.  I would still
> guess a minor though; I know I am completely unaffected by the P’s and Q’s
> that the media team uses, and don’t care if they are different from what
> E10S is using.  And whatever they have seems to be working for them.
>
> If it is important for everything to be the same, we need to consider the
> multiplier.  For example, if it’s going to make life twice as easy for
> Lawrence (hi Lawrence), but make it 10% more difficult for all the
> developers - I’d say we shouldn’t do it.  If it’s going to let us have
> better decision making because we can extract some data out of bugzilla
> that we otherwise couldn’t, then we probably should do it (“it” = be
> consistent.)
>
> Sometimes we want to do things because it makes things clean and pretty.
> When that’s the only reason to do something, we should be cautious (it
> would be clean and pretty if everybody worked 9-5, and out of an office,
> right?).  If clean and pretty leads to better data, and that data is
> required and used for better decision making, different story.
>

It is also important for everybody who files a bug in a component handled
by a team they are not on. We obviously want people who are not on the,
say, graphics team to file graphics bugs. We should have some way to
indicate to these bug reporters what sort of priority their bug is being
treated as, in a way that they can understand.

Teams can spend a little bit of time learning to select "backlog" or
whatever instead of "P5", or they can spend time in every bug communicating
to reporters what "P5" means to their particular team. The former is more
efficient over all. Or we can have the status quo, where bugs that aren't
being actively worked on have a status that is just confusing to bug
reporters, which discourages people from filing more bugs.

Andrew



>
> —
> - Milan
>
>
>
> > On Apr 1, 2016, at 11:16 , Andrew McCreight <amccrei...@mozilla.com>
> wrote:
> >
> > On Thu, Mar 31, 2016 at 4:01 PM, Chris Peterson <cpeter...@mozilla.com>
> > wrote:
> >
> >> Anthony's Media Playback team has been using a simple and effective
> triage
> >> system without special tags. All open bugs in the Audio/Video Playback
> >> component are in one of four states at all times:
> >>
> >> * Priority P1 bugs should be fixed ASAP.
> >> * Priority P2 bugs are real bugs or features we want to fix soon.
> >> * Priority P5 bugs are "patches accepted" bugs.
> >> * Bugs without a priority are untriaged.
> >>
> >
> > The drawback of indicating priorities in this way is that it is totally
> > opaque to anybody who is not on that particular subteam, let alone
> somebody
> > who is using Bugzilla for the first time to report breakage on a site
> they
> > use. If this was marked "backlog" or whatever instead of "P5", and there
> > was a link to an explanation of what "backlog" meant, then it would make
> it
> > much easier for people to figure out what is going on in any bug. I think
> > that is a big advantage of the proposed triaging system, even though I
> > think it is reasonable for anybody to be skeptical of adding even more
> > bells and whistles to the Bugzilla interface.
> >
> > Andrew
> >
> >
> >> P3 and P4 are not used. :) P5 sends a pretty clear message to people
> that
> >> we will not fix that issue any time soon. However, the P5 list is pretty
> >> clean because we aggressively WONTFIX bugs we truly don't want to fix
> >> instead of letting them linger.
> >>
> >> Bugzilla already has a lot of fields. It seems like new workflows could
> be
> >> built with a streamlined frontend UI without changing Bugzilla's
> database
> >> schema. The advantage of codifying existing workflows instead of adding
> new
> >> fields is that existing bugs will be compatible with the new system.
> >>
> >> IIRC, the Fennec team also tracked the "Someone is working on this"
> >> proposed in Emma's plan by assigning owners to all bugs, but developers
> >> would change their bug's status from NEW to ASSIGNED only when they
> began
> >> actively working on the bug.
> >>
> >> ___
> >> dev-platform mailing list
> >> dev-platform@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-platform
> >>
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Plan for Firefox Components

[Andrew McCreight]

On Thu, Mar 31, 2016 at 4:01 PM, Chris Peterson 
wrote:

> Anthony's Media Playback team has been using a simple and effective triage
> system without special tags. All open bugs in the Audio/Video Playback
> component are in one of four states at all times:
>
> * Priority P1 bugs should be fixed ASAP.
> * Priority P2 bugs are real bugs or features we want to fix soon.
> * Priority P5 bugs are "patches accepted" bugs.
> * Bugs without a priority are untriaged.
>

The drawback of indicating priorities in this way is that it is totally
opaque to anybody who is not on that particular subteam, let alone somebody
who is using Bugzilla for the first time to report breakage on a site they
use. If this was marked "backlog" or whatever instead of "P5", and there
was a link to an explanation of what "backlog" meant, then it would make it
much easier for people to figure out what is going on in any bug. I think
that is a big advantage of the proposed triaging system, even though I
think it is reasonable for anybody to be skeptical of adding even more
bells and whistles to the Bugzilla interface.

Andrew


> P3 and P4 are not used. :) P5 sends a pretty clear message to people that
> we will not fix that issue any time soon. However, the P5 list is pretty
> clean because we aggressively WONTFIX bugs we truly don't want to fix
> instead of letting them linger.
>
> Bugzilla already has a lot of fields. It seems like new workflows could be
> built with a streamlined frontend UI without changing Bugzilla's database
> schema. The advantage of codifying existing workflows instead of adding new
> fields is that existing bugs will be compatible with the new system.
>
> IIRC, the Fennec team also tracked the "Someone is working on this"
> proposed in Emma's plan by assigning owners to all bugs, but developers
> would change their bug's status from NEW to ASSIGNED only when they began
> actively working on the bug.
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to enable e10s by default when running tests locally

[Andrew McCreight]

I have already filed bug 1255095 about this, as you are far from the first
person to be confused by this!

Andrew

On Thu, Mar 24, 2016 at 11:59 AM, Ehsan Akhgari <ehsan.akhg...@gmail.com>
wrote:

> On Thu, Mar 24, 2016 at 2:10 PM, Felipe G <fel...@gmail.com> wrote:
>
>> Yeah, --e10s enables e10s in the browser for mochitest-chrome.  However,
>> the test harness is a .xul file opened in a tab, and that runs that tab as
>> non-remote, so for most tests it ends up testing the same thing as not
>> using --e10s. Other tabs and/or windows opened manually by the test would
>> be remote.
>>
>
> D'oh, I have been working on this stuff and I didn't realize that's the
> case (I was operating as if a passing mochitest-chrome when run in e10s
> actually works with e10s).  That's extremely confusing.  :(  Should we
> refuse to accept --e10s when running mochitest-chrome to help avoid this
> confusion?
>
>
>>
>> On Thu, Mar 24, 2016 at 3:05 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com>
>> wrote:
>>
>>> On 2016-03-24 1:25 PM, Andrew McCreight wrote:
>>> > One potential sticking point is mochitest-chrome. It currently does not
>>> >> get run in e10s in CI, so local configuration should mirror this.
>>> >> However, since --e10s is being removed, this means it would be
>>> >> impossible to run mochitest-chrome in e10s without modifying source
>>> >> files. Maybe this just needs some argparse hackery.
>>> >>
>>> >
>>> > My impression was that mochitest-chrome doesn't actually run with e10s,
>>> > even when you specify the flag. Is that not correct?
>>>
>>> No.  You currently can force it to run in e10s with --e10s like other
>>> mochitest variants.
>>>
>>> ___
>>> firefox-dev mailing list
>>> firefox-...@mozilla.org
>>> https://mail.mozilla.org/listinfo/firefox-dev
>>>
>>
>>
>
>
> --
> Ehsan
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to enable e10s by default when running tests locally

[Andrew McCreight]

On Thu, Mar 24, 2016 at 9:15 AM, Andrew Halberstadt <
ahalberst...@mozilla.com> wrote:

> Bug 1243083 tracks enabling e10s by default when running tests locally.
> I intend to do this for as many harnesses as possible unless someone
> says otherwise.


Great!

[some text deleted]

One potential sticking point is mochitest-chrome. It currently does not
> get run in e10s in CI, so local configuration should mirror this.
> However, since --e10s is being removed, this means it would be
> impossible to run mochitest-chrome in e10s without modifying source
> files. Maybe this just needs some argparse hackery.
>

My impression was that mochitest-chrome doesn't actually run with e10s,
even when you specify the flag. Is that not correct?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Split Gecko in standalone fuzzing-friendly programs.

[Andrew McCreight]

On Wed, Mar 9, 2016 at 12:17 PM, Boris Zbarsky  wrote:

> Just to satisfy my curiosity, what is AFL?
>

AFL is American Fuzzy Lop, a fuzzer that uses a combination of compiled-in
code coverage and genetic algorithms. http://lcamtuf.coredump.cx/afl/ It
has found a ton of errors in all sorts of programs, but it requires pretty
deterministic behavior (eg so it can implicitly learn that tweaking the nth
bit will cause a different branch to be taken).



>
> but that still doesn't solve the problem that people have to write the
>> necessary code that we can fuzz then.
>>
>
> OK.  This is a problem, certainly, and pretty independent of both the
> "split Gecko" thing and the existence of shells, right?
>
> What are the necessary qualities for things you can fuzz?
>
> -Boris
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Status: ASan builds on Windows

[Andrew McCreight]

I'd also note that Google at least used to ship a similar kind of thing to
their Canary users a few times a week, called SyzygyASAN:

http://blog.chromium.org/2013/05/testing-chromium-syzyasan-lightweight.html

I haven't found a ton of detail about whether they still do it but that
blog post does say "In the last three weeks, we’ve found 150 new bugs in
Chromium, several of which could lead to security vulnerabilities."

We already have a couple of extra checks in Nightly, like compartment
checking assertions, that have turned up issues we would not have found
otherwise. Even a single report can sometimes identify an issue, and allow
us to fix it. So I would bet that having more people run builds with even
more checking will turn up things to fix.

Andrew

On Tue, Dec 15, 2015 at 6:36 AM, Nicolas B. Pierron <
nicolas.b.pier...@mozilla.com> wrote:

> Hi,
>
> 0/ Context
>
> As part of the JS engine a lot of issues which are reported on crash-stats
> are rarely actionable.  I personally waited a few times on equivalent
> fuzz-bugs, in hope to fix a crash-stat issue by luck.  One of the proposal
> we made in Orlando was to investigate if we could improve the reports that
> we get from crash-stats.
>
> Among the idea, was the idea to ship ASan builds to nightly users.
>
> This email is a summary of the problems which are blocking.  I also listed
> the persons involved in the discussion, and which might be contacted to
> help solving these issues.
>
> 1/ Would ASan be useful?
>
> While asking Bob Clary [:bc], he reported that even if he did not measure
> the effectiveness of ASan reports, he once noticed that an ASan bug got
> marked as a duplicate a of 12 non-ASan crashes.
>
> As Bob & Decoder mentioned, even if we do not ship ASan builds to users,
> we should at least use Windows ASan builds with Bughunter, and fuzzing
> automation.
>
> 2/ Current Blockers:
>
> 2.1/ Windows Clang ASan builds are not stable yet.
>
> Apparently we have a few issues opened against clang, and we should push
> these forward to make sure that we can have a stable build.  Part of the
> stability issues might be related to the way our build system is working as
> we are linking crt library both statically and dynamically inside Gecko.
>
> It seems that part of the issue might be related to the fact that Clang
> default to cl.exe when Clang fails at compiling, and a guess from Raymond
> was that we have ABI issues caused by a miss conversion of the command line
> arguments.
>
> If you are interested to talk more, or help fix clang issues, you should
> contact the following persons:
>
>  - Raymond Forbes [:rforbes]
>  - Nathan Froyd [:froydnj]
>  - Jeff Muizelaar [:jrmuizel]
>  - Ehsan Akhgari [:eshan]
>
> Also, we have few Clang contributors within Mozilla who might have a bit
> more knowledge about the persons to ask to get momentum on the clang
> issues, such as:
>
>  - Jakob Stoklund Olesen [:jolesen]
>  - Dan Gohman [:sunfish]
>
> And for our build system issues on Windows, we should contact:
>
>  - Mike Hommey [:glandium]
>
> 2.2/ Enable Crash reporter on ASan builds.
>
> The crash reporter is currently disabled on ASan builds, we need to figure
> out why, one hypothesis (I do not recall the author) was that we have
> issues with the SEGV handler.
>
> Another issue, is that the crash reporter does not capture the stderr
> stream.  Thus we might have to make additional patches to clang to give it
> the ability to spew the reports in a file, that we can later attach to the
> bug report.
>
> I don't know who is the right person, but I briefly discuss this issue
> with Ted Mielczarek [:ted].
>
> 2.4/ Soccoro interface to display multiple backtraces.
>
> Currently Soccoro only has support to display one backtrace.  On the other
> hand ASan builds might report 2 / 3 backtraces (allocation site,
> deallocation site / crash site).  We would have to extend Soccoro interface
> to be able to search for the different backtraces, such that we can make
> buckets of crashes which have identical allocation sites / deallocation
> sites.
>
> 2.5/ Release Management.
>
> ASan builds have a x2 overhead, and this implies that we have to ship
> different binaries, ASan is not a simple toggle (as far as I know).
>
> The performance impact is too high to ship ASan builds by default
> (Lawrence Mandel).  And as this implies that we have to ship a new version
> of Firefox, we would have to let people opt-in for a short while on nightly
> before making them fallback to the normal nightly, or suggest this ASan
> builds on supports.mozilla.org to investigate.
>
> The person to contact might be Sylvestre Ledru [:Sylvestre], based on
> Lawrence suggestion.
>
> --
> Nicolas B. Pierron
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org

Re: git-bz-moz and Bugzilla 2 factor authentication

[Andrew McCreight]

I have now updated the git-bz-moz and moz-git-tools repositories with my
REST API rewrite. Let me know if you have any problems or feedback (I'm
mccr8 on IRC). Thanks to everybody who gave me feedback, and to froydnj who
looked over the many patches.

Andrew

On Wed, Sep 23, 2015 at 1:49 PM, Andrew McCreight <amccrei...@mozilla.com>
wrote:

> I've updated my repository for my git-bz REST API branch:
>   https://github.com/amccreight/git-bz-moz/tree/RestAPI
>
> I think everything is fixed now, so please try it out and let me know if
> you encounter problems or something seems slow. (There's some initial
> caching thing that takes a while, but it should show a message and doesn't
> happen very often.) You have to set up an API key, but thanks to feedback
> from people it now spams your console with instructions on how to do that
> if you don't have one set.
>
> I removed |git bz edit --fix| and |git bz push|, as well as |git edit
> --pushed| though as far as I can tell the latter doesn't actually do
> anything. Hopefully nobody uses those given that we have Pulsebot.
>
> One nice feature of the new version (inherited with little effort by me
> from bzexport) is that if the user you have set for a r? etc. flag is
> ambiguous it will present a menu for you to select a user rather than just
> exiting immediately.
>
> I'll submit a pull request in the next few days to the main git-bz-moz
> repo in the next few days barring anybody finding some problems. Nathan
> Froyd has graciously offered to review this stack of 28 patches. (Though he
> volunteered before he knew it was that many patches.)
>
> The current set of patches copies over a few files from the
> version-control-tools repository. The next step will be to properly
> integrate those files, maybe via a subrepo, until git-bz-moz gets moved
> into that repo per gps's plan. [1]
>
> [1]
> https://groups.google.com/forum/#!topic/mozilla.dev.version-control/z9z9N7_vWiY
>
> Andrew
>
>
>
> On Tue, Sep 15, 2015 at 2:37 PM, Andrew McCreight <amccrei...@mozilla.com>
> wrote:
>
>> Apparently Bugzilla 2fa breaks the weird cookie authentication method
>> that git-bz-moz and bzexport use. I think I've read that this is a bugzilla
>> bug, but in the meanwhile I've been working on making git-bz-moz use the
>> Bugzilla backend of bexport, which is less hacky and supports using API
>> keys for authentication. Setting up an API key is extremely easy.
>>
>> If you want to try it out, it is available from my github repo here:
>>   https://github.com/amccreight/git-bz-moz/tree/RestAPI
>>
>> git bz edit and git bz push don't work, but the rest should, so please
>> file issues at https://github.com/mozilla/git-bz-moz or email me if you
>> notice them. (Oh, I think setting reviewer flags for Firefox product bugs
>> doesn't work, is a known issue.) The patches are still a little hacky and
>> probably don't cache as much as they should.
>>
>> Andrew
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: About static analyzers on some various projects

[Andrew McCreight]

On Thu, Sep 24, 2015 at 4:23 PM, Nicholas Nethercote  wrote:

> On Thu, Sep 24, 2015 at 2:29 PM, Ehsan Akhgari 
> wrote:
> > On 2015-09-24 1:41 PM, Sylvestre Ledru wrote:
> >>
> >> * Coverity, a proprietary tool with a great (but slow) web interface.
> >
> > Does anybody look at these regularly?  I would be interested to know if
> they
> > produce high quality results these days.  My past experience with
> Coverity
> > has been that it's full of false positivies.
>
> Eric Rahm looks at them regularly. He's on PTO until next week. From
> what he's told me the false positive rate is quite high, and the true
> positives are mostly small things like leaks on error paths, but
> occasionally it finds something significant. He's been looking at them
> for some time which suggests he thinks it's worth the effort.
>

I've described our Coverity results as a "good first bug generator". There
are a ton of little local things to fix.

One interesting analysis it has that I don't think we've taken advantage of
is that it reports when most, but not all, calls to a function have their
return value checked. In addition to indicating possible places where we
might need to do more checks, it also hints at functions that maybe should
have MOZ_WARN_UNUSED_RESULT added.


ps. "infer" uses separation logic, which happens to be a topic I know a bit
about, if anybody wants to know more about it.

Andrew


>
> Nick
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: git-bz-moz and Bugzilla 2 factor authentication

[Andrew McCreight]

I've updated my repository for my git-bz REST API branch:
  https://github.com/amccreight/git-bz-moz/tree/RestAPI

I think everything is fixed now, so please try it out and let me know if
you encounter problems or something seems slow. (There's some initial
caching thing that takes a while, but it should show a message and doesn't
happen very often.) You have to set up an API key, but thanks to feedback
from people it now spams your console with instructions on how to do that
if you don't have one set.

I removed |git bz edit --fix| and |git bz push|, as well as |git edit
--pushed| though as far as I can tell the latter doesn't actually do
anything. Hopefully nobody uses those given that we have Pulsebot.

One nice feature of the new version (inherited with little effort by me
from bzexport) is that if the user you have set for a r? etc. flag is
ambiguous it will present a menu for you to select a user rather than just
exiting immediately.

I'll submit a pull request in the next few days to the main git-bz-moz repo
in the next few days barring anybody finding some problems. Nathan Froyd
has graciously offered to review this stack of 28 patches. (Though he
volunteered before he knew it was that many patches.)

The current set of patches copies over a few files from the
version-control-tools repository. The next step will be to properly
integrate those files, maybe via a subrepo, until git-bz-moz gets moved
into that repo per gps's plan. [1]

[1]
https://groups.google.com/forum/#!topic/mozilla.dev.version-control/z9z9N7_vWiY

Andrew



On Tue, Sep 15, 2015 at 2:37 PM, Andrew McCreight <amccrei...@mozilla.com>
wrote:

> Apparently Bugzilla 2fa breaks the weird cookie authentication method that
> git-bz-moz and bzexport use. I think I've read that this is a bugzilla bug,
> but in the meanwhile I've been working on making git-bz-moz use the
> Bugzilla backend of bexport, which is less hacky and supports using API
> keys for authentication. Setting up an API key is extremely easy.
>
> If you want to try it out, it is available from my github repo here:
>   https://github.com/amccreight/git-bz-moz/tree/RestAPI
>
> git bz edit and git bz push don't work, but the rest should, so please
> file issues at https://github.com/mozilla/git-bz-moz or email me if you
> notice them. (Oh, I think setting reviewer flags for Firefox product bugs
> doesn't work, is a known issue.) The patches are still a little hacky and
> probably don't cache as much as they should.
>
> Andrew
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: git-bz-moz and Bugzilla 2 factor authentication

[Andrew McCreight]

On Thu, Sep 17, 2015 at 6:50 AM, Ehsan Akhgari 
wrote:

> git bz edit and git bz push don't work, but the rest should, so please file
>> issues at https://github.com/mozilla/git-bz-moz or email me if you notice
>> them. (Oh, I think setting reviewer flags for Firefox product bugs doesn't
>> work, is a known issue.) The patches are still a little hacky and probably
>> don't cache as much as they should.
>>
>
> Hmm, I thought <
> https://github.com/mozilla/git-bz-moz/commit/4bdde9d270ff72f1a06943306b558dab29f2a3f7>
> had fixed setting the reviewer flags for Firefox product bugs.  Does that
> not work?
>


The method of setting multiple flags didn't seem to work with the REST API.
I was planning on following what bzexport does, which is query the server
for those flag values for the given product.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: easily getting allocation stacks for leaking objects

[Andrew McCreight]

On Thu, Sep 17, 2015 at 5:31 AM, Gerald Squelart  wrote:

> Good stuff!
>
> I hope you'll consider tracking AddRef's and Release's as well.
>
> I recently experimented with that for a troubled RefCounted class [1], and
> it was very useful to find which AddRef didn't have its corresponding
> Release.
>

There's already refcount logging for this:
  http://www-archive.mozilla.org/performance/refcnt-balancer.html

It is generally too spammy to include in the TreeHerder log, but it can be
useful.

Andrew



>
> Cheers,
> Gerald
>
> [1] https://hg.mozilla.org/try/rev/8dffaf0d2acf
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: easily getting allocation stacks for leaking objects

[Andrew McCreight]

On Thu, Sep 17, 2015 at 7:42 AM, Andrew McCreight <amccrei...@mozilla.com>
wrote:

>
>
> On Thu, Sep 17, 2015 at 5:31 AM, Gerald Squelart <squel...@gmail.com>
> wrote:
>
>> Good stuff!
>>
>> I hope you'll consider tracking AddRef's and Release's as well.
>>
>> I recently experimented with that for a troubled RefCounted class [1],
>> and it was very useful to find which AddRef didn't have its corresponding
>> Release.
>>
>
> There's already refcount logging for this:
>   http://www-archive.mozilla.org/performance/refcnt-balancer.html
>
>
Olli points out that I should actually link to the more modern page for
this:

https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Refcount_tracing_and_balancing

Anybody who wants help with refcount logging should feel free to get in
touch with me and I can help walk them through it.


> It is generally too spammy to include in the TreeHerder log, but it can be
> useful.
>
> Andrew
>
>
>
>>
>> Cheers,
>> Gerald
>>
>> [1] https://hg.mozilla.org/try/rev/8dffaf0d2acf
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: git-bz-moz and Bugzilla 2 factor authentication

[Andrew McCreight]

Sorry, the command is actually |git bz apply 12345| as you probably figured
out.

Andrew

On Tue, Sep 15, 2015 at 2:40 PM, Andrew McCreight <amccrei...@mozilla.com>
wrote:

> Oh, and another thing I meant to mention that seems underused: if you are
> using git-bz-moz, the |git apply| command is pretty handy. You can do |git
> apply 12345| where 12345 is a bug number, and it will prompt you for each
> non-obsolete patch attachment and apply it if you want it.
>
> Andrew
>
> On Tue, Sep 15, 2015 at 2:37 PM, Andrew McCreight <amccrei...@mozilla.com>
> wrote:
>
>> Apparently Bugzilla 2fa breaks the weird cookie authentication method
>> that git-bz-moz and bzexport use. I think I've read that this is a bugzilla
>> bug, but in the meanwhile I've been working on making git-bz-moz use the
>> Bugzilla backend of bexport, which is less hacky and supports using API
>> keys for authentication. Setting up an API key is extremely easy.
>>
>> If you want to try it out, it is available from my github repo here:
>>   https://github.com/amccreight/git-bz-moz/tree/RestAPI
>>
>> git bz edit and git bz push don't work, but the rest should, so please
>> file issues at https://github.com/mozilla/git-bz-moz or email me if you
>> notice them. (Oh, I think setting reviewer flags for Firefox product bugs
>> doesn't work, is a known issue.) The patches are still a little hacky and
>> probably don't cache as much as they should.
>>
>> Andrew
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: git-bz-moz and Bugzilla 2 factor authentication

[Andrew McCreight]

Oh, and another thing I meant to mention that seems underused: if you are
using git-bz-moz, the |git apply| command is pretty handy. You can do |git
apply 12345| where 12345 is a bug number, and it will prompt you for each
non-obsolete patch attachment and apply it if you want it.

Andrew

On Tue, Sep 15, 2015 at 2:37 PM, Andrew McCreight <amccrei...@mozilla.com>
wrote:

> Apparently Bugzilla 2fa breaks the weird cookie authentication method that
> git-bz-moz and bzexport use. I think I've read that this is a bugzilla bug,
> but in the meanwhile I've been working on making git-bz-moz use the
> Bugzilla backend of bexport, which is less hacky and supports using API
> keys for authentication. Setting up an API key is extremely easy.
>
> If you want to try it out, it is available from my github repo here:
>   https://github.com/amccreight/git-bz-moz/tree/RestAPI
>
> git bz edit and git bz push don't work, but the rest should, so please
> file issues at https://github.com/mozilla/git-bz-moz or email me if you
> notice them. (Oh, I think setting reviewer flags for Firefox product bugs
> doesn't work, is a known issue.) The patches are still a little hacky and
> probably don't cache as much as they should.
>
> Andrew
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

git-bz-moz and Bugzilla 2 factor authentication

[Andrew McCreight]

Apparently Bugzilla 2fa breaks the weird cookie authentication method that
git-bz-moz and bzexport use. I think I've read that this is a bugzilla bug,
but in the meanwhile I've been working on making git-bz-moz use the
Bugzilla backend of bexport, which is less hacky and supports using API
keys for authentication. Setting up an API key is extremely easy.

If you want to try it out, it is available from my github repo here:
  https://github.com/amccreight/git-bz-moz/tree/RestAPI

git bz edit and git bz push don't work, but the rest should, so please file
issues at https://github.com/mozilla/git-bz-moz or email me if you notice
them. (Oh, I think setting reviewer flags for Firefox product bugs doesn't
work, is a known issue.) The patches are still a little hacky and probably
don't cache as much as they should.

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fingerprinting of battery status?

[Andrew McCreight]

On Tue, Aug 4, 2015 at 9:33 AM, Jonas Sicking jo...@sicking.cc wrote:

 Fingerprinting doesn't seem useful if the fingerprint changes every
 few minutes as the battery level changes.

 I do agree that there are concerns that if the user has
 private-browsing pages and non-private-browsing pages open at the same
 time, that the pages can track when exactly the battery level changes
 and thereby figure out which user is using the private browsing
 window.

 So disabling the API, or fudging its return values, in private
 browsing windows sounds like a good idea. The same applies to features
 like device orientation, proximity/light sensors, network information
 (wifi vs. mobile etc), device orientation and probably a few more.


Another example of this is the Chrome memory API, that lets a page read out
how much memory it is using (I think how much the current Chrome process is
using, in practice). My understanding is that they quantize the reading,
and also only take a new reading occasionally (every few minutes maybe?).



 / Jonas


 On Mon, Aug 3, 2015 at 12:55 PM, Chris Peterson cpeter...@mozilla.com
 wrote:
  What is a legitimate use case for a web page to know my battery status?
  Battery level and time remaining can be used to fingerprint users.
 
  A mobile webapp might use battery level to throttle its activity, but
 that
  could be something the OS handles by pausing or throttling apps directly
 or
  broadcasting app lifecycle events. I can't think of a good reason why a
 web
  page in a browser, especially on a desktop OS, needs to know anything
 about
  my battery.
 
 
 http://www.theguardian.com/technology/2015/aug/03/privacy-smartphones-battery-life
 
  http://eprint.iacr.org/2015/616.pdf
 
 
  chris
  ___
  dev-platform mailing list
  dev-platform@lists.mozilla.org
  https://lists.mozilla.org/listinfo/dev-platform
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Linux builds now default to building with Gtk+3

[Andrew McCreight]

Just so people know, ASan builds with GTK3 crash immediately on startup, so
you'll want to keep the gtk2 version as described below.

Andrew

On Wed, Jul 22, 2015 at 6:38 PM, Mike Hommey m...@glandium.org 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 have switched to Gtk+3.

 - As of now on mozilla-inbound, and later on other branches, local
   Linux (and other non-OSX unices) builds default to Gtk+3.

 - You will need to install Gtk+3 development files to do those local
   builds. `mach bootstrap` should be able to do this for you.

 - You can still do Gtk+2 builds by adding the following to your
   mozconfig:
 ac_add_options --enable-default-toolkit=cairo-gtk2

 - You can still do Gtk+2 try builds by removing the gtk3.tar.xz entries
   in browser/config/tooltool-manifests/linux*/releng.manifest.

 - The Gtk+3 builds that were available on the elm branch will
   auto-update to normal nightlies in the next few days.

 - I will switch elm to do Gtk+2 builds, to ensure they don't break in
   the near future. I'm not sure how long I will keep that running.

 Big kudos go to, as far as I know, Andrew Comminos, for fixing all the
 remaining reds and oranges on the Gtk+3 build and allowed to make this
 possible. And to all the people involved in making the Gtk+3 port work
 in the first place.

 Cheers,

 Mike
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New requirement for tier 1 platforms: working assertion stacks

[Andrew McCreight]

Are we going to have tests for this? Does working include being properly
symbolicated?

But yes, it is extremely annoying to have failures without stacks. (See bug
1165469, which was only figured out once somebody reproduced the test
locally, because there was no stack.)

On Fri, Jul 10, 2015 at 9:58 AM, Kyle Huey m...@kylehuey.com wrote:

 Any reason not to require this?

 - Kyle
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Announcing the Content Performance program

[Andrew McCreight]

On Sun, Jun 28, 2015 at 7:55 PM, Vladan D vdje...@mozilla.com wrote:

 I asked Avi to work on pausing GC/CC during scrolling in Q3  Q4 2014. I
 still think it's relevant but process-per-tab will give some of the same
 benefits


Olli is working on creating some kind of unified scheduler for the giant
mess of GC and CC timers we currently have, in bug 1168991. This will make
it much easier to pause things during scrolling.

Andrew




 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Revisiting modelines in source files

[Andrew McCreight]

On Fri, Jun 19, 2015 at 8:27 PM, Nicholas Nethercote n.netherc...@gmail.com
 wrote:

  Sat, Jun 20, 2015 at 2:16 AM, Gregory Szorc g...@mozilla.com wrote:
 
  We can mass rewrite the tree. But unless
  the tools to keep things consistent are easy and painless to use, this
 will
  add chaos.

 Chaos? There are two distinct steps here.

 1. Get the style mostly consistent (e.g. spacing/indentation/bracing
 that erahm mentioned). This is
 probably best done in chunks, e.g. a few directories at a time, rather
 than a single mass rewrite, just because chunks are easier to manage.

 2. Introduce auto-formatting of some kind.

 Step 1 is a necessary pre-requisite of 2, but step 1 is useful even if
 2 doesn't happen.

 I also think automated tools probably won't get us meeting the style
 guide perfectly -- e.g. the aforementioned line-length wrapping, and
 can they ensure CamelCaps() function names and aFoo/mFoo/gFoo/sFoo
 variable naming? -- so even if we do step 2 we'll still need some
 style vigilance during reviews, and possibly some manual style fixes
 later. But that's ok, and it would still be a clear improvement over
 the current situation.


Yeah, I've reviewed a bunch of poiru's patches, and the situation in those
files is much better now. Before you'd end up with weird half-styles, and
it was hard to know what you style you should even use in any chunk of
code. Now, it is at least mostly consistent. Certainly, automated tools
enforcing the style would be a big improvment, but just having the style
cleaned up is very nice.



 Nick
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Revisiting modelines in source files

[Andrew McCreight]

On Wed, Jun 17, 2015 at 3:53 AM, Mike Hommey m...@glandium.org wrote:

 What we currently have in the tree is essentially modelines for vim and
 emacs. But:
 - most vim installations have modelines disabled by default because of
   the security implications: https://lwn.net/Articles/20249/.
 - emacs has the same security implication, and AIUI, opening a file with
   a modeline makes emacs ask questions to the user. Or ignore them in
   batch mode.

As Boris said, for our particular emacs modeline there is no prompt.


 - they add 2 or 3 lines of boilerplate to every file in the tree.

There's a ton of boilerplate at the top of every file, between the MPL and
the vast sea of includes, which we're never going to be able to get rid of.


 - they are not being added to every file in the tree.

Mode lines are easy to fix up (I wrote a script to do this) and only need
to be done once per file.

So how about removing modelines and adding editorconfig files?


I'm not particularly attached to mode lines (they are rather gross!), but
replacing a once-per-file cost with a once-per-developer cost doesn't seem
like a good trade off to me.


 Mike
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The War on Warnings

[Andrew McCreight]

On Thu, Jun 4, 2015 at 2:49 AM, Jonas Sicking jo...@sicking.cc wrote:

 FWIW, I suspect it'll be hard to put a dent in the number of warnings
 that we emit unless we either change all instances of
 NS_ENSURE_SUCCESS(rv, rv) to use some other macro which doesn't warn,
 or unless we change NS_ENSURE_SUCCESS(rv, rv) to not warn.


As you can see the from the list, the distribution of these warnings is
very uneven. It is not necessary to solve the entire warning issue to make
huge reductions in the total volume of warnings we see. For instance, in
bug 1170642 I noticed that there were about 16MB of warnings in e10s M2,
produced by a single line of code (which Eric fixed by removing the
warning).

Andrew



 It feels like right now we have three incompatible desires:

 * Test lots of failure cases.
 * Make errors warn in debug builds on all/most frames as the failure
 is propagated up the callstack.
 * Don't warn a lot when testing debug builds.

 It seems like we can only pick two out of these three.

 / Jonas



 On Wed, Jun 3, 2015 at 6:14 PM, Eric Rahm er...@mozilla.com wrote:
  We emit a *lot* of runtime warnings when running debug tests. I
 inadvertently triggered a max log size failure during a landing this week
 which encouraged me to take a look at what all is being logged, and what I
 found was a ton of warnings (sometimes accompanied by stack traces). Most
 of these should probably be removed (of course if they're real issues they
 should be fixed, but judging by the frequency most are probably non-issues).
 
  I'm currently cleaning up some of these, but if you happen to see
 something in the following list and are feeling proactive I would
 appreciate the help. There's even a meta bug for tracking these:
 https://bugzilla.mozilla.org/show_bug.cgi?id=765224
 
  I generated this list by grabbing the logs for a recent m-c linux64
 debug run, normalizing out PIDs and timestamps and then doing some
 sort/uniq-fu to get counts of unique lines.
 
  This is roughly the top 40 offenders:
 
65959   [N] WARNING: Overflowed nscoord_MAX in conversion to
 nscoord width: file ../../dist/include/nsRect.h, line 83
63460   [N] WARNING: NS_ENSURE_TRUE(piTarget) failed: file
 gdom/events/EventDispatcher.cpp, line 469
20039   [N] WARNING: 'NS_FAILED(rv)', file
 gdom/workers/ServiceWorkerManager.cpp, line 2529
20039   [N] WARNING:
 '!BasePrincipal::IsCodebasePrincipal(aPrincipal)', file
 gdom/workers/ServiceWorkerManager.cpp, line 2591
17784   [N] WARNING: Subdocument container has no frame: file
 glayout/base/nsDocumentViewer.cpp, line 2506
16322   JavaScript warning:
 file:///builds/slave/test/build/tests/jsreftest/tests/js1_8/extensions/regress-476427.js,
 line 1: JavaScript 1.6's for-each-in loops are deprecated; consider using
 ES6 for-of instead
14159   [N] WARNING: NS_ENSURE_TRUE(mMutable) failed: file
 gnetwerk/base/nsSimpleURI.cpp, line 264
14087   [N] WARNING: NS_ENSURE_SUCCESS(EnsureScriptEnvironment(),
 nullptr) failed with result 0x80040111: file gdocshell/base/nsDocShell.cpp,
 line 4592
11315   [N] WARNING: '!mMainThread', file
 gxpcom/threads/nsThreadManager.cpp, line 299
10574   [N] WARNING: No docshells for remote frames!: file
 gdom/base/nsFrameLoader.cpp, line 491
 9201   [N] WARNING: have unconstrained width; this should only
 result from very large sizes, not attempts at intrinsic width calculation:
 'psd-mIEnd != NS_UNCONSTRAINEDSIZE', file
 glayout/generic/nsLineLayout.cpp, line 884
 9155   [N] WARNING: have unconstrained width; this should only
 result from very large sizes, not attempts at intrinsic width calculation:
 'psd-mIEnd != NS_UNCONSTRAINEDSIZE', file
 glayout/generic/nsLineLayout.cpp, line 3058
 9130   [N] WARNING: have unconstrained width; this should only
 result from very large sizes, not attempts at intrinsic width calculation:
 'aISize != NS_UNCONSTRAINEDSIZE', file glayout/generic/nsLineLayout.cpp,
 line 160
 8844   [N] WARNING: Someone passed native anonymous content
 directly into frame construction.  Stop doing that!: file
 glayout/base/nsCSSFrameConstructor.cpp, line 6559
 7599   [N] WARNING: NS_ENSURE_TRUE(mDocShell) failed: file
 gembedding/browser/nsWebBrowser.cpp, line 363
 7454   [N] WARNING: anonymous nodes should not be in child lists
 (bug 439258): file glayout/base/RestyleManager.cpp, line 1440
 6544   [N] WARNING: Graph thread slowdown?:
 'std::abs(framePosition - CurrentDriver()-StateComputedTime()) 
 MillisecondsToMediaTime(5)', file gdom/media/MediaStreamGraph.cpp, line 1195
 6126   [N] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result
 0x80520012: file gnetwerk/base/nsFileStreams.cpp, line 492
 6126   [N] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result
 0x80520012: file gnetwerk/base/nsFileStreams.cpp, line 205
 5637   [N] WARNING: No outer window available!: file
 gdom/base/nsGlobalWindow.cpp, 

reminder: C++ mode lines

[Andrew McCreight]

I just landed a 1.2MB patch to fix C++ mode lines in dom/

As a reminder, the mode lines that should be used (in C++ files that are
properly 2-space indented) are:

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2
-*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */

See more at:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line

I generated the patch using a Python script, modeline.py, which can be
found on GitHub:
  https://github.com/amccreight/moz-source-tools

Feel free to use it for other directories, though I've already run it for
xpcom/. It tries to analyze whether a file is 2-space indented, which is a
little finicky.

Thanks to jst for reviewing the giant patch.

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: changing the default platform and operating-system on bugzilla.mozilla.org to all / all

[Andrew McCreight]

On Tue, Apr 14, 2015 at 8:40 AM, Dave Townsend dtowns...@mozilla.com
wrote:

 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
 problem that OS doesn't allow for multi-selections where say a bug affects
 a few versions of Windows or Windows and OSX. I've gotten used to just
 ignoring these fields and reading the bugs instead. I wouldn't feel any
 loss if they were just removed from display entirely.


I find them useful occasionally, though now that I think about it,
specifying affected operating systems through keywords would probably be
more useful.  Hopefully they will become more useful with the bugzilla
changes, so you don't get things set to random OSes when they don't need to
be.

Andrew



 On Tue, Apr 14, 2015 at 8:17 AM, Byron Jones g...@mozilla.com wrote:

  bugzilla has a set of fields, hardware and operating system, that
 i'll
  collectively call platform in this post.  their default values are
  detected from the reporter's user-agent string when a bug is created.
 
  unfortunately on bmo, the platform fields have two distinctly different
  meanings: the reporter's platform and the platform a bug applies to. for
  too long have these two conflicting meanings coexisted within the same
  field, leading to confusion and a field that on many bugs is wrong or
  useless.
 
  thanks to bug 579089 we plan on making the following changes early next
  week:
 
  * each product gains the ability to set their default platform
 
  * the default platform for all products initially will be all / all
 
  * a use my platform action will be added to enter-bug, allowing the bug
  reporter to quickly change from the product's default
 
  * a from reporter button will be visible when viewing untriaged bugs,
  which sets the platform to the reporter's
 
 
  --
  byron jones - :glob - bugzilla.mozilla.org team lead -
 
  ___
  dev-platform mailing list
  dev-platform@lists.mozilla.org
  https://lists.mozilla.org/listinfo/dev-platform
 
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to ban the usage of refcounted objects inside C++ lambdas in Gecko

[Andrew McCreight]

On Fri, Apr 10, 2015 at 10:37 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
wrote:

 On 2015-04-10 12:33 PM, Andrew McCreight wrote:



 On Fri, Apr 10, 2015 at 8:46 AM, Ehsan Akhgari ehsan.akhg...@gmail.com
 mailto:ehsan.akhg...@gmail.com wrote:

 I would like to propose that we should ban the usage of refcounted
 objects
 inside lambdas in Gecko.  Here is the reason:

 Consider the following code:

 nsINode* myNode;
 TakeLambda([]() {
myNode-Foo();
 });


 How is this any worse than any other usage of raw pointers on the stack?

 nsINode* myNode;
 doSomething();
 myNode-Foo();

 is the same thing.


 It is worse since the lambda may be held on to and executed later in the
 future (i.e., past the point in time when the function returns.)

 But also do note that raw pointers to refcounted objects on the stack are
 very dangerous as well (for example in your above code, doSomething() could
 destroy myNode.

  I also don't see how don't use any refcounted objects inside lambdas
 is any easier to enforce.


 It's easier because we don't yet have piles of code which have this
 pattern in them.  I would like to prevent us getting there so that we don't
 have to start solving this issue on a massive scale in a few years once we
 grow more lambda usage.

  I also don't see why refcounted objects in particular are worth of
 exclusion based on their lifetime in closures, but not references to
 other allocated things.  I guess we don't have local variables like
 |nsTArrayFoo* myArray;| as often, but that would be just as dangerous.



Yes, I have nothing against coming up with further restrictions to make
 more things safe, but mentioning other dangerous things is not an argument
 against this proposal.  ;-)


Well, I don't really see what is difficult about this in particular, but
I've been writing code in functional programming languages for a long time,
so maybe I'm just used to the lifetime issues around closures already.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Help needed: define Bugzilla components in moz.build files

[Andrew McCreight]

I hacked up a crude script to collate the results from Gregory's
spreadsheet that collates the results across a subdirectory into sort of
useful results:

https://github.com/amccreight/gecko-components

From the spreadsheet, do download as and then comma separate values to
get the input format.

For the dom/ subdirectory, it produces output like:

dom: Core :: DOM (2)
dom/phonenumberutils: Firefox OS :: Runtime (1), Firefox OS :: RIL (1),
Firefox :: Developer Tools (1), Core :: DOM: Device Interfaces (1)
dom/ipc: Core :: DOM: Content Processes (22), Core :: IPC (14), Core :: DOM
(10), Core :: DOM: IndexedDB (8)
dom/notification: Core :: DOM (7), Firefox OS :: Gaia::System (3)
dom/indexedDB: Core :: DOM: IndexedDB (45), Core :: DOM (15), Core :: XPCOM
(8), Core :: JavaScript Engine (2)
dom/tv: Firefox OS :: General (24)
dom/workers: Core :: DOM (27), Core :: DOM: Workers (26), Firefox ::
Developer Tools: Debugger (4), Core :: JavaScript Engine (4)
dom/cache: Core :: DOM (60)

There are a number of obvious improvements that could be made, like doing
some kind of coalescing (so if A, A/B, A/C, and A/D are in the same
component, but A/E isn't, then you'd want A and A/E to have components
indicated), and automatically inserting changes to a tree so you could make
a patch, but I'm not sure if it is worth the effort or not.  (I'm thinking
about this because dom/ has something like 90 subdirectories.)

Andrew

On Wed, Mar 4, 2015 at 9:48 PM, Gregory Szorc g...@mozilla.com wrote:

 I was accidentally sorting based on bug component name, not the count of
 bugs. The spreadsheet has been updated.

 Sorry for the confusion.

 On Wed, Mar 4, 2015 at 5:50 PM, Botond Ballo bba...@mozilla.com wrote:

 I see other wrongness in that spreadsheet, too. For example, for the
 first file I cared to check, gfx/layers/apz/src/APZCTreeManager.cpp,
 the spreadsheet gives Firefox for Metro :: General as the bug.
 However, I just checked, and out of the 80 bugs that touched the file
 since its creation, which was in 2014, 63 were in the Core :: Panning
 and Zooming component, and only 1 was in Firefox for Metro ::
 General.

 Cheers,
 Botond

 On Wed, Mar 4, 2015 at 4:57 PM, Cameron McCormack c...@mcc.id.au wrote:
  L. David Baron:
  Having looked at the data for layout/, I think the results in the
  spreadsheet are mostly wrong, and I'd rather not populate things
  using it.
 
  A lot of the wrongness is files which weren’t updated recently, except
  for tree-wide changes such as introducing nullptr, which got filed in
  components like Core :: XPCOM.
 
  --
  Cameron McCormack ≝ http://mcc.id.au/
  ___
  dev-platform mailing list
  dev-platform@lists.mozilla.org
  https://lists.mozilla.org/listinfo/dev-platform



___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Help needed: define Bugzilla components in moz.build files

[Andrew McCreight]

Is there any kind of existing code around that would look at the bugs for
the commits for the files in a directory and create some kind of count of
the components they were filed in?  dom/ has something like 90
subdirectories, and it would be nice to be able to quickly get some kind of
census like that to guide writing BUG_COMPONENT thing.

Andrew

On Tue, Mar 3, 2015 at 10:16 AM, Gregory Szorc g...@mozilla.com wrote:

 Support for the previously announced [1] intention to use moz.build to
 define metadata for files has now landed on mozilla-central with the
 landing of bug 1132771 [2].

 This is important to you because there are plans to leverage this metadata
 to make it easier to get stuff done. Some potential uses include:

 * automatically filing bugs against the proper component
 * automatically selecting reviewers for a patch
 * intelligently scheduling automation jobs based on what changed

 *But we can't do any of these things unless there is data to drive it.*
 That's where you come in.

 I would kindly request that you take a few minutes to help define which
 files in mozilla-central map to which Bugzilla components. The process for
 doing this is relatively simple:

 1) Read the docs on how file metadata works [3]
 2) Write and land a patch (see [4] for an example patch)

 The newly-landed `mach file-info` command can be used to help you query
 metadata on files. Run `mach help file-info` for usage.

 If you need help, ask in #build.

 If you don't like how things work or if you have a suggestion for
 improvement, file a new bug depending on bug 1132771 and we'll go from
 there. You may be interested in bugs already on file, which include support
 for defining code reviewers (bug 1137042) and the ability to audit metadata
 for correctness (bug 1137043).

 Adding or changing Files entries in moz.build files does not require
 build peer review.

 [1]

 https://groups.google.com/d/msg/mozilla.dev.platform/iXr70VgapWk/GkTCcKRjNi8J
 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1132771
 [3]

 https://ci.mozilla.org/job/mozilla-central-docs/Tree_Documentation/build/buildsystem/files-metadata.html
 [4] https://hg.mozilla.org/integration/mozilla-inbound/rev/4cc39c54099d
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: gecko-dev and Git replication will be broken for a little while

[Andrew McCreight]

On Fri, Jan 30, 2015 at 2:08 AM, Tim Guan-tin Chien timdr...@mozilla.com
wrote:

 Any support for Level 1 people for creating a patch-to-commit for
 attaching on Bugzilla?
 I tried :jlebar's moz-git-tools once but the exported patch was broken for
 hg.


The easiest way to attach a git patch to bugzilla is with
  git bz attach -e commits
It automatically figures out what bug you want to attach to, based on the
commit description, and uses your browser cookie or something to actually
do the uploading.  It also formats it all correctly.

This is part of moz-git-tools, which we're actively maintaining at
https://github.com/mozilla/moz-git-tools

Please file any problems you have with it on Github.

Andrew


 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: e10s is now enabled by default for Nightly!

[Andrew McCreight]

- Original Message -
 Thinking ahead: e10s is a big enough change that I suspect we'll see
 high levels of instability when it gets uplifted to Aurora and
 (especially) Beta. Not sure how to avoid that... but will there be an
 easy way to disable it? I think there should be a pref in the user
 prefs (i.e. not just about:config) because it sounds like a
 non-trivial fraction of users will have add-ons broken by it. And does
 safe mode disable it?

There's already a check box in preferences that disables it.

 
 Nick
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform
 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Git - Hg workflows?

[Andrew McCreight]

Generally speaking, I use git for everything except pushing to inbound and try, 
and I use moz-git-tools to intermediate my interaction with hg.

 a) Landing code to inbound, fx-team, aurora, etc

For this, I keep around hg repos for the repos I care about, which is m-c and 
inbound right now, then use:
  git push-to-hg -t ../hg/inbound patches to commit
Then I go over to my hg repo and push using hg in the usual way.

For non-inbound branches, thanks to the awesome work of the sheriffs, I don't 
have to deal with pushing at all.

 b) Pushing to Try

For this, I do
  git push-to-try ../hg/mc -b d -p linux -u all -t none

This single command deals with everything that has to happen in the hg repo, so 
I don't need to interact with it directly.

 c) Fetching new commits
I just use git fetch for this, then manually switch over to my hg repos and 
update them, so I can be sure that when I push to try, things match up.

 d) Collaborating/sharing commits with others, especially hg-git sharing
I just use github if I need to do this, though I haven't done it much.

I upload patches to bugzilla using
  git bz attach -e patches to commit

The little text file it brings up lets me do things like set reviewer flags, 
obsolete patches, etc.  I even wrote some code that tries to figure out who you 
are going to ask to review the patch, based on the r=foo stuff in the commit 
message, so it is convenient.  No hg is involved AFAIK.

 Is going through a hidden, local hg bridge seamless? Satisfactory?
 Barely tolerable? A horrible pain point? (I noticed some of the hg
 interactions in moz-git-tools aren't optimal. If these are important
 tools, please ping me off list so I can help you improve them.)

Needing the extra disk space, and having to update extra repos, is a little bit 
annoying, but not a big deal.
 
 Is moz-git-tools the de facto standard for Mozilla developers? Are there
 other competing tools?

FWIW, John Schoenick has been maintaining moz-git-tools, and a few others of us 
submit the occasional patch.  So it isn't as abandoned as Ehsan's message might 
make it seem. ;)

 Overall, how happy are you with your Git fetch/push workflows? Short of
 switching the canonical repositories to Git, what do you need to be more
 productive?

It is pretty good.  Having to keep around extra repos is my only real 
complaint. Pushing to try can be a little pokey, but I don't know what part of 
the process is slow, and I can just let it do its thing and come back to it 
later.


Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: ./mach build subdirectory doesn't work reliably any longer

[Andrew McCreight]

- Original Message -
 FWIW, I've often made changes like this when touching files like
 nsCOMPtr.h or nsINode.h -- or switching nsresult from a typedef to an
 enum class! -- and I find just doing ./mach build binaries works fine.
 It reports errors randomly from all over the tree, but that works fine
 for me.  What's the advantage of doing it directory-by-directory?

I've had some cases where a file that is included everywhere will break in some 
particular file, but be fine in most places, so you end up rebuilding a bunch 
of stuff you know is going to work everytime you adjust it.  I don't recall 
offhand why that was.  Maybe a template that broke in certain instantiations?

Andrew
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform