<!-- Please describe your changes on the following line: -->
Sub-PR of #19015
---
<!-- 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#19742 (github issue number if applicable).
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests
<!-- 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: 2ff3e119faab0488ebd4d790600d07695404f883
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 01b2a9b44500eca908d8d8ddd3ce956b2b214a3d
It is bogus, because it depends on the display property as it's cascaded, but
the display property can change afterwards, for example, if we get blockified
because we're the root element or a flex item.
Replace it with a normal field instead.
Also, it carries some weight, because it's the last property that uses this
concept of "derived" property, and "custom cascade". So we can remove some code
after this.
Compute it after the cascade process in StyleAdjuster.
Source-Repo: https://github.com/servo/servo
Source-Revision: f2036e7661a3f865b38d8296cc1b8ab98e60f679
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 0206357b95137b0ebb8533d71d7a705faf781e60
It's kind of a mess. See individual commits for details.
Source-Repo: https://github.com/servo/servo
Source-Revision: 032fd388e4efdd9ecc682877d017b9d2f78e29e2
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : f365989a4d7c713caf92ed0ef34a228a6243644e
A single color in the color list renders just as border-bottom-color.
This used to have two colors, but was changed in [1], so now it can go away.
[1]: https://hg.mozilla.org/mozilla-central/rev/cfdf310748918c3d5eadc16daa5153091e325995
MozReview-Commit-ID: LDocmCwjkzw
--HG--
extra : rebase_source : 0b5027434d7a964165f547c3c67f31045ecc3df4
Implement this change in the Performance Timeline API https://github.com/w3c/performance-timeline/issues/66
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] There are tests for these changes
Source-Repo: https://github.com/servo/servo
Source-Revision: f866e1aacb5bcf17a7d11c6106d34b474d6b4f33
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 55e08a3e9a94522e4e53acbb39e8f737171837c1
The spec changed in order to align with the error thrown by importNode.
--HG--
rename : dom/tests/mochitest/webcomponents/test_bug1176757.html => dom/tests/mochitest/webcomponents/test_shadowroot_clonenode.html
In order to write tests, I would like to create an method that allows chorome js can directly set the user-activation flag.
Therefore, I need to move all these details into nsDocument, then we could easily simulate the user activation.
MozReview-Commit-ID: 5JrCoQc0vF7
--HG--
extra : rebase_source : 256ff2993ef754dc51409e7e444b868a3302bd65
This is a sub-PR of #19015
r? emilio
For the `fn set_original_display` inside `properties.mako.rs`, I removed `is_item_or_root` first to see how the tests result is. If it's needed, I'll add it back.
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#19697
- [x] These changes do not require tests
Source-Repo: https://github.com/servo/servo
Source-Revision: 1b46e2e7597e90a41c6bfb3bd7008bdd922c93c6
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : fd06f9afbcc05acfe20eb48096e421d7dd5b3c2e
The forthcoming window tracking refactoring introduces the new
abstractions ContentContext and ChromeContext that to a large extent
share the same interface. They make it possible to interact with
both types of browsing context in a uniform manner.
Marionette currently has a lot of convoluted if-conditions to
paper over the differences between ChromeWindow, <xul:browser>,
and browser.Context. Examples of this includes the assert.window
and assert.contentBrowser assertions: they essentially perform the
same job, but does not share the same API because the underlying
APIs they call are different.
In an effort to prepare Marionette for the window tracking refactoring,
this patch adds a bit of glue to combine them both into one assertion
called assert.open. This checks that the browsing context has not
been discarded.
MozReview-Commit-ID: K5e7Sr1mq0
--HG--
extra : rebase_source : dcdb730515760da28acb6c8384ff45c202e0da08
Currently, TSFTextStore::GetTextExt() refers mComposition for doing its own
hack. However, this means that it refers composition in TIP. However,
query event is computed with content information. So, even if TSFTextStore
dispatched eCompositionCommit event, it may not be handled by content yet.
In this case, we need information relative to last composition string.
So, TSFTextStore::GetTextExt() should refer IsHandlingComposition() and
last composition string information stored by mContentForTSF.
MozReview-Commit-ID: KMqrDmnUldU
--HG--
extra : rebase_source : cea97c9e9117028913cf45e4dc1e83e2b4f102e9
If remote process hasn't handled dispatched commit event yet, TSFTextStore
needs to dispatch query content event relative to latest composition string
information. So, TSFTextStore::mContentForTSF should cache composition start
and composition string length until pending composition events are handled
by content actually.
MozReview-Commit-ID: ARM851nNZGz
--HG--
extra : rebase_source : d4f1ddb197d3168f2db52849b2982779c388e2e8
Currently, ContentCacheInParent uses selection when it handles query content
event whose input offset is relative one after sending eCompositionCommit(AsIs)
event but it's not yet handled by the remote process. However, in this case,
selection may not be modified with committed string.
So, when mPendingCommitCount is not 0, ContentCacheInParent should compute
absolute offset with the latest composition string information. For doing
this, it needs to keep storing mCompositionStart until eCompositionCommit(AsIs)
is handled in the remote process actually.
MozReview-Commit-ID: 2Dc69HNIbvh
--HG--
extra : rebase_source : 4be432ad363022e4b3f2e3c82c8d229dc9af889d
When composition events are handled by content actually, widget receives
NOTIFY_IME_OF_COMPOSITION_EVENT_HANDLED notification. If focused content
is in a remote process, this is notified only when all sending composition
events are handled in the remote process. So, when widget receives the
notification can there is no composition in IME, that means that nobody is
composing composition at that time.
This patch adds TextEventDispatcher::IsHandlingComposition() which returns
false only when nobody has composition and makes TSFTextStore refer this
method because TSFTextStore needs to know if focused content has composition
in any cases.
MozReview-Commit-ID: F1ZZgFJAArD
--HG--
extra : rebase_source : 65e7f592e0ffd1c516e4dab16ab4ca8d7171f954
To prevent the crash when content-select is enabled, I disable this
assertion that don't allow to call ShowDropDown() in the content
process.
MozReview-Commit-ID: F3BelChp1AK
--HG--
extra : rebase_source : 2bbec4dceffb7698804609010127b37442a907a7
For top level frame, it should also be activated when user activate its child frame.
eg. A (youtube.com) -> B (ad.com), when user activate B frame, the A frame would also be activated.
MozReview-Commit-ID: BP7eGKiqYJe
--HG--
extra : rebase_source : 8a07e2a46d70957989168a9ee677e5241fee61fe
After landing bug 1375910, input.value = "" doesn't remove inter text node.
When value is empty, SelectAllOrCollapseToEndOfText will set selection to
end of text. But since empty text node is still exist, it select all nodes,
instead of collapsed. So if text node is empty, we should collapse selection.
MozReview-Commit-ID: Gm0AP6YSJIg
--HG--
extra : rebase_source : fa7ecda9761f1e202b0a4600968c2e1151220fc3
After landing bug 1356263, no one uses HAVE_I18N_LC_MESSAGES. So it is
unnecessary to check LC_MESSAGES.
MozReview-Commit-ID: IPgl3rQ2qrd
--HG--
extra : rebase_source : 542ada2cf9ac2775855bba29f39044b55fa93f20
Add a geckoview-docs job that executes "./mach android geckoview-docs",
which takes care of calling gradle to generate the javadoc archive, and
uploading it to Github using given parameters.
MozReview-Commit-ID: DTWh4XdFZEO
--HG--
extra : rebase_source : 9d75be24cb553b3a773d3d34a2bdbdf4d4c8cd34
Add a './mach android geckoview-docs' command that generates javadoc for
GeckoView using Gradle. Specifying the '--archive' option will generate
a geckoview-javadoc.jar archive. Specifying the '--upload' option,
intended primarily for Taskcluster, will upload the javadoc to Github
pages under the given user/repository.
MozReview-Commit-ID: HfwXlf8aFhw
--HG--
extra : rebase_source : 25ccbf3380ba2c8f391c48c882256f970be92c9f
Add some missing lines and fix some mistakes in our javadoc comments.
MozReview-Commit-ID: 9Q7qWJJ51Vo
--HG--
extra : rebase_source : afc70812b26de19e610412df014070b75c46017b
Tweak the javadoc task arguments to not generate errors for a standard
GeckoView javadoc run.
MozReview-Commit-ID: 931xCtUcX6N
--HG--
extra : rebase_source : 51e13cd4ec4a0ad9ec91e3bf2b52768aa6ba5e16
Igor Gutorov
Marco Bonardo
Emilio Cobos Álvarez
Patrick Brosset
Fernando Jiménez Moreno
Gurzau Raul
Csoregi Natalia
Jessica Jong
Stone Shih
Alastor Wu
Makoto Kato
Narcis Beleuzu
ffxbld
Noemi Erli
CYBAI
shindli
Jonathan Kew
Andreas Tolfsen
Adrian Wielgosik
Dão Gottwald
Simon Sapin
Scott Wu
Masayuki Nakano
KuoE0
Munro Mengjue Chiang
Glenn Watson
DimiL
Jim Chen