The ceiling was introduced in bug 549190 for improve the consistency of
underline positioning. However, removing ceiling now doesn't seem to
regress the testcases in that bug, probably thanks to improvement in
other part.
The ceiling here causes us to have different font metrics than other
browsers on Windows, and can lead to webcompat issue. We also don't do
this for other backends. So it's probably better removing it in favor
of rounding.
There are several test changes:
* min-intrinsic-with-percents-across-elements.html changes result due to
height of wrapping div in reference page depends on line height, so a
fixed line height is set to work around the issue.
* 368020-1.html changes result because a slightly different line-height
triggers bug 1462514. It is changed to use fixed line-height to work
around the issue.
* 456147.xul is disabled because it compares XUL against HTML page, but
XUL has different approach to position text in its elements than HTML.
Specifically, XUL elements don't seem to respect line height while
HTML elements do. The original line height in the file was probably
chosen to make the HTML match XUL, so it seems to be non-trivial to
fix it in a platform-independent way.
* sizing-orthog-{vlr,vrl}-in-htb-{008,020}.xht fails due to text in <p>
after the testing block shifts 1px up for unknown reason.
MozReview-Commit-ID: 2WJG1AigWl1
--HG--
extra : rebase_source : 540e68ffff618a6dc3c14b3702b2c042988061a3
While working to reproduce the stale content bug with tab warming
I realized that my work here had inadvertently clobbered tab
warming by immediately calling the tab unload code. This wasn't
necessary, and I didn't need to put the cached tab deactivation
code in the unload method, it just seemed initially convenient.
This should make more sense overall.
MozReview-Commit-ID: 9v9dYZTa1Dv
--HG--
extra : rebase_source : fe1d6f4f87df11d5ed495e309a4a0f144bfc2143
To avoid a flash of stale content in the event of a slow tab
switch, we need to make sure we remove a tab from the cache if
its location changes while it's in the background.
MozReview-Commit-ID: ElpoWhhjb0n
--HG--
extra : rebase_source : 615ebd1a57916e0fe2b8c062ab47ffe748397033
This is fairly straightforward, other than the fact that the
nomenclature gets a bit awkward with the aForce parameter on
the ForcePaint methods. I'm not sure which direction to go with
this - "aForce" seems a fairly intuitive name for what we want,
and I'm kind of inclined to say the existing ForcePaint mechanic
should be renamed to something like PaintWithInterrupt, or
PaintWithPriority.
MozReview-Commit-ID: Bj9DROug1pC
--HG--
extra : rebase_source : a3d91fec940d83325d36bafb13fe892e9c9530e8
After digging into this, I'm still not entirely sure why the timing
has changed such that the checks don't work immediately. I have a
strong suspicion though that it's simply because our tab switch is
now instant, resulting in the necessary messages just being a
little bit behind. Hopefully this is an acceptable bandaid.
MozReview-Commit-ID: H1wKW1UQBxp
--HG--
extra : rebase_source : 993c3e97852894ddd64561d039fbf0e71d607066
We maintain a simple LRU cache of tab layers by setting their
docShellIsActive = false with preserveLayers(true). Once they
are pushed out of the cache by more recently used tabs, their
layers are discarded.
Luckily most of the complexity of this could be contained in
the AsyncTabSwitcher - the one change that had to sit outside of
that was moving the aTab.closing = true earlier in the removeTab
call, so that we could use that information to eagerly evict tabs
from the cache. This was to address a leak in a few tests on try.
MozReview-Commit-ID: 2E3uU8LEYkD
--HG--
extra : rebase_source : d2865fd1ee10db17d9f41cca059a5cee697f259d
MOZ_UPDATE_CHANNEL is meant to set the channel to use for the updater,
and nothing else. It's not an indicator of which branch we're building
on and it's not an indicator of whether it's a developer build or a CI
build. The latter seems to be what it's used for for A11Y_LOG, so use
DEVELOPER_OPTIONS instead.
--HG--
extra : rebase_source : 48822af1e4af444e00c89859c51c01c57d130248
For some reason, GNU as is not happy with the assembly generated after
bug 1238661 anymore on Debian armel.
OTOH, as mentioned in bug 1238661 comment 4, we actually don't need this
workaround anymore, so let's just kill it.
--HG--
extra : rebase_source : 6fd06832136d4f840c65f74b63f1c1bec48d525d
In this patch fix not only new animation inspector, but also previous one.
MozReview-Commit-ID: KYdaUXXea70
--HG--
extra : rebase_source : f5a240572a0e7655d3c253c07a28e5fa56fccb9c
We out-of-line the relevant functions because assertions can generate
quite a bit of code, and we'd rather let the compiler determine if these
functions should be inlined now.
