It can happen often where we reuse the front buffer for a long paint, and then
the next frame we see that it is still locked, and need to allocate a new buffer
from the texture pool. If this happens we don't need to repaint the new buffer
because the old buffer is still around, but we do need to copy it over and
upload it to texture sources. It seems better to just hold onto the back buffer
and let it accumulate more invalid regions.
MozReview-Commit-ID: 2DQjwAX7ZmM
--HG--
extra : rebase_source : 3077952d3ef56deea6af68492f71bb114d96d84a
When we are creating a new back buffer we mark the whole region as being
invalid. This will cause us to paint extra in certain circumstances where
the visible region is a subset of the tile space.
MozReview-Commit-ID: BayRu0mV39O
--HG--
extra : rebase_source : b7eb40408faca5fc3fbc3e53263de7d262af35d5
We discard and copy over data from the old tile when we resize a single tiled content client. For some reason
we were not removing that region we successfully copied from the invalid region we would then set on the tile.
This would cause us to do more work on following frames. For some other reason we were removing that region
from the region we'd clear for non-opaque tiles. This commit changes it so we remove it from both.
MozReview-Commit-ID: DIu1Y3jzV7Z
--HG--
extra : rebase_source : 9c06482798823cf9ecb9be4937c6af9dd1ece6f2
Automatic update from web-platform-testsCorrectly reject in-progress body methods with AbortError
Prior to this change, response body methods such as
response.body.arrayBuffer() would reject with a TypeError if the fetch
was aborted. This change makes them correctly reject with an AbortError
instead.
This implements stage #3 of the "Body Cancellation" section of the
design doc:
https://docs.google.com/document/d/1OuoCG2uiijbAwbCw9jaS7tHEO0LBO_4gMNio1ox0qlY/edit#heading=h.fvc7d7q07oio
Bug: 817687
Change-Id: Ifde322d9c22485a8ba9d14fd4ffca65c4fb4745a
Reviewed-on: https://chromium-review.googlesource.com/954765
Commit-Queue: Adam Rice <ricea@chromium.org>
Reviewed-by: Matt Falkenhagen <falken@chromium.org>
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Cr-Commit-Position: refs/heads/master@{#544335}
wpt-commits: f2ae7641fad03150b4238a8b34dc9bdfdf58c0dd
wpt-pr: 10096
wpt-commits: f2ae7641fad03150b4238a8b34dc9bdfdf58c0dd
wpt-pr: 10096
MozReview-Commit-ID: KWIBtaWMUPx
This also adopts the resolution of [1] while at it, and switches XUL to not
support display: contents until a use case appears.
This makes our behavior consistent both with the spec and also in terms of
handling dynamic changes to stuff that would otherwise get suppressed.
Also makes us consistent with both Blink and WebKit in terms of computed style.
We were the only ones respecting "behaves as display: none" without actually
computing to display: none. Will file a spec issue to get that changed.
It also makes us match Blink and WebKit in terms of respecting display: contents
before other suppressions, see the reftest which I didn't write as a WPT
(because there's no spec supporting neither that or the opposite of what we do),
where a <g> element respects display: contents even though if it had any other
kind of display value we'd suppress the frame for it and all the descendants
since it's an SVG element in a non-SVG subtree.
Also, this removes the page-break bit from the display: contents loop, which I
think is harmless.
As long as the tests under style are based in namespace id / node name /
traversal parent, this should not make style sharing go wrong in any way, since
that's the first style sharing check we do at [2].
The general idea under this change is making all nodes with computed style of
display: contents actually honor it. Otherwise there's no way of making the
setup sound except re-introducing something similar to all the state tracking
removed in bug 1303605.
[1]: https://github.com/w3c/csswg-drafts/issues/2167
[2]: https://searchfox.org/mozilla-central/rev/fca4426325624fecbd493c31389721513fc49fef/servo/components/style/sharing/mod.rs#700
MozReview-Commit-ID: JoCKnGYEleD
Bug 768765 isn't enough for fix. Since Selection::GetAnchorFocusRange can
return nullptr, we should consider this condition.
And I cannot reproduce this using crash test, so I add mochitest for this.
MozReview-Commit-ID: 8Ei5YBIBuWv
--HG--
extra : rebase_source : cd11517f73179d949479716a83baec0e1f492eca
This is regression of bug 1423835.
When I fixed the bug, I accidentally changed the result of
HTMLEditRules::JoinNodesSmart() to use new API. However, it was simple
misunderstand. The original code sets the initial value of result to
{ aRightNode - aLeftNode.Length() } but I understood it as
{ aRightNode - aRightNode.Length() }. Therefore, this patch backs out the
patch only for this line.
MozReview-Commit-ID: 5rD7YFij8v
--HG--
extra : rebase_source : c11770892ab7416b9bf5d3329fc8b7b413387747
Bug 1421018 intended to block the Ask.Com Toolbar (tbnotifier.exe).
This is basically malware and is responsible for a huge number of unnecessary accessibility instantiations.
However, there seems to have been some confusion and we ended up blocking tbnnotifier.exe instead.
This changes that block to tbnotifier.exe.
MozReview-Commit-ID: 2gZF8sYeGtb
--HG--
extra : rebase_source : 3d14a24c12748edfc31ddf7dac51bca491abd744
In practice, Android never enforced restrictions on the tag length, and
in newer versions, the restriction is removed, so we shouldn't limit the
tag length at all.
MozReview-Commit-ID: JQF9FBdB5Fj
--HG--
extra : rebase_source : 71aa09210d694b68a72043f7588fbd799f385c23
Use the new "debug" and "warn" functions with template literals in
existing code.
MozReview-Commit-ID: 4ob6mom6pQF
--HG--
extra : rebase_source : 564f23c8de1256f73c085845fe030d8bbf45b19c
Inject new logging functions, "debug" and "warn", into each GeckoView JS
module that geckoview.js loads. Also do the same thing for frame script
classes that extend from GeckoViewContentModule.
The new logging functions are used with template literals (debug `hello
${foo} world`;), which are lazily evaluated, so disabled logs don't use
as many CPU cycles. They can also be easily enabled/disabled.
MozReview-Commit-ID: 7ZfYAMrcCyU
--HG--
extra : rebase_source : 8a830f29ea1cabcdc5055fc86c9880a5216aa456
Make Log.jsm functions support tagged template literals. For example,
instead of |logger.debug("foo " + bar)| or |logger.debug(`foo ${bar}`)|,
you can now use |logger.debug `foo ${bar}`| (without parentheses).
Using tagged template literals has the benefit of less verbosity
compared to regular string concatenation, with the added benefit of
lazily-stringified parameters -- the parameters are only stringified
when logging is enabled, possibly saving from an expensive stringify
operation.
This patch also fixes a bug in BasicFormatter where consecutive tokens
are not formatted correctly (e.g. "${a}${b}").
MozReview-Commit-ID: 9kjLvpZF5ch
--HG--
extra : rebase_source : ccf4e9fae9fa9ea7581de82296035fcc736ca58e
Add an AndroidAppender that lets Log.jsm output to the Android logs,
using AndroidLog.jsm. Because the Android logging system keeps track of
the log metadata (time/level/name) separately from the log message, the
patch also adds a separate AndroidFormatter that does not prepend the
metadata to the log message itself.
MozReview-Commit-ID: C9oBbgVQOEc
--HG--
extra : rebase_source : eb1e8622b059ee45b574830426194ea35643b37c
Ryan Hunt
Jon Coppeard
Andreas Pehrson
Jason Laster
Ben Hearsum
Nathan Froyd
James Graham
Adam Rice
Ben Kelly
Jan-Erik Rediger
Dragan Mladjenovic
Florian Quèze
Jan de Mooij
Boris Zbarsky
Emilio Cobos Álvarez
ffxbld
Andreea Pavel
Jonathan Kew
Christoph Kerschbaumer
Tim Taubert
Nicholas Nethercote
Makoto Kato
Xidorn Quan
Masayuki Nakano
James Teh
Jim Chen
Gurzau Raul
Gijs Kruitbosch