There's nothing that makes sense in the existing setup; we're only not
getting bitten because the set of things that _do_ depend on all of
the flags that differ between the underlying Nightly builds and
single-locale repacks is small, and nobody has complained. For
example, about:licenses probably does not include the Adjust SDK
license for single-locale repacks.
This patch series recompiles the Java code as part of each
single-locale repack, and that means the feature flags, etc, need to
be the same between the underlying compiled code (from the underlying
Nightly build) and the fresh Java compile. This patch tries to
harmonize the two.
MozReview-Commit-ID: 230q7HuD1vV
--HG--
extra : rebase_source : 1be8a389ed289c788add4d3e95c540f29165cf6b
extra : source : d7f794ec69ccd38d66ec5394fac7cc6658e29ce4
I'm seeing "try" in my repacks, when the underlying build has
"nightly-try". This should make the two agree.
MozReview-Commit-ID: 45yE9Qwz0v7
--HG--
extra : rebase_source : ff1ae4e50203ea032032069203558d75d348ff21
Single-locale repacks need to run aapt (--without-gradle) or Gradle
(--with-gradle). When running --with-gradle, they need to compile the
Java source code again (in order to produce a fresh R.java with
correct IDs). That compile will be part of the shipping APK, so it
needs to be configured "the same" as the underlying repacked. *This
is a significant change in behaviour, but necessary to support newer
Gradle/aapt versions, which do not maintain R.java ID mappings across
invocations.*
Part of the configuration are the secret keys and features that are
gated on them. This commit makes those secrets available to
single-locale repacks.
MozReview-Commit-ID: 4REPsIb5TgN
--HG--
extra : rebase_source : 2d23e0e0c51a61e50acf24123b316bdbb0b579ff
extra : source : a721890f7573140ca6a926e722bd3538c732dae7
Single-locale repacks do the following:
Download existing APK; unzip APK; update l10n resources; |mach package| with IS_LANGUAGE_REPACK=1.
This is pretty hard to accommodate, but we can try. The key issues
here are to recognize when IS_LANGUAGE_REPACK=1 and not ask for l10n
resources (in particular, strings.xml) to be generated.
We do need to include the freshly built classes.dex when repackaging,
because newer Gradle/aapt doesn't preserve the R.java IDs.
MozReview-Commit-ID: 9FvQtmPOUjg
--HG--
extra : rebase_source : b0440ceb318662bf3c08f2139c51dae5775a6b38
Basically, widget code shouldn't access API in dom/events as far as possible
since it's difficult to care widget code when other developers to change under
dom/.
This patch backouts the patch for bug 1402461 which made GeckoEditableSupport
depend on EventStateManager in dom/events. Now, necessary information is in
InputContextAction and same condition should be shared with Windows.
MozReview-Commit-ID: LMlrizswxUj
--HG--
extra : rebase_source : c13604eac143ec5994c65571bff09887d5c0c221
Currently, widget doesn't show VKB when input context change is caused by JS.
However, if it's caused by an event handler of a user input, user may expect
to open VKB. For example, if a touch event in fake editor causes moving
focus to actual editable node, user expect to show VKB.
Therefore, InputContextAction should declare two causes. One is unknown but
occurred during handling non-keyboard event. The other is unknown but occurred
during handling keyboard event.
However, EventStateManager doesn't have an API to check if it's being handling
a keyboard event. Therefore, this patch adds it first.
AutoHandlingUserInputStatePusher sends event type to StartHandlingUserInput()
and StopHandlingUserInput() of EventStateManager and sUserKeyboardEventDepth
manages the number of nested keyboard event handling. Therefore,
EventStateManager::IsHandlingKeyboardInput() can return if it's handling a
keyboard event.
IMEStateManager uses this new API to adjust the cause of changes of input
context.
Finally, InputContextAction::IsUserInput() is renamed to IsHandlingUserInput()
for consistency with EventStateManager and starts to return true when the
input context change is caused by script while it's handling a user input.
MozReview-Commit-ID: 5JsLqdqeGah
--HG--
extra : rebase_source : 9fcf7687d1bf90eeebbf6eac62d4488ff64b083c
There's nothing that makes sense in the existing setup; we're only not
getting bitten because the set of things that _do_ depend on all of
the flags that differ between the underlying Nightly builds and
single-locale repacks is small, and nobody has complained. For
example, about:licenses probably does not include the Adjust SDK
license for single-locale repacks.
This patch series recompiles the Java code as part of each
single-locale repack, and that means the feature flags, etc, need to
be the same between the underlying compiled code (from the underlying
Nightly build) and the fresh Java compile. This patch tries to
harmonize the two.
MozReview-Commit-ID: 230q7HuD1vV
--HG--
extra : rebase_source : 40bdac7073614fcb366e97b733ad98afb4f2dfb4
extra : source : d7f794ec69ccd38d66ec5394fac7cc6658e29ce4
I'm seeing "try" in my repacks, when the underlying build has
"nightly-try". This should make the two agree.
MozReview-Commit-ID: 45yE9Qwz0v7
--HG--
extra : rebase_source : 8b524470680e248c649bf3e4e532cdd5487ec538
Single-locale repacks need to run aapt (--without-gradle) or Gradle
(--with-gradle). When running --with-gradle, they need to compile the
Java source code again (in order to produce a fresh R.java with
correct IDs). That compile will be part of the shipping APK, so it
needs to be configured "the same" as the underlying repacked. *This
is a significant change in behaviour, but necessary to support newer
Gradle/aapt versions, which do not maintain R.java ID mappings across
invocations.*
Part of the configuration are the secret keys and features that are
gated on them. This commit makes those secrets available to
single-locale repacks.
MozReview-Commit-ID: 4REPsIb5TgN
--HG--
extra : rebase_source : 9a74ea5f6633d1a4bd52d6116b60edaf974d11eb
extra : source : a721890f7573140ca6a926e722bd3538c732dae7
Single-locale repacks do the following:
Download existing APK; unzip APK; update l10n resources; |mach package| with IS_LANGUAGE_REPACK=1.
This is pretty hard to accommodate, but we can try. The key issues
here are to recognize when IS_LANGUAGE_REPACK=1 and not ask for l10n
resources (in particular, strings.xml) to be generated.
We do need to include the freshly built classes.dex when repackaging,
because newer Gradle/aapt doesn't preserve the R.java IDs.
MozReview-Commit-ID: 9FvQtmPOUjg
--HG--
extra : rebase_source : 6a34a8c299138ea39c6703f334c8fd5f49b03237
* In the first stage, we fetch changed records, newest first, up to the
download limit. We keep track of the oldest record modified time we
see.
* Once we've fetched all records, we reconcile, noting records that
fail to decrypt or reconcile for the next sync. We then ask the store
to apply all remaining records. Previously, `applyIncomingBatchSize`
specified how many records to apply at a time. I removed this because
it added an extra layer of indirection that's no longer necessary,
now that download batching buffers all records in memory, and all
stores are async.
* In the second stage, we fetch IDs for all remaining records changed
between the last sync and the oldest modified time we saw in the
first stage. We *don't* set the download limit here, to ensure we
add *all* changed records to our backlog, and we use the `"oldest"`
sort order instead of `"index"`.
* In the third stage, we backfill as before. We don't want large deltas
to delay other engines from syncing, so we still only take IDs up to
the download limit from the backlog, and include failed IDs from the
previous sync. On subsequent syncs, we'll keep fetching from the
backlog until it's empty.
Other changes to note in this patch:
* `Collection::_rebuildURL` now allows callers to specify both `older`
and `newer`. According to :rfkelly, this is explicitly and
intentionally supported.
* Tests that exercise `applyIncomingBatchSize` are gone, since that's
no longer a thing.
* The test server now shuffles records if the sort order is
unspecified.
MozReview-Commit-ID: 4EXvNOa8mIo
--HG--
extra : rebase_source : f382f0a883c5aa1f6a4466fefe22ad1a88ab6d20
The test captures the existing logic in `_processIncoming`, even though
it's not quite correct:
* First, we fetch all records changed since the last sync, up to the
download limit, and without an explicit sort order. This happens to
work correctly now because the Python server uses "newest" by
default, but can change in the future.
* If we reached the download limit fetching records, we request
IDs for all records changed since the last sync, also up to the
download limit, and sorted by index. This is likely to return IDs
for records we've already seen, since the index is based on the
frecency. It's also likely to miss IDs for other changed records,
because the number of changed records might be higher than the
download limit.
* Since we then fast-forward the last sync time, we'll never download
any remaining changed records that we didn't add to our backlog.
* Finally, we backfill previously failed and backlogged records.
MozReview-Commit-ID: 7uQLXMseMIU
--HG--
extra : rebase_source : 719ee2d9e46102195251b410f093da3247095c22
This is a sub-PR of #19015
r? emilio
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#19068 (github issue number if applicable).
- [x] These changes do not require tests because _____
Source-Repo: https://github.com/servo/servo
Source-Revision: 107ead64d073f9e13ce2c4477624a20bcd0dd30e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2915fb39cc3e87625c957746a7772ca63257e46e
A close button on the starting page of the devtools onboarding flow
will be helpful for users who triggered the shortcut by mistake and
would like to escape the flow.
MozReview-Commit-ID: 7rZ50jFepJ3
--HG--
extra : rebase_source : 9f0dadf3a68f084d05e9f0098a8a7ac90becf964
While the usage of this capability was optional before, it will
be of help starting with Firefox 58. With this version the
webdriver conformant click will be enabled by default. As
fallback the legacy click should still be able to get selected,
and as such the capability has to be set.
DONTBUILD
MozReview-Commit-ID: 1iU8FPK353N
--HG--
extra : rebase_source : 0c296507d0f7d1884c88bb2f0fbbf267e99f219b
The local device removal path used by RDM had a bug in its `findIndex` call
which caused it to always return `true` for the first device.
Effectively this meant that each separate device removal button always removed
the first device! This would lead to all sorts of user confusion and UI
divergence.
Here we clean this up by allowing the caller (RDM in this case) to specify via a
callback which device is intended for removal.
MozReview-Commit-ID: 22VwEDZAXOa
--HG--
extra : rebase_source : a48b314090a321aa13cf8ca436e2beefa3dcc392
Nick Alexander
Masayuki Nakano
Phil Ringnalda
Ed Lee
Sebastian Hengst
Zibi Braniecki
Matthew Noorenberghe
Jonathan Guillotte-Blouin
Kit Cambridge
Rand Mustafa
Ursula Sarracini
Dave Townsend
Thom Chiovoloni
Francois Marier
Felipe Gomes
Emilio Cobos Álvarez
Edouard Oger
CYBAI
Tim Nguyen
Mike Park
Servo VCS Sync
Julian Descottes
Henrik Skupin
Dão Gottwald
J. Ryan Stinnett