I had removed the USE_YASM define in porting the libvpx
moz.build to libaom, to avoid depending on VPX_USE_ASM.
Turns out USE_YASM is a magic context define, without which
the build won't compile libaom's yasm-format .asm files,
so we need to define it for the two intel architecture
source sets.
Restore the define unconditionally for intel targets.
We require yasm in the default build for those targets,
and want to fail if it isn't available to block performance
regressions.
MozReview-Commit-ID: CqGtY8RNLNf
--HG--
extra : rebase_source : ccc7f9dfc467642d9e4c623c55e54e769fb38f2f
We no longer support 32-bit x86 macOS, and
these flags point to configurations we
don't generate.
MozReview-Commit-ID: 3mIfHCf6aUj
--HG--
extra : rebase_source : 35b5089ade7f9d5d03e5f4d3f0760cc969b4b8c7
JavaScript errors that arise from the Marionette implementation are
currently wrapped as WebDriverErrors. A WebDriverError is encoded with
a "webdriver error" error code, which officially does not exist in the
WebDriver specification.
To distinguish WebDriver errors from programming errors of Marionette,
this changes them to be encoded as UnknownErrors (error code
"unknown error"). This will make stacktraces coming from clients
easier to read, since it is clear that the error is not caught by the
WebDriverError-catchall.
MozReview-Commit-ID: A5HejTOgOp8
--HG--
extra : rebase_source : 7bd4f539954dd11973b2bd16c1bf4f4ea7b4a4d7
For debug builds a delay of 1s is too short. It means that a navigation
command will return when the readyState reaches interactive for an eager
page load strategy. But due to the slowness of the browser, the next
command could already operate on a complete readyState. Delaying the load
of resources is the only possible option.
MozReview-Commit-ID: D2je04Euwf0
--HG--
extra : rebase_source : d74f276d96cd5bd2301f9dac8866f9dadc6e2937
We can bail out earlier before calling an FFI function.
This is a PR for https://bugzilla.mozilla.org/show_bug.cgi?id=1364264 .
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes do not require tests because it's for stylo
Source-Repo: https://github.com/servo/servo
Source-Revision: 875b07b4ec64d9ef01bafb81ecf01496c0b9fa4b
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : f61dc4336198f974eff1fcd7401efbbd899baa00
This slims down SharedStyleContext, in preparation for a few things.
First, I would like to eventually move the stylist to the document in Servo, in
order for it to hold the StyleSheetSet.
Also, this gets rid of a fair amount of overhead while creating it in stylo.
Fixes bug 1363245.
Source-Repo: https://github.com/servo/servo
Source-Revision: eeb1ee9723777b0dc04e919556826eef628363fe
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : e20eedc331b5fa4c6e2fecc140e10f220619deb8
This patch removes the magic number and instead uses the ELEMENT_NODE
constant which exists on all objects of the Node prototype chain.
We already test that obj has a nodeType own property.
MozReview-Commit-ID: If9HIkBjCyN
--HG--
extra : rebase_source : 5b04727b53616c08bf74a4f3acb56c33d827d015
According to a recent change in the WebDriver specification, we need to
return an object's JSON representation iff it exists.
The relevant specification prose change was made in
1ee4c61c11.
This patch causes return values that have a toJSON property that is a
function, to return the value of calling said function.
MozReview-Commit-ID: GpQNE9GpjCH
--HG--
extra : rebase_source : 7192bbd484cbaa4661f2442990082aefcdd1570b
This patch renames element.fromJson and element.toJson to
evaluate.fromJSON and evaluate.toJSON, respectively.
The JSON (de)serialisation code belongs more naturally in the evaluate
module, which did not exist when these functions were written.
MozReview-Commit-ID: FJGbjGD1kZ6
--HG--
extra : rebase_source : b2528f545c8213b06b9116299806d8ab8a875250
This patch matches Chrome's behavior almost exactly, except it uses a slightly
different formula for the deltaY value that results in the same movement speed
as Chrome but doesn't drift over time.
Tested by confirming that trackpad pinch zoom now works on maps.google.com,
wego.here.com, and figma.com.
`beginGestureWithEvent` and `endGestureWithEvent` are not called for
applications that link against the macOS 10.11 or later SDK when we're running
on macOS 10.11 or later.
For compatibility with all supported macOS versions, we have to call
{begin,end}GestureWithEvent ourselves based on the event phase when we're using
the 10.11+ SDK.
See: https://developer.apple.com/reference/appkit/nsresponder/1526368-begingesturewithevent
NO_TLS used to be hardcoded on mac because up to 10.6, __thread was not
supported. Until recently, we still supported for 10.6, and it's not the
case anymore, so we could make mac builds use __thread.
Unfortunately, on OSX, __thread circles back calling malloc to allocate
storage on first access, so we have an infinite loop problem here.
Fortunately, pthread_keys don't have this property, so we can use that
instead. It doesn't appear to have significantly more overhead (and TLS
overhead is small anyways compared to the amount of work involved in
allocating memory with mozjemalloc).
At the same time, we uniformize the initialization sequence between
mozjemalloc and mozjemalloc+replace-malloc, such that we have less
occasions for surprises when riding the trains (replace-malloc being
nightly only), ensuring the zone registration happens at the end of
mozjemalloc's initialization.
The function, when passed `true`, creates a new arena with no attachment
in the global list of arenas, and assigns it to the current thread.
When passed `false`, it restores the default arena.
Some details are left out because they don't matter yet, as the sole
initial use of the API is going to invoke the function when stylo rayon
threads start up, which happens exactly once per thread, and at thread
exit time, which happens at shutdown, if ever.
This simplifies things, and leaves those details to followup(s):
- Arenas can't simply be killed when the function is called with `false`
again (or when the thread dies) because they may still contain valid
allocations that could have been passed to other threads. Those arenas
should be kept until they are empty.
- jemalloc_stats doesn't know about them and will under-report memory
usage.
- pre/post fork hooks don't know about them and will not force-unlock
their locks. In practice, until those arenas are used for something
else than the style system, this can't lead to the dead-locks that
these hooks help prevent because nothing should be touching pointers
allocated through them after fork.
This avoids using substring matching on labels, which is likely to lead to
sadness someday.
MozReview-Commit-ID: J1pFuP1U335
--HG--
extra : source : 45d01b30e9d1eb6e7a06eb2800d7d54d302c2f6e
Marco Bonardo
Ralph Giles
Daniel Holbert
Manish Goregaokar
Andreas Tolfsen
nbeltran14
Henrik Skupin
Asaf Romano
Hiroyuki Ikezoe
Emilio Cobos Álvarez
Chris H-C
Wes Kocher
Joel Maher
Ryan VanderMeulen
Evan Wallace
Birunthan Mohanathas
Olli Pettay
Alin Selagea
Iris Hsiao
Mike Hommey
Julian Seward
Ruturaj K. Vartak
Jan de Mooij
Ehsan Akhgari
vincentliu
Phil Ringnalda
Kris Maglione
Cameron McCormack
Dustin J. Mitchell