We have about 11,500 of these when loading gmail in a Stylo-enabled build, from
SpecifiedUrls; the objects themselves account for about 1.3 MiB of memory, and
the strings within them about 2.9 MiB.
We also have a very small number of them on the Gecko side.
<!-- 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
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because testing is on the Gecko side.
<!-- 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: 8397c5b0a210a33a0991d369e88016dd51f521fd
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : ac2b08b4d0fd32d0bd95ade03b1f758d674415e4
The variables (basicShapeSVGBoxValues, etc.) in property_database.js are
moved to the beginning of the file so that they're defined before usage.
MozReview-Commit-ID: 7L3obIY1alP
--HG--
extra : rebase_source : 6c3dff5ecbdad8ef6cf1a49953e4ad1001620b6c
`MallocSizeOfOps::enclosing_size_of_op` is an `Option<>` type, and the panic in
question is caused by not providing a value in a case where it's needed for
measuring a HashSet.
HashMaps and HashSets are common enough that it makes sense to make
`enclosing_size_of_op` non-optional, which this patch does.
MozReview-Commit-ID: IB2aRuXHj8E
--HG--
extra : rebase_source : a6f593b718ca9e92a7a36ca7e2063a01e11c7e04
`MallocSizeOfOps::enclosing_size_of_op` is an `Option<>` type, and the panic in
question is caused by not providing a value in a case where it's needed for
measuring a HashSet.
HashMaps and HashSets are common enough that it makes sense to make
`enclosing_size_of_op` non-optional, which this patch does.
<!-- 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
- [ ] These changes fix #__ (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because tests are on the Gecko side.
<!-- 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: bb998dbdf31920d5ddc2a91d6bdfe8a880e11604
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 18ff3083b36733a2a212f094f249b46872b4ec61
Continuation on bug 1397307 which was incomplete.
MozReview-Commit-ID: JGGHQyjnALI
--HG--
extra : rebase_source : 067652250dcd0904c8436eebc50068c7fb8d8cbb
Only the Windows H264 decoder supports CreateDecoderParam::mError, all the other PDM leave the value untouched.
As such, it can't be assumed that in case of failure, the mError attribute will be set.
MozReview-Commit-ID: GWHGP6Wv3fl
--HG--
extra : rebase_source : 081b71c7a53c41d9a13904e4182e3cfdb876ae43
See the individual commits for details.
This is the only coherent story I have for crashes like:
https://crash-stats.mozilla.com/report/index/bcdfe629-ca1f-4e4d-aa17-27f890170917
(And the fact that there are crashes like it on the main thread kinda indicates it's the case)
Source-Repo: https://github.com/servo/servo
Source-Revision: 2387dbedbb27629cd9e8c4657e8328ae04ff6d58
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2cebeca9acb1d40d2bc4eb3d2646f49ba24a3437
In some Android ROMs, MediaCodec doesn't allocate additional buffers to reduce
consumer starvation and will not work when MDSM grips most recently returned
frame before rearching seek target. Implement SetSeekThreshold() to get actual
seek target to check if video buffers can be released back to remote decoder
immediately.
MozReview-Commit-ID: 7IetuVxCXc0
--HG--
extra : rebase_source : 8e8643dbde757d41a26de45663a8232b4c66c386
This reduces sizeof(ImageValue) from 104 to 96. When heap-allocated, this moves
it from the 112 byte bin to the 96 byte bin. Loading gmail with Stylo, there
are about 11,500 ImageValues on the heap, so this saves about 184,000 bytes.
MozReview-Commit-ID: JLe2cJ54IlL
--HG--
extra : rebase_source : 6c74d1d606db0cb1d09392f5585cc1cbadc92ebd
Summary: We're currently using the thread_rng to derive a cmd byte for the U2F protocol fuzzers. That of course should rather be derived deterministically from the input handed to the fuzzing target.
Bug #: 1400513
Differential Revision: https://phabricator.services.mozilla.com/D61
Someone changing the attribute appendWindowStart and appendWindowEnd can be expected to know what they are doing. As such, we don't need to make sure playback starts when content timestamps are broken.
MozReview-Commit-ID: EcPORuDHpF5
--HG--
extra : rebase_source : 2e29f07d8c4c52dfee360bac9e83b4d92b3eae38
Today, only the DOM API is disabled.
When bluetooth is disabled, can we also disable bluetooth device code?
Source-Repo: https://github.com/servo/servo
Source-Revision: 06628d2f6090e069b3447ad1ff09a1158e0836ab
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 3e6d03cd191932346385b0ee89c99277ef1d0bd7
nsLeafFrame only exists as an abstract superclass, and every subclass actually
brings along its own Reflow impl, so nsLeafFrame's own impl is just dead code.
This patch makes sure it's really dead code by leaving in the Reflow() decl
with " = 0;" so the compiler will enforce that all concrete subclasses *do*
have a more specific override (and that they don't just inherit the stub
nsFrame impl from further up the ancestor chain, for example).
MozReview-Commit-ID: Co36IpuaeOc
--HG--
extra : rebase_source : 036caa3abaed0a1cf75e8674af4ae2e8b55b3b8c
(This was the only concrete nsLeafBoxFrame subclass that was missing this
annotation. So, after this patch, all concrete nsLeafBoxFrame subclasses will
have this annotation. Nice!)
MozReview-Commit-ID: Iu1LaLTTqzu
--HG--
extra : rebase_source : d11f0391c9fed77c805b7bfb71cc39ed729a3f8f
* The -Wno-unused-but-set-variable flag is supported by gcc but not clang, so move it to a gcc-only CFLAGS.
* The -Wno-error=uninitialized flag is supported by both gcc and clang, so move it to CFLAGS shared by gcc and clang.
* Also suppress -Wunreachable-code and -Wshift-negative-value clang warnings. gcc supports -Wshift-negative-value, but only starting in gcc 6.1 and we are still using gcc 4.9 in automation.
warning: unknown warning option '-Wno-unused-but-set-variable'; did you mean '-Wno-unused-const-variable'? [-Wunknown-warning-option]
gfx/cairo/cairo/src/cairo-quartz-surface.c:1908:6: warning: code will never be executed [-Wunreachable-code]
gfx/cairo/libpixman/src/pixman-bits-image.c:268:32: warning: shifting a negative signed value is undefined [-Wshift-negative-value]
MozReview-Commit-ID: AnQAsfDaZbk
--HG--
extra : rebase_source : 6dd94a39479e05f67f93d4e4be2bd10ece4df7be
extra : source : 34ddaea5129be2ae1e9faa0a1d905b8690909611
Using ':not' would unduly increase the specificity of the '.subviewbutton > .toolbarbutton-text' rule,
so I went with overriding it instead.
MozReview-Commit-ID: 85o0IcjCgbQ
--HG--
extra : rebase_source : 385bcd09c2cea5c24a99bb23c60da63b5a46749d
We enter the Custom(..) code path from other random places, like to remove the
relative lengths from a calc expression while zooming, or whatever craziness
MathML font-size uses, and we don't want to set the dependency on those cases.
Source-Repo: https://github.com/servo/servo
Source-Revision: 4b4a744265d1bd79f731ff7b9160af9f6af7db2b
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 749b8dbe6c0c46e719d1ab90f6d2c6fcb324233b
The previous drag space was only set as min-height on the titlebar,
which led tabsintitlebar.js to not account that extra space for moving
the titlebar to the bottom (because it calculates that height from
tab strip height). So while it looked fine visually, the titlebar did
not stretch all the way to the bottom, so that e.g. double-clicks aren't
registered correctly.
MozReview-Commit-ID: 1mHFDBUe3sC
--HG--
extra : rebase_source : 667b131485658927fc2f3d484b2ab15cce782d95
This patch changes the test_construction.html with following modification.
1. Modify the test testWithDuplicateShippingOptionsParameters to expect a
TypeError when constructing wiht duplicate shippingOption ids.
2. Add test testShippingOtpionAttribute for shippingOption setting checking
with following conditions
1. No selected shippingOption and PaymentOptions.requestShipping is false
2. One selected shippingOption and PaymentOptions.requestShipping is false
3. One selected shippingOption and PaymentOptions.requestShipping is true
4. Multiple selected shippingOptions and PaymentOptions.requestShipping is
true.
This patch implements the following changes according to the spec change.
See https://w3c.github.io/payment-request/#constructor step 8 for more
details.
1. Return TypeError during PaymentRequest construction with duplicate
shippingOption id.
2. Set PaymentRequest.shippingOption with the selected shippingOption only
if options.requestShipping is true.