When the namespace changes (e.g. due to a tab move between windows), we
may get stale transaction requests that we need to ignore. In
WebRenderBridgeParent::RecvSetDisplayList, we would automatically send
any unsent transaction data when exiting the method, but this did not
take into account the staleness. This patch ensures we only flush the
data if we actually want it.
The transaction in question that was observed and causing crashes was
UpdateImageBuffer.
In bug 1482415 a special check was added for the case where we fail to allocate
a buffer and started an async task. This papered over one crash for another
as ClientPaintedLayer also assumes that if there is an async task there is
a capture. It'd be best to just null out mAsyncTask and keep those checks
as is.
Differential Revision: https://phabricator.services.mozilla.com/D3520
--HG--
extra : rebase_source : 8cb2458f0a98795a6ece90b38a9c194c863bbd84
This results in fixed position elements being attached to the layout viewport
when being async-scrolled by APZ (when the layout viewport is larger than the
visual viewport).
MozReview-Commit-ID: 2YYIDnTWgVn
--HG--
extra : rebase_source : 58b77b2e9c8ed35bdc2d24dd8ca9494e8d23a391
Includes a new RAII class: AutoApplyAsyncTestAttributes, which, for the
duration of its lifetime, applies mTestAsyncScrollOffset and mTestAsyncZoom to
the APZC's FrameMetrics. We need this to ensure that the
AsyncPanZoomController::GetCurrentAsync* methods consider test scroll and zoom
attributes when doing their respective computations.
MozReview-Commit-ID: 9owJcdIegNH
--HG--
extra : rebase_source : 35273faf10b8db13e3b5485278262f93d4adc579
These method names and ordering have gotten out of sync because of
the recent churn.
Differential Revision: https://phabricator.services.mozilla.com/D3288
--HG--
extra : rebase_source : 42bceaeb66a0df4808981b8c9cb0ed70b23f5a30
extra : histedit_source : 228024efe8de4e149f7e7ca66a2bb078bba820ce
This may have been needed at some point, but all the important code for
EndLayerTransaction is in CompositorBridgeChild behind a lock, so this
should be safe.
--HG--
extra : rebase_source : bda4080bc04afa95954732050df7bd25c8177752
extra : histedit_source : 9386583dd923bf0ae44ff783d3ef1c6692944c77
There should only ever be at most four TextureClients here, so
allocated a vector seems wasteful.
--HG--
extra : rebase_source : 6b0f9f7749461eb39cd3c6c6bf7917152ffc9aab
extra : histedit_source : b5539d02c294596a5147dc55b417ef7970f8c0cd
This was needed when there were multiple types of CapturedPaintStates but
is not anymore.
--HG--
extra : rebase_source : 3648edccca7c73e3e3aa7a5c3e0d48d12d6324c5
extra : histedit_source : 021814c10b6578970c3a6d234c1e6641ad26b095
Correctness improvements:
* UTF errors are handled safely per spec instead of dangerously truncating
strings.
* There are fewer converter implementations.
Performance improvements:
* The old code did exact buffer length math, which meant doing UTF math twice
on each input string (once for length calculation and another time for
conversion). Exact length math is more complicated when handling errors
properly, which the old code didn't do. The new code does UTF math on the
string content only once (when converting) but risks allocating more than
once. There are heuristics in place to lower the probability of
reallocation in cases where the double math avoidance isn't enough of a
saving to absorb an allocation and memcpy.
* Previously, in UTF-16 <-> UTF-8 conversions, an ASCII prefix was optimized
but a single non-ASCII code point pessimized the rest of the string. The
new code tries to get back on the fast ASCII path.
* UTF-16 to Latin1 conversion guarantees less about handling of out-of-range
input to eliminate an operation from the inner loop on x86/x86_64.
* When assigning to a pre-existing string, the new code tries to reuse the
old buffer instead of first releasing the old buffer and then allocating a
new one.
* When reallocating from the new code, the memcpy covers only the data that
is part of the logical length of the old string instead of memcpying the
whole capacity. (For old callers old excess memcpy behavior is preserved
due to bogus callers. See bug 1472113.)
* UTF-8 strings in XPConnect that are in the Latin1 range are passed to
SpiderMonkey as Latin1.
New features:
* Conversion between UTF-8 and Latin1 is added in order to enable faster
future interop between Rust code (or otherwise UTF-8-using code) and text
node and SpiderMonkey code that uses Latin1.
MozReview-Commit-ID: JaJuExfILM9
Multiple tabs in the same process could be viewing the same image. If it
is an image we are taking some time to download from the network, it may
not be displayed all at once. As a result, it could generate several
dirty rects for the newly decoded lines each time we paint. Since we
only apply the dirty rect to the active tab, and forget it afterwards,
then when one returns to the other tab(s), it may not reupload all of
the modified image data. Now we save the dirty rect and accumulate it
for the handles which weren't able to be updated immediately.