With the MathML refactorings this feature got lost. It would still get
recalculated when explicitly specified as a keyword, but not otherwise.
To avoid hitting the font metrics provider too often, we only do this
when the generic changes. Otherwise we trust the existing calculated
font.
I swear, once Stylo lands I'm going to campaign to remove font-size from CSS entirely. 😩
Source-Repo: https://github.com/servo/servo
Source-Revision: 29f5b226ac6029cfa3806a36e58974b94c12d655
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : feaf14b66482d4ceeb79c4d44c91e38ed3d31d72
Previously, when these properties changed, we'd only send change hints to
recompute overflow areas & trigger DLBI. If the outline was always outside of
the element's border box, this old strategy was generally OK, because the
outline tweak would cause a change to the overflow areas' size, and that would
invalidate the changed area via DLBI & trigger a repaint.
However, for outlines that are *inside* of the element (via negative
'outline-offset'), these change hints were not sufficient, because tweaks to
the outline width & offset will NOT affect the size of the element's overflow
areas and will not trigger any DLBI invalidation.
So in order to correctly handle these changes, we really need to request a
repaint of the affected element, since some piece of the element may need to be
repainted even if it's not changing in size.
MozReview-Commit-ID: J4KGUHrJ09U
--HG--
extra : rebase_source : 677950d5aebdf7e90120b8fe7bb937344da42d7d
They make component/style fail to build, because of `#[deny(warnings)]`
Source-Repo: https://github.com/servo/servo
Source-Revision: b6f5d65bbddc9e8d35016c8669256a8a539b7516
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 626223612f9972e075e3fe92bcb78f220beaff7f
<!-- Please describe your changes on the following line: -->
Fixes unsafe transmute between `AtomicRefCell<PersistentLayoutData>` and `AtomicRefCell<PartialPersistentLayoutData>` which have different memory alignment in 32 bit archs leading to SEGV crashes. See https://github.com/servo/servo/issues/16817 and https://github.com/servo/servo/pull/16816
mem::align_of values in 32 bit archs (e.g. Android):
```
PersistentLayoutData 8
PersistentLayoutData 4
AtomicRefCell<PersistentLayoutData> 8
AtomicRefCell<PartialPersistentLayoutData> 4
```
mem::align_of values in 64 bit archs
```
PersistentLayoutData 8
PersistentLayoutData 8
AtomicRefCell<PersistentLayoutData> 8
AtomicRefCell<PartialPersistentLayoutData> 8
```
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#16817 (github issue number if applicable).
<!-- Either: -->
- [x] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 47e4c48feb12e4189f11fd94631f0abea5827f91
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 51c494d499c304cd69e5504acc1ed8399afada05
aarch64's gcc and arm's gcc with -mfpu=neon defines __ARM_NEON for NEON, so we should detect it to support NEON code.
MozReview-Commit-ID: LRMTQLctuLV
--HG--
extra : rebase_source : 9e09eb9b67824c81dc45198acd6582584a5e1652
ycvcr_to_rgb565 uses inline assember for arm neon. Since it is different for aarch64's assembler, we should define HAVE_YCBCR_TO_RGB565 on arm32 only.
MozReview-Commit-ID: 4c2n1luvVvC
--HG--
extra : rebase_source : 8ae3f9deb6d0f4e3ab6036b7ce7ec57e0c7e1b57
Previously, `mach bootstrap` would unconditionally prompt to help
configure Mercurial in most scenarios. I agree with Ehsan's observation
in a mailing list post that this behavior doesn't make sense when
running from a Git checkout, as the user probably doesn't care about
Mercurial if they are using Git.
This change doesn't completely ignore Mercurial for Git users. For
example, we still unconditionally run code that verifies that Mercurial
is installed and reasonably up to date. Changing this would be a bit
of work. But even if we wanted to change it, git-cinnabar users
would benefit from having a modern Mercurial installed. So it isn't
straightforward for Git users to ignore Mercurial completely.
MozReview-Commit-ID: 8ncHRgCsjz
--HG--
extra : rebase_source : 7945e3bf3d5283105bac517885f794fc5d7bba6d
<!-- Please describe your changes on the following line: -->
Servo part of https://bugzilla.mozilla.org/show_bug.cgi?id=1361258
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [ ] `./mach test-tidy` does not report any errors
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because they're gecko-specific
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 642cd08f21727ee35dc3dace14d0c9ad5837f380
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : ed48f5ce4eb76e854ab7f92723e722d34a695a3d
nsAHttpTransaction::Available() obtained a bytecount from the abstract
transaction's input stream. If that stream was derived from a file://
it would create janky IO - so remove the interface.
Http2Push maintains a non-inherited interface which is used to check
the number of bytes it has internally buffered in memory.
MozReview-Commit-ID: IQHt8yGsqDE
--HG--
extra : rebase_source : 64449c6bd743119ea7626a3b2b2b91a376280021
UAOverridesBootstrapper.js is introduced to delay the initialization of
UserAgentOverrides.jsm until the creation of nsHttpHandler in chrome process.
Uninit will be triggered at profile-change-net-teardown because no network
traffice after this point.
MozReview-Commit-ID: F8Lpn6RyZEm
--HG--
extra : rebase_source : b516209f96ec81deb54aab3c038803beb3cea441
system-info might need to be construct while creating nsHttpHandler and it might take up to 30ms.
Lazy loading the DEFAULT_UA can delay the creation of nsHttpHandler after start-up.
MozReview-Commit-ID: FtIpKjcY38r
--HG--
extra : rebase_source : 8061ed3ce6c42955e52f494166958f5b63ab940b
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#14856 (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: dc8cf694eddca6529bf4b3ac1066764473775192
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2865a2a154d7e8d7b0b5e7f2e6ec499717185fd2
This is also the non-broken way to fix bug 1346392. Instead of waiting
until the auth handler gets its hands on things, we break layering a bit
and inspect the response headers as soon as we decompress them to see if
there's any connection-oriented auth being requested. If there is, we
treat the situation as if we got a RST_STREAM or GOAWAY with
HTTP_1_1_REQUIRED.
We were able to re-purpose the NS_ERROR_ABORT code path that was
previously used with an inappropriate HTTP status code when talking to
an HTTPS proxy over http/2, as that usage was removed a while back from
the stream, though we still had the (dead) code in the session to handle
the stream giving us that return value. The error code was changed to
NS_ERROR_NET_RESET, however, to give a better description of what's
going on.
MozReview-Commit-ID: DLjOIIiXGrV
--HG--
extra : rebase_source : 703fde39432808cabd05b48aa40165e53ebc5ed1
I was going to inline "enable_ccache" into buildbase.py because AFAICT
its value is effectively "if not windows." However, I realized that
all this is doing is dumping ccache stats (something the build system
itself is in a better position to do because it actually knows if
ccache is enabled). Then I realized we don't use ccache directly
any more in automation because we use sccache (or at least that's the
way it should be).
Since there's no need for this ccache code in mozharness, this commit
deletes it. If we want it back, we can add the functionality to
`mach build`.
MozReview-Commit-ID: BrRi1QKe5l3
--HG--
extra : rebase_source : 0e25f372dcdd0cc6ef571bcee5cba675104cd7a4
extra : source : 5e04c49d2d10ad48b19cddaf28fee845dc6e8629
nsAHttpTransaction::Available() obtained a bytecount from the abstract
transaction's input stream. If that stream was derived from a file://
it would create janky IO - so remove the interface.
Http2Push maintains a non-inherited interface which is used to check
the number of bytes it has internally buffered in memory.
MozReview-Commit-ID: IQHt8yGsqDE
--HG--
extra : rebase_source : 78dbd5cae35bc6cb1ce2f03192226cb85564298e
I had removed the USE_YASM define in porting the libvpx
moz.build to libaom, to avoid depending on VPX_USE_ASM.
Turns out USE_YASM is a magic context define, without which
the build won't compile libaom's yasm-format .asm files,
so we need to define it for the two intel architecture
source sets.
Restore the define unconditionally for intel targets.
We require yasm in the default build for those targets,
and want to fail if it isn't available to block performance
regressions.
MozReview-Commit-ID: CqGtY8RNLNf
--HG--
extra : rebase_source : ccc7f9dfc467642d9e4c623c55e54e769fb38f2f
We no longer support 32-bit x86 macOS, and
these flags point to configurations we
don't generate.
MozReview-Commit-ID: 3mIfHCf6aUj
--HG--
extra : rebase_source : 35b5089ade7f9d5d03e5f4d3f0760cc969b4b8c7
JavaScript errors that arise from the Marionette implementation are
currently wrapped as WebDriverErrors. A WebDriverError is encoded with
a "webdriver error" error code, which officially does not exist in the
WebDriver specification.
To distinguish WebDriver errors from programming errors of Marionette,
this changes them to be encoded as UnknownErrors (error code
"unknown error"). This will make stacktraces coming from clients
easier to read, since it is clear that the error is not caught by the
WebDriverError-catchall.
MozReview-Commit-ID: A5HejTOgOp8
--HG--
extra : rebase_source : 7bd4f539954dd11973b2bd16c1bf4f4ea7b4a4d7
For debug builds a delay of 1s is too short. It means that a navigation
command will return when the readyState reaches interactive for an eager
page load strategy. But due to the slowness of the browser, the next
command could already operate on a complete readyState. Delaying the load
of resources is the only possible option.
MozReview-Commit-ID: D2je04Euwf0
--HG--
extra : rebase_source : d74f276d96cd5bd2301f9dac8866f9dadc6e2937
We can bail out earlier before calling an FFI function.
This is a PR for https://bugzilla.mozilla.org/show_bug.cgi?id=1364264 .
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes do not require tests because it's for stylo
Source-Repo: https://github.com/servo/servo
Source-Revision: 875b07b4ec64d9ef01bafb81ecf01496c0b9fa4b
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : f61dc4336198f974eff1fcd7401efbbd899baa00
This slims down SharedStyleContext, in preparation for a few things.
First, I would like to eventually move the stylist to the document in Servo, in
order for it to hold the StyleSheetSet.
Also, this gets rid of a fair amount of overhead while creating it in stylo.
Fixes bug 1363245.
Source-Repo: https://github.com/servo/servo
Source-Revision: eeb1ee9723777b0dc04e919556826eef628363fe
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : e20eedc331b5fa4c6e2fecc140e10f220619deb8
This patch removes the magic number and instead uses the ELEMENT_NODE
constant which exists on all objects of the Node prototype chain.
We already test that obj has a nodeType own property.
MozReview-Commit-ID: If9HIkBjCyN
--HG--
extra : rebase_source : 5b04727b53616c08bf74a4f3acb56c33d827d015
According to a recent change in the WebDriver specification, we need to
return an object's JSON representation iff it exists.
The relevant specification prose change was made in
1ee4c61c11.
This patch causes return values that have a toJSON property that is a
function, to return the value of calling said function.
MozReview-Commit-ID: GpQNE9GpjCH
--HG--
extra : rebase_source : 7192bbd484cbaa4661f2442990082aefcdd1570b
This patch renames element.fromJson and element.toJson to
evaluate.fromJSON and evaluate.toJSON, respectively.
The JSON (de)serialisation code belongs more naturally in the evaluate
module, which did not exist when these functions were written.
MozReview-Commit-ID: FJGbjGD1kZ6
--HG--
extra : rebase_source : b2528f545c8213b06b9116299806d8ab8a875250