This hides the changes in #20391 from Gecko builds that use the malloc_size_of crate.
Source-Repo: https://github.com/servo/servo
Source-Revision: c0bf170a11f61e721ee88d661fa0d97a464fbb69
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : e2e29829d3301d5d290d549700e5caff00e99137
1. Add testShowWithXXX tests to test PaymentRequest.show() with
PaymentDetailsUpdate promise.
2. Improve the test case implementation by removing the redundant code.
--HG--
extra : histedit_source : 9c68ba8eb6ea4db7e6a158baf19f170b5736a9db
1. Add "optional Promise<PaymentDetailsUpdate> detailsPromise" as a parameter
of PaymentRequest.show() in PaymentRequest.webidl.
2. Let PaymentRequest inherit from PromiseNativeHandler, and implement the
ResolvedCallback() and RejectedCallback() to handle the PaymentDetailsUpdate
promise.
3. Update PaymentRequest.show() implementation. If PaymentDetailsUpdate Promise
is not nullptr, the show request would not be transferred to chrome process
immediately until the promise is resolved/rejected.
4. Update selectedShippingOption when requestShipping is true.
5. Change the PaymentMethod id validation sequence according to the spec.
--HG--
extra : histedit_source : e591c759037cce4f66701b2faa5ecbe01c00e246
There's no reason to ask GL since we should know the answers.
Also GL is tricky on how it handles these semi-deprecated queries.
Official GL stance is "don't ask questions you know the answer to".
MozReview-Commit-ID: F7p73eSTrYw
The CSS for page action icons doesn't handle fallback when only one variable
is defined, so for widgets that don't define their icons using CSS, we always
need to provide both.
MozReview-Commit-ID: 7UgMSVS3W6K
--HG--
extra : rebase_source : d8e38c256b45efecf04f1e20b5fcc6024e839f25
Each nsStaticAtomSetup contains a pointer to a static atom, and also a pointer
to the canonical pointer to that static atom. Which is pretty weird! The
notable thing thing about it is that these structs are in an array, and that
gives us the only way to iterate over all static atoms in a single class, for
registration and lookups.
But thanks to various other recent changes to the implementation of static
atoms, we can now put the static atoms themselves into an array, which can be
iterated over. So this patch does that. With that done, nsStaticAtomSetup is no
longer necessary.
According to the `size` utility, on Linux64 this reduces the size of libxul.so
by the following amounts:
> text: 62008 bytes
> data: 20992 bytes
> bss: 21040 bytes
> total: 104040 bytes
- The bss reduction is one word per atom, because the canonical static atom
pointers (e.g. nsGkAtoms::foo) have moved from .bss to .data, because they're
now initialized at compile time instead of runtime.
- The data reduction is one word per atom, because we remove two words per atom
for the nsStaticAtomSetup removal, but gain one word per atom from the
previous bullet point.
- I'm not sure about the text reduction. It's three words per atom. Maybe
because there is one less relocation per atom?
Other notable things in the patch:
- nsICSSAnonBoxPseudo and nsICSSPseudoElement now inherit from nsStaticAtom,
not nsAtom, because that's more precise.
- Each static atoms array now has an enum associated with it, which is used in
various ways.
- In the big comment about the macros at the top of nsStaticAtom.h, the pre-
and post-expansion forms are now shown interleaved. The interleaving reduces
duplication and makes the comment much easier to read and maintain. The
comment also has an introduction that explains the constraints and goals of
the implementation.
- The SUBCLASS macro variations are gone. There are few enough users of these
macros now that always passing the atom type has become simpler.
MozReview-Commit-ID: 1GmfKidLjaU
--HG--
extra : rebase_source : 2352590101fc6693ba388f885ca4714a42963943
For nsCSSAnonBoxes.cpp, nsCSSPseudoElements.cpp, nsDirectoryService.cpp, the
corresponding .h file includes nsStaticAtom.h. For the other files in this
patch, nsStaticAtom.h is not needed at all.
MozReview-Commit-ID: IpMmbXwZHhu
--HG--
extra : rebase_source : 46d0a6b40a41ee233adad7c205cf907fa27de34a
At least on some devices, there seems to exist some sort of intermediate danger
zone where the intent is no longer large enough to be rejected outright by the
OS, but still big enough to render Firefox inoperable through some sort of
resource exhaustion.
From Android 6.0 onwards, this doesn't matter as otherwise we would have crashed
anyway, but on previous Android versions a much too large intent will simply be
ignored, so if we truncate, but not enough, this actually makes matters worse.
The value used in this patch was chosen by attempting to share the whole
contents of planet.mozilla.org on a Samsumg S3 Mini running Android 4.1.2.
90k characters led to resource exhaustion and the screen turning black, while
85k characters still worked. On a more modern phone, even larger amounts (e.g.
100k characters, like Chrome) worked. Therefore, to have some additional margin,
a maximum limit of 80k characters will be used.
MozReview-Commit-ID: 6etHe0KUgig
--HG--
extra : rebase_source : 5f712da6cf53572dfa5c755ef097a5961a0be891
<!-- Please describe your changes on the following line: -->
When using `ports/servo` as a starting point for an embedding, it's easier if it only relies on the `libservo` crate and not directly on `components` ones. Since `libservo` reexports all the modules we need, it's a straightforward fix.
---
<!-- 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 There are no relevant tests, and no real code change.
<!-- 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: f7a495afa71d6053d9843677f1f53b8002bc8194
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 764b5fac18fc8ca927b4ee7c835f22912445b489
If we know that we don't have anon children it is pointless to go through FFI.
Source-Repo: https://github.com/servo/servo
Source-Revision: 107fd47b93e5e8586ca27293052b9fedc75b88e4
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : c7cb1f3136acb43480759412d087f2b48c332bb5
This limits screensharing simulcast to a single layer. When window sharing, our
source video can have arbitrary dimensions. If one of those dimensions ends up
being odd, the aspect ratio of the smaller layer will not match the aspect ratio
of the odd sized layer, causing a runtime assertion failure and crash.
It is not sufficient to prevent the creation of odd sized layers in
CreateEncoderStreams because the user can resize the window while it is being
shared, which will cause a fatal assertion prior to the streams being recreated.
When switching back from window sharing to camera, a call to
CreateEncoderStreams will occur with resolutions matching the dimensions of
the window that was just shared. To prevent a crash, this also adds a check
which prevents the creation of layers with odd resolutions.
Looking at cricket::GetSimulcastConfig for the version of webrtc.org in tree,
the number of simulcast layers is limited to one, or two if a field experiment
is enabled. That code also limits resolutions at which screensharing is allowed
as well as the number of layers that can be created for each resolution, and
ensures that each layer is exactly half the size of the layer above.
Adding these new constraints to CreateEncoderStreams makes us more consistent
with what the webrtc.org code would do when creating streams, which should
help to avoid more assertion failures in the future. Long term, I believe we
should just switch to using cricket::GetSimulcastConfig.
MozReview-Commit-ID: 8gjdY5GPPjl
--HG--
extra : rebase_source : 5a22f6d0a995303e6a4039eafc056631fbb86415