* Code in XMLHttpRequestMainThread is converted to set the username and password individually. This is because when the parameters are empty, it ended up calling SetUserPass(":") which always returns an error.
MozReview-Commit-ID: 3cK5HeyzjFE
--HG--
extra : rebase_source : f34400c11245d88648b0ae9c196637628afa9517
We don't use these GUIDs anywhere, and this change lets us kill off some expensive data structures necessary
to maintain lists of successfully uploaded GUIDs, particularly during an upload.
MozReview-Commit-ID: F0kcY8o8DUw
--HG--
extra : rebase_source : e7443ffabde02059008e6c833ee52c45e206ec81
This patch does two things:
- serializes flow of records through the RecordsChannel
- simplifies the batching logic
The two are connected: rather than queuing records in ConcurrentLinkedQueue, we now buffer
downloaded records in an ArrayList, and deliver them to the receiving repository all at once.
Doing this work right at the channel level lets us kill off the buffering middleware.
An addition of a NonBufferingSyncStage lets individual SyncStages use a RecordsChannel which
doesn't perform any kind of buffering. Prior, stages did this by wrapping their receiving repositories
in the buffering middleware.
The main goal is to speed up the flow of records, keep within the same memory footprint
and do some simplification in the process.
This patch explicitly does not address the delegated nature of fetch and store, which is now largely irrelevant.
MozReview-Commit-ID: J2afmgr1Td1
--HG--
extra : rebase_source : 62f5f7940bb8db9a18704edfd0b9cb38eb410b71
There are a lot of choices and moving pieces in this commit. I elected
to include the mechanics and the target use case in the same commit so
that readers can compare and contrast the implementation and final
expression in one review window.
- Initially, I wanted to make the {AB_CD} substitutions in
LOCALIZED_FILES and not in LOCALIZED_GENERATED_FILES. However, I ran
into conceptual blockers doing this. Fundamentally, LOCALIZED_FILES
is FINAL_TARGET_FILES, and my use case should _not_ be putting files
anywhere near dist/bin. In addition, LOCALIZED_FILES
(FINAL_TARGET_FILES) is handled using manifests, which would need to
grow locale-aware functionality to handle this. That's not desirable.
In addition, if we use manifests, then we lose the powerful locality
of |mach build mobile/android{/base}| re-generating changed
locale-dependent resources. This is similar to how the build system
plumbs dist/idl manifest processing throughout the build: we're
repairing local workflows after moving work into a global process.
For these reasons, this doesn't support {AB_CD} in LOCALIZED_FILES.
- There is even another layer of complexity! There are two axes
involved with these files: AB_CD controls localization and the Make
target controls destination. For the record, it is:
regular builds - AB_CD unset
multi-locale builds - AB_CD set
single-locale repacks - AB_CD set
For the record, the existing logic (before any changes) is:
regular builds - Make target is `libs` in mobile/android/base/locales
multi-locale builds - Make target is `chrome-%` in mobile/android/base/locales
single-locale repacks - Make target is `libs` in mobile/android/base/locales
This commit adds targets for both destinations, and uses Make
chrome-%:: and libs:: magic to control what is invoked in the various
situations. Tricky!
- I added MERGE_RELATIVE_FILES in order to be able to follow-up this
patch with more patches that will get rid of
m/a/base/locales/{moz.build,Makefile.in} altogether, and fold this work
into m/a/base. As it stands, we're already reaching from
m/a/base/locales all the way out to
mobile/locales/.../region.properties, so the existing code doesn't
follow the layout expected between mozilla-central and
l10n-central/$(AB_CD). But that'll impedance will get worse as we
improve the build system dependencies, not better, so we should grow
support for localized resources that aren't exactly as expected.
- I chose to follow Python's syntax for string substitutions. I
would have preferred to mark files that should be localized with a
leading '%'... but I took that for filesystem absolute paths in
moz.build files already. I also considered @AB_CD@ to echo the
preprocessor, but didn't want to open the door to an expecation that
_all_ preprocessor DEFINEs will work in the way {AB_CD} does.
- The generate_*py script changes required a bit of a hack to "turn
off" locale dependent resources. This would have been nicer if we had
marked localized resources with '%'... but we didn't. See the
--fallback flag. The real reason this is needed is that we're doing
work which is more like the work of compare-locales (merging
locale-dependent resources) at build-time rather than repack time. I
don't know why that's the case -- probably when we (I) implemented it,
compare-locales and the whole l10n process was entirely opaque. It's
not worth changing it now, so we use this --fallback flag approach.
- I didn't get to tup support. This should gently fail without
breaking tup builds: any {AB_CD} substitutions just won't be
expanded. I haven't a clue how this should work in tup in the future
(or, more generally, how to make any sense of repacks without
declaring the full set of expected locales at configure time.)
- strings.xml can't be a LOCALIZED_PP_FILES, since we need to
customize the output location based on AB_rCD, and since we need a
little more flexibility than PP_FILES gives for our inputs.
MozReview-Commit-ID: MyfIkNSEzt
--HG--
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/en-US/localized-input => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/en-US/localized-input
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/foo-data => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/foo-data
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/generate-foo.py => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/generate-foo.py
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/en-US/localized-input => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/inner/locales/en-US/localized-input
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/moz.build => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/moz.build
rename : python/mozbuild/mozbuild/test/backend/data/localized-generated-files/non-localized-input => python/mozbuild/mozbuild/test/backend/data/localized-generated-files-AB_CD/non-localized-input
extra : rebase_source : 816b6f220758f2bb3bdd3ec81a2cb02269c6de5b
I wanted to lift this next to the definition of AB_CD, but that
doesn't allow to use it in a backend.mk file, due to the order in
which Makefile, config.mk, rules.mk, and backend.mk are processed.
Therefore, I've put it in a tiny include file, so that it can be used
by a Makefile and a backend.mk file.
This allows the `RecursiveMake` backend to owning defining AB_rCD in
backend.mk files, while not requiring consumers to arrange for AB_rCD
in a sibling Makefile.in file.
Other build backends will need to arrange for AB_rCD themselves: see
following commits.
MozReview-Commit-ID: I7GIzRbCCtf
--HG--
extra : rebase_source : 3277fedb43bc3d8007287c223554a085dae2f198
extra : source : 854c0f43a1f74b4e22aa7638b407580240c90dd5
Switch from the old XML-based AMO metadata API to the modern JSON based
API. This turned into something between a modest update and complete
rewrite. Most notably, external APIs became (mostly) promise-based. The
exception is getCachedAddonById() which XPIInstall.jsm requires a
synchronous callback from.
Also, hopefully we will be able to get rid of a bunch of this metadata
handling soon. If this code had a long life ahead of it, the unit tests
could use some more attention, but I mostly did the minimum here just to
keep them running for now with the expectation that we'll be able to get
rid of them within some small number of months.
MozReview-Commit-ID: 3DRaBdWGaiJ
--HG--
rename : services/sync/tests/unit/addon1-search.xml => services/sync/tests/unit/addon1-search.json
rename : services/sync/tests/unit/bootstrap1-search.xml => services/sync/tests/unit/bootstrap1-search.json
rename : services/sync/tests/unit/missing-sourceuri.xml => services/sync/tests/unit/missing-sourceuri.json
rename : services/sync/tests/unit/missing-xpi-search.xml => services/sync/tests/unit/missing-xpi-search.json
rename : services/sync/tests/unit/rewrite-search.xml => services/sync/tests/unit/rewrite-search.json
rename : services/sync/tests/unit/systemaddon-search.xml => services/sync/tests/unit/systemaddon-search.json
extra : rebase_source : f25d78b938768041c5c05b72a1f7ff3a7dee8275
Remove unused imports of AddonRepository.jsm plus some more
leftover bits from in-browser search results.
MozReview-Commit-ID: AZyAtnHvaMP
--HG--
extra : rebase_source : 6085ed3a22bd9a43f8882f604b97aa55b8b788c5
From the point of view of the session itself, this queue is named correctly (e.g. session's abort and finish
methods make sure invoke success and failure delegate methods from this queue).
However, from the point of view of every concrete implementation of the session, the current naming isn't clear.
New name is for symmetry with the store queue, and the above ambiquity is addressed in the comment.
MozReview-Commit-ID: 61j7ZCNdr4x
--HG--
extra : rebase_source : 5f4092c2629414fc4f9051d8f8f0c113f1d6910d
This is a clean-up. Everywhere else, we run the fetch tasks and corresponding delegates on the delegateQueue.
MozReview-Commit-ID: Kd8XZAclJIB
--HG--
extra : rebase_source : d789ac49c365336c104c4e66c9826bf387d85465
We don't remove the configure option entirely for two reasons:
1) --with-gradle is still used in automation to specify a particular
Gradle binary, which is functionality we want to keep;
2) developers might have --with-gradle specified, and we can save them
having to remove it explicitly. There's a downside to this, however:
stale configure options can hang around indefintely. We can evolve
the configure option in the future.
MozReview-Commit-ID: D4sSclJ12j8
--HG--
extra : rebase_source : 3e5ebbf98347b5f2abfb67d2c50004aadc8bd145
Add a test for functionalities of GeckoSessionTestRule.
MozReview-Commit-ID: 9k9Fh1una20
--HG--
extra : rebase_source : f2558c452febf9f333ec4fed1955a0285ca9b246
Add a rule for setting up a GeckoSession for a JUnit4 test and letting
the test wait for listener invocations and to verify listener behavior.
MozReview-Commit-ID: 20ij409yY1Z
--HG--
extra : rebase_source : 50f8a01aad41938910710421b97d5dcc97594a06
Add GeckoSession.getScrollListener() so GeckoSessionTestRule can use it.
MozReview-Commit-ID: DLDlz5wz3cP
--HG--
extra : rebase_source : c196810da282f4ede6cb753081ef4d38af862909
GeckoSession consumers may want to refer to individual keys through a
GeckoSessionSettings.Key<> variable.
MozReview-Commit-ID: HK5wcs0uugD
--HG--
extra : rebase_source : 23e2489eed328bf0a08358c58c633d527d8a85c2
Right now there's no good way for a GeckoSession consumer to make a copy
of a GeckoSessionSettings object.
MozReview-Commit-ID: 199K5J51Y9x
--HG--
extra : rebase_source : 99c81c34ab2203e3517e07d286f865f5e93869c8
Kotlin has several nice features for writing tests, such as lambdas and
default implementations for interface methods. This patch adds Kotlin
support to the geckoview module build.gradle. We don't want to use
Kotlin in non-test code yet, so the patch ensures that only test code
contains Kotlin files.
MozReview-Commit-ID: FcQiHj20xlB
--HG--
extra : rebase_source : e304d25d09291bc0a3faa29bf36f9d01eadc8524
Pass --appname org.mozilla.geckoview.test to 'mach mochitest' or
'mach reftest'. This runs the tests without e10s currently.
MozReview-Commit-ID: 7TIvA3zRCw2
This eliminates a race where the JS side thinks it has a listener, and
expects a reply, but will never get one because it was unregistered
while the message was in-flight. GeckoSessionHandler dispatches
on the Android UI thread, which is where listeners are set/unset, so
we do not need any synchronization.
MozReview-Commit-ID: 5W3hsQ1cmb7
It may be nice to also log failed state transitions, but we seem to have too
many of those for it to be very useful right now.
MozReview-Commit-ID: 7z4UMyWQp2F
This adds a new geckoview_test module, which contains a
test runner Activity. We can then use JUnit4 + Espresso to
exercise the GeckoView APIs (such as GeckoSession).
MozReview-Commit-ID: FEMAZhpasLW
This allows apps to decide which GeckoSession should handle a load that
will be in a new window (e.g., window.open()).
MozReview-Commit-ID: BkJM93489Ga
This was oversight when landing Bug 1419581, coupled with dedicated
testing by Grisha. We don't expose all CONFIG values as DEFINES by
default, and I forgot to add the relevant value to the exposure list.
MozReview-Commit-ID: GUYNWampBAJ
--HG--
extra : rebase_source : f946f2630f2e9120d03b05a4677815e73ab6851a
