This shouldn't be at module level.
This isn't technically needed for this series. I caught it during
an earlier attempt at teasing out all Python import dependencies
to run `mach`. Why let a good patch go to waste.
MozReview-Commit-ID: FwwdZqcKtpq
--HG--
extra : rebase_source : a8ce2cf452dc8c03371dc384ea4f1be9195b5d30
The bug is caused by the first call to ResizeReflow in
nsDocumentViewer::GetContentSizeInternal, which reflows the content with
unlimited height. ResizeReflow calls DidDoReflow, which calls a
callback installed by nsHTMLScrollFrame that clamps the scroll port setting
the scroll top to 0 and losing the original scroll top. When the content
is reflowed again to the maximum height, the scroll top stays at 0.
MozReview-Commit-ID: 3VkgWLqSTDP
--HG--
extra : rebase_source : 68c65746e014f0702de82ea576897592b07f81cb
Sometimes, we may get a 2d transform matrix like this:
matrix(0, 1, -1, 0.33, 0, 0)
The reason is we might have "rotate(90deg)" in the test case, so the 1st or
the 4th element could be 0.0, and we shouldn't assume they are 1.0 while
converting matrix2d into matrix3d, or we will get a weird result, like this:
matrix3d(1, 1, 0, 0,
-1, 0.33, 0, 0,
0, 0, 1, 0,
0, 0, 0, 1)
m11 shouldn't be "1" here.
Add a "defined()" function to return the first defined object as the
matrix element because we should be testing the defined-ness, instead of
truthiness.
MozReview-Commit-ID: HSTt2PR02AU
--HG--
extra : rebase_source : 417438239635f9bbf0eb4818b39c611ab90b9a10
In particular, this avoids the stupid calls in display: none roots.
The cache stuff should be unnecessary, but there's still some fishy stuff going
on.
MozReview-Commit-ID: LgnW0k1gmsN
--HG--
extra : rebase_source : b07e1f2533e4a2fc1610f35351fc2964f37e82e2
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