Using namespace id fixes this issue because in Gecko, the pref of MathML
(as well as SVG) works in the way that we choose a different namespace
id (the disabled id) for the elements. Those ids are mapped to the same
namespace atom as normal ids, which means if we use the atom, we would
treat the elements like normal mathml elements.
MozReview-Commit-ID: 9YBBokbP04M
--HG--
extra : rebase_source : 397f09db41a22bfa34e4abe26ad10027dab83d0d
Using namespace id fixes this issue because in Gecko, the pref of MathML (as well as SVG) works in the way that we choose a different namespace id (the disabled id) for the elements. Those ids are mapped to the same namespace atom as normal ids, which means if we use the atom, we would treat the elements like normal mathml elements.
https://bugzilla.mozilla.org/show_bug.cgi?id=1388881
Source-Repo: https://github.com/servo/servo
Source-Revision: 1877cac477770c5908f4b9983adaf7108a361e6e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 5be2c9ddb0f8745f4c7e4f8905949800f4b63e76
When range is selected table element, Selection.addRange uses nsFrameSelection. If frame isn't constructed yet, addRange throws NS_ERROR_FAILURE even if table element isn't editable element.
When getting nsITableCellLayout, we should flush frame to construct cell frame.
MozReview-Commit-ID: 9qWwW46RYNL
--HG--
extra : rebase_source : 708e78af457a28bc273b83015f78950a5bee232e
When recycling chunks, mozjemalloc tries to avoid keeping around more
than 128MB worth of chunks around, but it doesn't actually look at the
size of the chunks that are recycled, so if chunk larger than 128MB is
recycled, it is kept as a whole, going well over the limit.
The chunks are still properly reused, and further recycling doesn't
occur, but that can limit other mmap users from getting enough address
space.
With this change, mozjemalloc now doesn't keep more than 128MB, by
splitting the chunks it recycles if they are too large.
Note this was not a problem on Windows, where chunks larger than 1MB are
never recycled (per CAN_RECYCLE).
--HG--
extra : rebase_source : 6765fd30b78ca5ddc7d55aac861355d960e47828
Despite the comment, this was necessary only for a direct convolver stage,
which has been removed:
https://hg.mozilla.org/mozilla-central/rev/e66105937eef190dec073f1b9859e07a0272706b#l4.29
FFT convolver stages pad the buffer to the necessary length in
FFTBlock::PadAndMakeScaledDFT().
MozReview-Commit-ID: LqP1x1hmLOM
--HG--
extra : rebase_source : 622e16140b62ca748a31cbd318f881c617baf17a
CompositionTransaction forgets to call EndBatchChanges when GetSelectionController returns error, so we should use RAII class instead.
MozReview-Commit-ID: HI9kutRVzx6
--HG--
extra : rebase_source : d276f4349c5a64d4610581ae1a76d160841f7d7b
When recycling chunks, mozjemalloc tries to avoid keeping around more
than 128MB worth of chunks around, but it doesn't actually look at the
size of the chunks that are recycled, so if chunk larger than 128MB is
recycled, it is kept as a whole, going well over the limit.
The chunks are still properly reused, and further recycling doesn't
occur, but that can limit other mmap users from getting enough address
space.
With this change, mozjemalloc now doesn't keep more than 128MB, by
splitting the chunks it recycles if they are too large.
Note this was not a problem on Windows, where chunks larger than 1MB are
never recycled (per CAN_RECYCLE).
--HG--
extra : rebase_source : f81e94c6960ba253037f77de1a39c9ff74651e80
This is an imperfect workaround. Ideally we'd want layout to determine the
correct color here: If the pushed layer will end up on something mostly opaque
in the outer layer, the font smoothing background color should be transparent
(or even a color that approximates that opaque content), and if the pushed
layer will end up on transparency in the outer layer, the appropriate font
smoothing background color for the outer layer should be used when drawing text
in the pushed layer.
This workaround causes us to lose subpixel AA in background tabs that have the
overflow mask applied to them. For those, using the font smoothing background
color in the pushed layer was the right choice.
MozReview-Commit-ID: FPufh04EVp3
--HG--
extra : rebase_source : 7a6cb73255bdb7f1b8aba7df60ebe61171275da4
We will dispatch decoding tasks in Handle{Audio,Video}Decoded() instead.
See comment 0 for the rationale.
MozReview-Commit-ID: 9trJYoMfzJH
--HG--
extra : rebase_source : 0fae6eda31571d34268f2dba58a8e5f6cf0dadc9
extra : source : 275964a63b741e4ac0258e714f54f43d5cc6ae0b
Following P1, cache suspend status changes will be notified when necessary.
If not, it would be a bug that should be fixed. We shouldn't wallpaper the
issue by calling NotifySuspendedStatusChanged() manually.
MozReview-Commit-ID: 9EbybTiOOIO
--HG--
extra : rebase_source : 299e22c6813f4eeb152c4d8140dc295ff856dc1e
extra : source : 2b18fe0368c6332d0b5c1e044218a26c75314124
This is a workaround to fix bug 687972. It should be OK now to remove
it since we have fix bug 1108960 where MediaCache failed to run the
update loop to update the suspend status of the stream.
MozReview-Commit-ID: MbInehhScs
--HG--
extra : rebase_source : 94345a00af31834db8b9858cdf5a9e889044156a
extra : source : 70f626894c3a15c8077f70425a97004478caa9e1
It would be less accurate to call SetReadMode(MediaCacheStream::MODE_PLAYBACK)
in ChannelMediaDecoder::MetadataLoaded() instead of DecodeMetadataState::OnMetadataRead()
because MDSM might have started decoding by the time 'metadata loaded' event arrives
in the main thread. However this little inaccuracy should be fine since it only
affects a small amount of data concerning the eviction algorithm.
MozReview-Commit-ID: JoQMGr5Fvge
--HG--
extra : rebase_source : 3663a028522cc8b973964f62e59d7568a5eba10a
extra : source : 359b4454633432d3334a106aedb267a2451afb45
<!-- Please describe your changes on the following line: -->
Use the new `ComputedUrl` type for computed types and `SpecifiedUrl` for specified types instead of using the `SpecifiedUrl` implementation for both.
---
<!-- 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#17625 (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because this is an implementation change and tests already exist.
<!-- 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: 8a48578a2601769d61ab6f8429e7b1ecb19cbb84
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 8e64001c6f6116b88cf25e54bdcfaa5632a83539
We accidentally left mochitest clipboard enabled only for try, this removes its tier setting of 2 on windows 7, and makes it run wherever the corresponding builds run.
MozReview-Commit-ID: I2ybhqPtswV
--HG--
extra : rebase_source : 2516f6bce22e66a3444ac8c61231a47a74de3c0c
<!-- Please describe your changes on the following line: -->
This is a preliminary refactoring in preparation for only rebuilding cascade data for origins that have a change. https://bugzilla.mozilla.org/show_bug.cgi?id=1382925
---
<!-- 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
- [ ] These changes fix #__ (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: ca14848711884a15a352ec5453df3d83574036a5
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : da603047dcb33bc29a2d5e4a01c2460b5e421400
We should have CI Lint YAML files in the tree.
MozReview-Commit-ID: GN5pOJCXvnz
--HG--
extra : rebase_source : 15509426d82ccbe647172274f9d6d80aa913bdf6
We should have CI Lint YAML files in the tree.
MozReview-Commit-ID: F8hTBerSNIj
--HG--
extra : rebase_source : b3b420eb4f66e448e41de4b556c200e1bd590094
We should have CI Lint YAML files in the tree.
MozReview-Commit-ID: ATX5IOK747y
--HG--
extra : rebase_source : 493c6c762e3b26f1295205c0300df8b0cd87bc7b
We should have CI Lint YAML files in the tree.
MozReview-Commit-ID: IMOKGhxKFJW
--HG--
extra : rebase_source : 0ef71f24141a531833d48f2a305183dd808f00f5
We should have CI Lint YAML files in the tree.
MozReview-Commit-ID: 758kdSddjJN
--HG--
extra : rebase_source : f057b0ce281adb67a156235b051a371a252bd22c
We should have CI Lint YAML files in the tree.
MozReview-Commit-ID: L83j6SODA3w
--HG--
extra : rebase_source : 2be273b518f3424d62f4a90cebe25a3c2833c8a0
We should have CI Lint YAML files in the tree.
MozReview-Commit-ID: HYVWXzNnnzG
--HG--
rename : tools/lint/flake8_/__init__.py => tools/lint/yamllint_/__init__.py
extra : rebase_source : 635ef617eeba1cd1299366beb0c83232d42f0258
Sylvestre Ledru
Sebastian Hengst
Xidorn Quan
Makoto Kato
Dão Gottwald
Manish Goregaokar
Mike Hommey
Karl Tomlinson
Phil Ringnalda
Markus Stange
JW Wang
Fausto Núñez Alberro
Ryan VanderMeulen
Dennis Schubert
Justin Wood
Cameron McCormack
James Cheng