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
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
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
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
With the use of job-defaults, we can avoid a lot of repetition from
those definitions.
--HG--
extra : rebase_source : 932c2ed530aa8aec9a33da60cf652535fa0bd303
The mozharness transform is supposed to set the docker image to
desktop-build when not already set, but was not doing it properly.
I guess this is why some jobs were setting the image themselves, despite
using the mozharness transform.
Consequently, don't manually set the image to desktop-build when it's
the default.
--HG--
extra : rebase_source : 024bd10960bedaee3416785348a5c12498c5286f
See https://bugzilla.mozilla.org/show_bug.cgi?id=1351737#c29
This patch saves more than 80k of code size.
Source-Repo: https://github.com/servo/servo
Source-Revision: 08fc9f190d7e1eaa11560b5924e243ba686c3d79
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 5c71e5e84415f8934a4e72b75e357d1962f82def
