Bug 1416607 - error when Moz2DImageRenderer fails to create a NativeFontResource or UnscaledFont. r=jrmuizel

MozReview-Commit-ID: Jool723LUFX

Backed out 1 changesets (bug 1402828) for failing devtools/client/netmonitor/test/browser_net_copy_as_curl.js r=backout a=backout on a CLOSED TREE

Backed out changeset 4d059e20a773 (bug 1402828)

Bug 1387511 - Part 1: Use the grid negative number platform API to render negative line numbers correctly in css grid inspector. r=pbro

MozReview-Commit-ID: 854rPXdmbny

Backed out 1 changesets (bug 1416948) for already being pushed in autoland by bug 1416456 r=backout a=allstarschh on a CLOSED TREE

Backed out changeset 9dd7ba5308be (bug 1416948)

MozReview-Commit-ID: BLZp3HskBji

--HG--
extra : rebase_source : 721d0586deb572a5e989547d592d741cc9d15950

There are non-cost reference return values on IPDL structs. We should take
advantage of them in order not to recopy everything everytime something
changes.

MozReview-Commit-ID: D4hG2moE3f

--HG--
extra : rebase_source : 4edca9b1a808f99dd60be908bbb197757bf9b90a

Find out where we use MayHaveTransformAnimation in EffectSet
and change them to MayHaveTransformAnimation in nsIFrame.

MozReview-Commit-ID: GhkztK8JtNa

Bug 1381153 - Part 1: Cache MayHaveOpacityAnimation and MayHaveTransformAnimation in nsIFrame. r=mstange, r=mats

There are two places where I have to cache the status of MayHaveOpacityAnimation
and MayHaveTransformAnimation. First place is in |nsIFrame:init()| where an
element is associated with a frame. Second place is in
|KeyframeEffectReadOnly::UpdateEffectSet()| where the script can add animations
on element.

btw I keep the original two flags of MayHaveOpacityAnimation and
MayHaveTransformAnimation in EffectSet because there is no guarantee that
an element has been associated with a frame when we call to |UpdateEffectSet()|.
But we still want to keep the benefits that we can quickly look up
MayHaveOpacityAnimation or MayHaveTransformAnimation. So I keep them in
EffectSet and transfer the status into nsIFrame when we bind an element
to a frame in nsIFrame:Init().

MozReview-Commit-ID: JDwyAQQTKA7

It would be really nice to push all of this back up to the parent or to at
least make it asynchronous. I think it should be possible since we control
when we send the DOM events, but for the moment this should work.

With this patch, I extend ProxyMIMEInfo and HandlerInfo with information about
the available extensions for a given MIME type. On Linux, at least, we read
the system (in my case GNOME) registry in the child and handlers.json in the
parent finally merging them again in the child (in
ContentHandlerService::FillHandlerInfo). Even though I was unable to get my
mochitest to work, it did work well enough that I could verify that this patch
was getting all of the proper extensions to the nsContentAreaDragDrop.cpp
code.

MozReview-Commit-ID: AR3VayMUiDN

--HG--
extra : rebase_source : f9861e46e92fb7e8d297eff3e5d61a3c18912b47

Non ns-prefixed classes are supposed to be in either the mozilla namespace or
a sub namespace (such as dom, css, or others).

MozReview-Commit-ID: 8bF6bP49NLG

--HG--
extra : rebase_source : bfa5e6da36c49ea7bb333eb58d168ef614c07c0b

MozReview-Commit-ID: HngrLGSS6St

--HG--
extra : rebase_source : deac5b74dd8490a39c08f6944c359f27bc3cd7f9

MozReview-Commit-ID: Aw8bQFlGQj3

--HG--
extra : rebase_source : d1e707b458cc9de278a79604663860ea5cb4e6a6

Bug 1415729 - Make 'necessary_update_should_be_invoked' test in file_restyles.html more strict. r=birtles

Before this change, the test calls getAnimations() after changing animation
duration.  Unfortunately it was wallpapering what's going on there actually
since getAnimations() flushes pending styles.  This patch drops the
getAnimations() call and makes it clear how many restyles happen there.

MozReview-Commit-ID: A0a5MlTyBnD

--HG--
extra : rebase_source : cc20d2c6945f81f72c753137441b8d84ff52ff63

MozReview-Commit-ID: AcjDRK36d9d

--HG--
extra : rebase_source : 2d853c3c4702e775275a49f2eb3552ef00b7d295

MozReview-Commit-ID: Ds87KZ47vf1

--HG--
extra : rebase_source : 0578a58107b39abb546758cd8aa21c89e7b4b81f

Bug 1415469 - Remove mDeviceResetSequenceNumber from TDR process since we don't need it anymore; r=dvander

MozReview-Commit-ID: 3uQQwW8QOJA

--HG--
extra : rebase_source : ab6090ad51a2a4714f1739a30d854d624d187239

MozReview-Commit-ID: 8ozY0Zbuczx

--HG--
extra : rebase_source : 7c99ea332b0da1ac20ec1037fb0dc4ac9088d8f8

SRWLock is more lightweight than CriticalSection, but is only available
on Windows Vista and more. So until we actually dropped support Windows
XP, we had to use CriticalSection.

Now that all supported Windows versions do have SRWLock, this is a
switch we can make, and not only because SRWLock is more lightweight,
but because it can be statically initialized like on other platforms,
allowing to use the same initialization code as on other platforms,
and removing the requirement for a DllMain, which in turn can allow
to statically link mozjemalloc in some cases, instead of requiring a
shared library (DllMain only works on shared libraries), or manually
call the initialization function soon enough.

There is a downside, though: SRWLock, as opposed to CriticalSection, is
not fair, meaning it can have thread scheduling implications, and can
theoretically increase latency on some threads. However, it is the
default used by Rust Mutex, meaning it's at least good enough there.
Let's see how things go with this.

--HG--
extra : rebase_source : 337dc4e245e461fd0ea23a2b6b53981346a545c6

MozReview-Commit-ID: J7Roez2btL

--HG--
extra : rebase_source : c65e1bd1239516dbf64d0025e41832a157d0d2ad

Bug 1416490 - Backed out changeset 6a412222f22e (bug 1320738) in favor of fixing the underlying issue. r=glandium

MozReview-Commit-ID: 5JaoquWq5Jj

--HG--
extra : rebase_source : 70f3cff23ab7d4d0f0e79d1cf207b0462c355ce0

Bug 1416490 - Ensure environment variables that are configure options are passed from configure to old-configure. r=glandium


MozReview-Commit-ID: GFP8bahu1bb

--HG--
extra : rebase_source : 1ff35a8b6470308b71dc74c2befb8219a41534c2

Bug 1416490 - Check for a value passed to RUSTC_OPT_LEVEL rather than whether its value was a default. r=glandium

The current code will fail if "RUSTC_OPT_LEVEL=" is passed. This can happen
if the value isn't present and that fact is injected into js' configure. We
only want to respect RUSTC_OPT_LEVEL if a value is passed, so we simply check
for the presence of a value rather than its origin.

MozReview-Commit-ID: 6GhLfprJEEn

--HG--
extra : rebase_source : 40f3e381a128e04d65cc0175df32cdcd8302e05e

On Windows 7, there is yy/mm/dd'('ddd')' as short date format of Japanese.
When selecting this, ddd isn't converted to day of the week correctly.

FindInReadable will update start position iterator even if not found. So when
using FindInReadable again, we have to reset start position iterator.

MozReview-Commit-ID: AoS1Txq3Twc

--HG--
extra : rebase_source : 2f02189d0288e833debb2d4ca47efbca632924e5

Now that nsArray uses nsCOMArray under the hood, we don't have to do weird
ForwardEnumeration hacks to start IndexOf at a non-zero index.

MozReview-Commit-ID: 3ReDV0BT0hn

--HG--
extra : rebase_source : 399a988d00fabaa314eb7592b2aacf277a2ca477

Forgot to push the updated patch to review.

Test-only change. So self-reviewing.

CLOSED TREE

--HG--
extra : amend_source : 44bbf8748ce10982e6a3d96ff9ed42d3dc653f3f

Now that we require mach to run client.mk and mach only invokes
client.mk for full builds (the "build" target) and configure
(the "configure" target), we should no longer have anyone using
client.mk as a proxy to make targets in the build backend.

So remove that feature.

MozReview-Commit-ID: BbaMdZHnRXy

--HG--
extra : rebase_source : 570e81a62e35cbe4ea27e011883a306f23f3024c

This was added before mach AFAICT. If people need this functionality,
we can add a mach command.

MozReview-Commit-ID: HL52nJE2SMQ

--HG--
extra : rebase_source : cdf67a997731e7f1f94e16aa36c3f806c09779e8

The clobber logic is already written in Python. Now that we
always use mach in front of client.mk, we can check the clobber
state before we execute client.mk.

Since we always check the clobber state, we can remove the
CLOBBER files from various dependencies in client.mk. The
clobberer code should ensure everything is in a good state.

The refactor of the clobber Python code required some changes to
its testing. We drop some support for verifying output strings.
But testing this correctly would require a bit of effort. I don't
think it is worth it.

MozReview-Commit-ID: 69CoImCgtNm

--HG--
extra : rebase_source : c925bb49fd54fe6a5abaa4ac9dc0833e139c6a57

I'm pretty sure this was related to the now removed feature for
building multiple projects.

MozReview-Commit-ID: 4AG7lsk6BLS

--HG--
extra : rebase_source : b677a141161255ffeea57358d4f497fc05c8fb1c

Now that mach is being used to invoke client.mk, we can perform
objdir directory creation there.

Removing the use of mkdir_deps meant that we could remove some
included make files which AFAICT were only used to provide
$(mkdir_deps).

MozReview-Commit-ID: 4ZRToz8xqZy

--HG--
extra : rebase_source : 8d0d2430b33863e1dec8cee84e72178307d1c6e0
extra : source : d223afd90123eba035714288d5da9394b2dbb8d8

The auto-generated make file that we include (and the `mach environment`
output that we included before that) should not contain comment lines.
I think it is safe to remove the code that filters them out.

It is possible a multi-line value in mozconfigs could contain lines
looking like comments and this may cause problems. I'm inclined to
believe that this scenario doesn't exist. If someone complains and
we need to bring back support, we could certainly do that.

MozReview-Commit-ID: 8kKw91HH4ms

--HG--
extra : rebase_source : 3fab8af7f713c91632f3d5172664832af10b555f

This should have the same net result.

TBH, I'm not 100% convinced we need this export. It is only needed
to send variables to sub-makes. And the only make file reading
FOUND_MOZCONFIG is client.mk. Since the code that evals the
auto-generated make file is always executed in client.mk, we
shouldn't need this export.

All this code is going away soon anyway. So I'm inclined to cargo
cult this just in case.

MozReview-Commit-ID: DqF1BU702A

--HG--
extra : rebase_source : 31859c0d4bb6ceb06367bf0ca554d79d57d2d0c3

Currently, client.mk calls `mach environment` to obtain a make file
to be evaluated in the context of client.mk. The reason it is
implemented this way is because client.mk could be an entrypoint to
the build system.

With recent changes that require the use of mach to use client.mk,
we are now guaranteed to have Python code running before client.mk
is invoked. This means we don't need to invoke `mach` from client.mk.

This commit ports the code for generating a client.mk suitable make
file from `mach environment` to the build dispatcher. We now write out
a new .mozconfig-client-mk file in the objdir. client.mk is changed
to cat this file and to include it as a native make file.

The OBJDIR environment variable is also set so client.mk knows where
to read the auto-generated file from.

This commit should be backwards compatible.

Hopefully it is obvious, but this new make file is only temporary.
As soon as the remaining mozconfig logic is moved out of client.mk,
we should be able to simplify down to a single "include" in client.mk.

MozReview-Commit-ID: BEfWo76Z1qA

--HG--
extra : rebase_source : 752df93f816b95bda108a3c787d7f4941b136bbb

Actual uses of this variable were removed by 5fb427c50ca3
(bug 1412431). This is dead code.

MozReview-Commit-ID: GsDqpXZol2L

--HG--
extra : rebase_source : ce6eb799aa8a20e7a9af0587167bf05a6095b8df