PLayerTransaction's constructor was previously synchronous so we could
return a TextureFactoryIdentifier. This is quite reliably available
already in the case of opening a tab, due to RenderFrameParent knowing
which compositor it is attached to, so we can make the constructor
asynchronous.
In the top-level widget case, we add a new synchronous message to find
the TextureFactoryIdentifier.
This is pretty straight-forward.
Sadly, this will require local developers to add a "skin" product
flavor to their invocations, like:
./mach gradle app:assembleLocalAustralisDebug
In addition, this shows how many different variants of the Gradle
product flavor are embedded into our automation configurations. I
can't solve that at this time.
Since I was here, I took the time to rename "automation" to
"official", which makes "localAustralis" the default in Android
Studio, avoiding a common issue with new builders producing an APK
that doesn't include omni.ja in the IDE.
MozReview-Commit-ID: CtU7zFpNCob
This is pretty straight-forward.
Sadly, this will require local developers to add a "skin" product
flavor to their invocations, like:
./mach gradle app:assembleLocalAustralisDebug
In addition, this shows how many different variants of the Gradle
product flavor are embedded into our automation configurations. I
can't solve that at this time.
Since I was here, I took the time to rename "automation" to
"official", which makes "localAustralis" the default in Android
Studio, avoiding a common issue with new builders producing an APK
that doesn't include omni.ja in the IDE.
MozReview-Commit-ID: CtU7zFpNCob
--HG--
extra : rebase_source : 477ef683f850ff11cfa128e17855666bb7758a7a
When you create a <key> element, which is what the commands API
does under the hood to allow keyboard shortcuts, the event type
that the handler listens to defaults to keypress. For printable
characters, the keyCode property of a keypress event is 0,
causing keycode bindings for these printable characters to not
work. We could use key for these properties, but the shift key
interacts with the key property in ways that make it simpler to
simply fix the keycode usage for our purposes.
MozReview-Commit-ID: HdWdN7cMfuq
--HG--
extra : rebase_source : d75aee5472f43575adfb68f201503f9a57c2deea
<!-- Please describe your changes on the following line: -->
I just changed the `prefix` parameters on the constructors of several HTML elements. The type now is `Option<Prefix>`. I also changed the sizes of the `sizeof.rs` unit test to match the new values.
---
<!-- 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#16700 (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [X] These changes do not require tests because it should not affect anything else
<!-- 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: ed7686b42c02c5c1d769be952ef58b285f35a7f6
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : ade76a808b80fcbb1e011c0b6f7a29c37361559e
It seems like the server-side keyring is getting deleted somehow. This
causes syncing of the keyring to fail. We haven't completely
fixed the root problem yet, but this adds logging to try to flag
down the dangerous operation of deleting a bucket to make sure we
aren't doing that by accident. We also try to recover from the
server-keyring-was-deleted situation by wiping all storage.sync data,
the same as if we found a keyring that we couldn't decrypt.
MozReview-Commit-ID: JMB0IxApbGq
--HG--
extra : rebase_source : 54982a374aa5c7d7e60e8175b99734c672b91799
Fixed backgrounds were not being clipped correctly when rendered using
inactive layers.
MozReview-Commit-ID: 3v8tajr3MoB
--HG--
extra : rebase_source : 25329cb9efb998c64924916d4ea496a439688c8d
Use MOZ_FORMAT_PRINTF in toolkit/mozapps/update, and fix the one
erroneous printf that this detected.
MozReview-Commit-ID: 5dzyMOZwNDG
--HG--
extra : rebase_source : b26942181d52b356702c039bcace11dbf900a3d1
Since the order of events is 'blur' followed by 'focus', we send a message from the content process to the parent process and wait for a reply to give enough time for the parent process to signal that the 'blur' was related to the focusing of the search field. If the parent process hasn't signaled as such, then the content process will proceed with hiding the dropdown.
MozReview-Commit-ID: 6ngoo9uHcsM
--HG--
extra : rebase_source : caf43a975827aec71ba82fe39435b05c954673bc
Robert Strong
Phil Ringnalda
Michael Layzell
Ben Hearsum
David Anderson
Boris Zbarsky
André Bargull
Benjamin Bouvier
David Anderson
Gijs Kruitbosch
Wes Kocher
Sebastian Hengst
Nick Alexander
ffxbld
Patrick Brosset
Carsten "Tomcat" Book
Kris Maglione
Mark Banner
Doug Thayer
Brian Grinstead
Christian Poveda
Dão Gottwald
Ethan Glasser-Camp
Jamie Nicol
Tom Tromey
Jared Wein
Cameron McCormack
Alfredo Yang
Jan Beich
Tom Schuster