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
Instead of evaluating config.guess in client.mk, we evaluate it
in Python. The Python code also looks for CONFIG_GUESS in the
mozconfig. This still happens in client.mk courtesy of evaling
the mozconfig's relevant parts.
MozReview-Commit-ID: 87NmQiB2ccX
--HG--
extra : rebase_source : 368bc7bf1375a3943ce62fbb77458c40091a7092
MozbuildObject._run_make() also invokes baseconfig.mk as part of
validating the make binary that will be executed.
Since mach calls this Python code and mach is now required to
invoke client.mk, the validation in client.mk is redundant and can
be removed.
autoconf.mk includes baseconfig.mk. So even once we eliminate
client.mk, the make backend itself will still validate make.
We should probably move this validation to moz.configure (if it
isn't already there). But that can be done another time.
MozReview-Commit-ID: DPCBdz253S6
--HG--
extra : rebase_source : 8588738c517bd636039555299095981c71722600
We're about to start moving logic from client.mk into Python.
The transition will require doing things like setting
environment variables when we invoke client.mk. Prepare for
this by factoring the "call client.mk" logic into a reusable
function.
The function will obviously be temporary until client.mk is
no more. I'm not sure what the end state will be yet. But surely
having equivalent code in Python is better than having it in
make.
MozReview-Commit-ID: F15DxXSV8V3
--HG--
extra : rebase_source : e04815201652cd90a6e5e1b105be761c21169aa6
Remove most of the Compositor and Surface management code in LayerView.
And use LayerSession.Compositor in rest of the gfx code.
MozReview-Commit-ID: 5E9pj3eGHlv
--HG--
extra : rebase_source : 0b0a64113db58aaf376c98d5480f5cf31174a3d3
Add a `screenOriginChanged` callback to GeckoDisplay.Listener, which
informs Gecko of changes in the origin of the display. The origin
translates to coordinates for web APIs like screenX/screenY and certain
other calculations.
Also, make GeckoDisplay listen to layout changes in the view tree (by
overriding gatherTransparentRegion as an optimization), and call
`screenOriginChanged` accordingly.
MozReview-Commit-ID: C72EHCkbV3T
--HG--
extra : rebase_source : 240c5c8fb3c2938ae966f40e86f7c5a0ca66526c
Make GeckoView implement GeckoDisplay for its own SurfaceView, and use
that with GeckoSession.
MozReview-Commit-ID: LXllQGlCxaB
--HG--
extra : rebase_source : 1b41e411b2c293797d572d584c4f2b7036e83b23
Make GeckoSession inherit from LayerSession, and connect its Compositor
to native code as part of the GeckoSession routine.
MozReview-Commit-ID: wQaH1A0a7z
--HG--
extra : rebase_source : ee4ae96e974d15c8cb9ad569ea9abf0ace4d0fa5
Make native code use LayerSession::Compositor instead of
LayerView::Compositor. Also, make some callbacks happen on the UI thread
to make the Java code cleaner.
MozReview-Commit-ID: KhuHel7Zfdn
--HG--
extra : rebase_source : 040442539fd7cc1af8e13e4be1d9ebfb1625f778
Add a LayerSession class that's split off LayerView. Currently,
LayerSession takes over Surface management and the Compositor class from
LayerView. Eventually, all of LayerView will migrate to LayerSession.
MozReview-Commit-ID: F1ozOfZGY2g
--HG--
extra : rebase_source : eaf42122db1238c99b0da1e689bc365180a2835f
Introduce a GeckoDisplay interface for interaction with GeckoSession.
MozReview-Commit-ID: 13prgWaPqKU
--HG--
extra : rebase_source : 282b27a1f7c11cf4e559b1f25946c3f4574e900a
We don't actually use the screen size through GeckoLayerClient anymore.
Getting rid of it lets us get rid of the Context field in
GeckoLayerClient as well.
MozReview-Commit-ID: GM1jlhAZm4T
--HG--
extra : rebase_source : 04827eb61d6304d4782a7a935d5528013255726f
on a CLOSED TREE
Backed out changeset dff6393650df (bug 1416284)
Backed out changeset b1474e3a2e94 (bug 1416284)
--HG--
extra : rebase_source : 0877a744252fdb0aeb022fc99fd8b117bdd2b628
Part of #19015.
Source-Repo: https://github.com/servo/servo
Source-Revision: 6f1d9a198fa3f060f3eae28f13ac248b0b1186ce
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 67e4b73b154a8ae116473b27f8c6b5f4650dc509
The library was added in bug 1160285 for webapprt, and webapprt was
removed in bug 1238079.
--HG--
extra : rebase_source : 8e47523263eb53707b0d916cc550418f1bc646ef
The Browser Testing and Tools group agreed that the webdriver endpoint, when
asserting for a modal, that it clears the modal on the screen and raises an
an Unexpected Alert Open error.
See https://github.com/w3c/webdriver/pull/1145
MozReview-Commit-ID: 1OnT1AMM0tY
--HG--
extra : rebase_source : dab2d8b96f3dc1dddb7b22127faf30e9e744b0bc
