There's only one case of sync frame construction from ContentRemoved now, and
it's not on the element being removed, but on the whitespace siblings if needed,
and _only_ when they don't support lazy frame construction.
Basically, this switches all the RecreateFramesForContent calls to use
`aAsyncInsert` (which I changed to an enum class for readability), except when
we're already reframing.
Also, it switches ReframeTextIfNeeded to opt-in into lazy frame construction,
since it's used only when aFlags == CONTENT_REMOVED.
This allows to simplify the DestroyFramesFor API (which I'm happy to rename to
something more meaningful, since now it's something like
DestroyFramesForAndRecreateThemAsync), and do some other consistency cleanups.
A bunch of the ContentRemoved callsites were pretty random at passing
aAsyncInsert, and that was some kind of a mess. This patch ensures consistency,
and makes it impossible to do O(n^2) work when removing DOM nodes, which is
nice.
The underlying reason for this is explained in the description of bug 1377848,
and basically allows us to remove a bunch of Servo hacks on the longer term (a
few of them are going away already, yay!).
MozReview-Commit-ID: 2DrUTxGV8RX
--HG--
extra : rebase_source : f428d839a5482477dea22c0fea600d54f3e8799c
The login reputation checks depend on a server lookup and therefore would
render non-deterministic the performance and correctness of tests.
MozReview-Commit-ID: Bil0rSZsGPT
--HG--
extra : rebase_source : ae06a028c71eee323307ecd4e62bbf1e8a14fe13
The login reputation checks depend on a server lookup and therefore would
render non-deterministic the performance and correctness of tests.
MozReview-Commit-ID: Bil0rSZsGPT
--HG--
extra : rebase_source : c9a641e4bf49c48bf864ed546bf2ae6eb51c27e4
Bindgen bitfield enums don't work as return values with the Linux 32-bit ABI at
the moment because they wrap the value in a struct.
This causes the Rust side to believe the caller will pass along space for the
struct return value, while C++ believes it's just an integer value.
MozReview-Commit-ID: JHDp0XAmQCG
For the Obama wikipedia page, this covers about 85% of the unmeasured
ComputedValues structs. The about:memory output looks like this:
> +---2,443,648 B (02.41%) -- computed-values
> | +--1,088,272 B (01.07%) -- dom
> | +----945,744 B (00.93%) -- non-dom
> | +----409,632 B (00.40%) -- visited
I'm not sure why some CVs are still being missed.
MozReview-Commit-ID: 1bYWwSi4ihn
--HG--
extra : rebase_source : 14e4bd36a54bbbd8fd265f559704bec5a5e3b154
GTK is definitely not thread-safe, and unless proven otherwise, I suspect the
other widgets aren't either.
Mutex the calls to get the system color stuff.
There are chances to make this more fine-grained moving the mutexes into the
specific widget code and when needed. That is more analysis work which I'm not
sure we should waste time on, since the chances on racing here seem quite
unlikely in practice (system colors are uncommon enough in content, I guess).
MozReview-Commit-ID: AOQQ2jtkgpx
nsTextFrame stores text as single byte character array if all characters are
less than U+0100. Although, this saves footprint, but retrieving and modifying
text needs converting cost. Therefore, if it's created for a text node in
<input> or <textarea>, it should store text as char16_t array.
MozReview-Commit-ID: 9Z82rketT7g
--HG--
extra : rebase_source : 59f59ac1488c21a57d95d253cc794a011d672c95
This ensures that if the scroll event triggers style changes, they are
reflected on the same paint.
This is accomplished by having the refresh driver fire scroll events as
an explicit step after FlushType::Style observers and rAF callbacks, and
before the actual style flush.
MozReview-Commit-ID: 4kgauD5SgVo
--HG--
extra : rebase_source : 5f2c869c0749c1e1473797f2e202c075907a45fd
