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
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
@Honza: Please wait for a green try before reviewing this.
MozReview-Commit-ID: 5KlOkYLnorj
--HG--
extra : rebase_source : 339c2dda1eb2afaf490e6bacb613addeece42d04
Since we don't want to treat NS_BASE_STREAM_CLOSED as abort or error, let's just
treat it as success to simplify the call flow.
MozReview-Commit-ID: 1Fubaq6lfAq
--HG--
extra : rebase_source : b9168704aa618eca553d96770e3256aadcc4b925
Instead of doing dispatch inside MediaResourceCallback::NotifyDataEnded(),
we let the callers decide whether to call the function synchronously. This is required
by ChannelMediaResource::CacheClientNotifyDataEnded() which will run off the main thread.
MozReview-Commit-ID: IzUYw8QMZbD
--HG--
extra : rebase_source : b888049d5b999a37515f00e52ae02dcf17f227e8
extra : intermediate-source : 7b660cd9b9fbb1a00e427b8e9074c9b736a80ae9
extra : source : cc055c39bd9fbbeb4354bbbebe0c46512be6e3a3
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
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
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
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
