I think this fixes the error I just saw in CI:
```
/Users/distiller/project/components/fxa-client/ios/FxAClient/FxAccountLogging.swift:8:1: warning: (enumNamespaces) Convert types used for hosting only static members into enums (an empty enum is the canonical way to create a namespace in Swift as it can't be instantiated).
```
Added the `get_auth_state()` method which gives a high-level view of the
auth state. Start tracking if a user is experiencing auth issues. This
represents a different state than either `Connected` or `Disconnected`.
As noted, the Rust code doesn't track all the data that we want yet, and
will need some help from the Kotlin wrapper. Added functions for
simulating auth errors
Added check for missing scoped keys in auth tokens. This will replace a
bunch of android-components code to workaround
https://github.com/mozilla-mobile/android-components/issues/8527.
Reworked the device API:
* Defined the `LocalDevice` struct, which contains the info about the
client's device.
* Many device methods now return a LocalDevice value constructed from
the server response.
* Use the last `LocalDevice` returned from the server to cache the
capabilities. This improves on the previous system, since it
differentiates between no known info and the empty list.
* One drawback is that this will always be unset when users migrate, so
they may hit the server an extra time when `ensure_capabilities` is
first called.
* This replaces `device_capabilities` in many cases, but
`device_capabilities` is still used for the
`reregister_current_capabilities`. In general, I think it's good to
track the two things separately: the last device info we've sent and
the last device info we got back from the server.
Reworked the Kotlin fxa-client wrapper:
* Stop wrapping `FxaConfig` and `FxaServer`, we can just export those
classes directly now.
* Renamed `PersistedFirefoxAccount` -> `FxaClient`. We're working
towards having this class handle more than just persistence.
* Make the token_server_override field optional
This acts as a container for the FirefoxAccount's state. All fields are
private, which means any state mutations need to go through one of its
methods. This makes it easier to follow the mutations.
As part of this refactor, I tried to make the names be more precise.
For example `last_sent_device_capabilities` instead of
`device_capabilites`.
Renamed `State` to `PersistedState` and the current "PersistedState"
enum to "PersistedStateTagged". My hope is that these names make it
clear what each type is doing.
Removed the `RefCell` around `FxaTelemetry`. It doesn't seem useful
when the entire struct is wrapped in a Mutex.
Removed some dead code
Moved all the code that updates `self.state` to the bottom of the
function. This makes the changes atomic, which is easier to understand.
Either we successfully handle the response and update our state, or we
fail to handle the response and the state stays the same.
I don't think this will affect the functionality. If we fail to handle
the oauth response, then we will be in a disconnected state and any of
the changes that would have previously been made won't matter. Please
double-check my reasoning here though.
This was part of my work for the auth PR, but I think it's useful
separatedly.
- Updated `fxa-client` to be a single binary.
- Added a cargo alias so it can be run with `cargo fxa [args]`.
I think this makes it easier to use and also will make it easier to
expand the functionality. It's easier to add another clap subcommand
than to add a new binary.
Made the wrapper code work with the new FxaConfig and FxaServer classes.
As noted, we should probably just expose those classes directly to the
consumer application, since they're almost identical to the
server/config classes that we do expose. However, let's wait just a bit
and fix a couple smaller breaking changes at once.
Made `FirefoxAccount` input a single `FxaConfig` instance for all of
it's configuration. I want to add more constructor arguments but don't
want to end up with a huge argument count.
Made the example code use the public API, not the internal module.
`FxaConfig` helps ease this transition. The motivation for this is that
I want to move FxaClent and some other fields to the public
`FirefoxAccount` instance, which means the example code needs to start
using it. This also results in some nice code cleanups.
Deleted the `fxa-client/migration` example, we're not really
using the migration code anymore.
Now that we're not exposing the `internal` module as pub, Rust is
noticing a lot of dead code. For the serde JSON structs, I kept the
dead fields and added an annotation. For the unused functions, I just
deleted them.
Created an `FxaServer` enum. This matches how the android wrapper
handles it and I don't think we need to input arbitrary URLs here.
- Define both the internal and external errors in `errors.rs`
- Use the new `error_support` code to handle conversions between the two
- Wrap API calls in `handle_error()`
- Defined the `ApiResult` typealias
- Reworked some of the imports a bit. The internal code doesn't need to
re-export pub items.
This is prep for the upcoming FxA client work. I think the smaller
modules are easier to understand and will make it easier to communicate
changes. Also, it's useful to know which structs go together with which
methods.
- Switched to using workspace dependencies, this will make future
updates much simpler
- Updated code to work with the new UniFFI crate structure
- Updated the error-support integration tests to work with the workspace
dependencies, following this advice: https://stackoverflow.com/a/71461114.
Reworks how BSOs work in all syncable components.
This adopts some of the BridgedEngine model - specifically, there's now
an IncomingBso and OutgoingBso, each with a corresponding IncomingEnvelope
and OutgoingEnvelope. There's also a new formalized "content" mechanism
for serializing and deserializing payloads to and from some T, with a
sane and consistent procedure for handling tomebstones and malformed
records.
BridgedEngine and SyncEngine now work using these new types, getting us
closer to fully integrating these engines into a single trait.
This kills sync15::Payload entirely in favor of the new system.
Went through all the main app-services components and replaced the
old-style `log::error!` calls with `error_support::report_error!`.
Removed the `reporting` feature of `error-support` and made it
always-enabled.
Renamed the `report_error` function so that it's name doesn't clash with
the `report_error` macro
(Which further reinforces that the name of that crate should be something like
`sync15-types`)
This is preparatory work for a much larger patch that will get us further down
the path to #2841 and also fix#2712. It should not change any behaviour.
As part of this, the sync15_traits errors needs to be addressed. It's not
reasonable to just create another enum that we expect clients to add to
their error types because many of the errors overlap which makes handling
them very difficult (eg, if we want to catch a serde error, you don't want
to know which crate it originated in) - so sync15 duplicates the sync15_traits
errors and can convert between them - so consumers can continue to catch
sync15::Error and still get errors which originated in sync15-traits.
sync15-traits now has a `crypto` feature - sync15 enables that feature, but
crates which just use a `bridged_engine` do not. This means that when
vendoring into Desktop Firefox, this feature isn't enabled, so we don't
pull in any of the crypto libs there.
* Update rand and parking_lot.
I need this to update other Gecko dependencies.
* Update dependency_summary to account for various windows-rs crates.
I'm not sure why it wasn't failing to find the relevant licenses before,
it was likely a pre-existing issue.
* Update dependency summaries.
* Runs dependency summaries on a mac
Co-authored-by: Emilio Cobos Álvarez <emilio@crisal.io>
* Prepare Nimbus for using uniffi Custom types
* Update places to use renamed Custom types
* Increment uniffi version number
* Update Cargo.lock
* Fixup ktlint
* initial conversion of errors for places uniffication
* Converted history metadata functions for places uniffication
* Converted kotlin history metadata functions
* Converted iOS history metadata functions
* [Places uniffication] Fix places error issues (#4687)
* remove uniffi-specific wrapper and updated error test
* Uniffi VisitObservation and apply_observation (#4689)
* uniffied VisitObservation, HistoryVisitInfo and methods using those structs
* Uniffi top frecent site info (#4711)
* Uniffi top frecent site info
* Uniffis FrecencyThresholdOption
* Uniffi Places Sync (#4714)
* uniffi places sync and sync15 functions
* Uniffi Search result and match url (#4720)
* Uniffi query autocomplete
* uniffi places_accept_result
* uniffi places_match_url
* cargo fmt
* cargo clippy
* remove accept_result from ffi crate
* Adds comment on the uniffi bug with varaint shadowing type
* Uniffi Places Interrupt methods (#4726)
* uniffi places interrupt functions
* Consolidate types (#4736)
* Updates the visit observation to use URL
* Uses VisitTransition for HistoryVisitInfo
* updates uniffi to 0.16
* Uniffied bookmarks
* switch to use uint in the apis for adding bookmarks (#4747)
* Remove the manual places FFI entirely.
* folders and separators now have non-nullable parents
* Always insert via Insertable items, and clarify separation between node types.
* Add json_tree module with all json-based types and implementation.
* Fix swift warnings re non-null parentGuid
* bookmarks: Remove public_node and introduce a fetch module
* Update swift code to make breaking changes fixes cleaner (#4766)
* rebased and added changelog entry
Co-authored-by: lougeniac64 <lougeniaC64@users.noreply.github.com>
Co-authored-by: Tarik Eshaq <teshaq@mozilla.com>
Co-authored-by: Mark Hammond <mhammond@skippinet.com.au>
* upgrades rust to 1.57
* fixes clippy
* Document where to find the latest version moz-central uses
* an attempt to fix broken cargo bench
* Uses _ instead of dead_code where possible
* runs cargo update
The FxAClient Swift module is the only thing that uses
the KeychainWrapper extensions, so let's make them live
inline in that codebase. This will simplify eventual
migration to publishing as separate Swift modules.
Prior to this commit, the `build.gradle` for each individual
project contained copy-pasted logic for configuring Android
and protobuf. Some of them were even using slightly different
versions of the same dependencies.
With this commit, there are two new gradle scripts that encapsulate
this shared logic:
* ./build-scripts/component-common.gradle, for basic Android
and Kotlin setup.
* ./build-scripts/protobuf-common.gradle, for configuration specific
to the protobuf plugin.
Hopefully this will make the logic easier to maintain going forward.
Prior to this commit, each of our individual components had its
own copy of gradle logic for depending on the megazord, including
a couple of lengthy comments about fiddling around with JNA for
the Android Studio test runner.
I've moved all that logic into a helper function in `publish.gradle`
so that we can maintain it in a single location from here out.
There may be a cleaner or more idiomatic way to achieve this kind
of code-sharing in gradle, but I figure this *has* to be better
than our current copy-paste-based approach.
I've manually confirmed that a local `./gradlew test` completes
successfully, as well as testing via Android Studio.
The latest release of UniFFI includes a significant change to the
way Object instances are managed, switching from handlemaps to
raw Arc<T> pointers. We should get this into consumers for testing
at some point early in a Nightly cycle.
This is a nice testcase for the "bindings are automatically regenerated
on UniFFI version changes" theory about the previous commit, which does
indeed seem to be working out for me in practice.
We currently have four copies of the logic for calling UniFFI
from gradle, several with their own little tweaks. Let's take
the best lessons from each and consolidate them into a single
shared helper.
This version is, I think, an improvement over all the existing
ones:
* Like the nimbus version, it registers the task as generating
java source files, which should help things integrate cleanly
into the broader build.
* Like the fxa-client version, it declares explicit inputs so
that we can avoid re-running the task when nothing has changed.
* New in this version, it declares an input dependency on anything
that would affect the version of `uniffi-bindgen` that is in use,
since that too will change the generated outputs.
That last change should really help with smooth updates to the
version of UniFFI in use. Previously, if you changed the UniFFI
version it would not trigger a cleanup of old generated bindings,
and you'd get `java.lang.UnsatisfiedLinkError` errors like in #4054.
(This is UniFFI's last-line-of-defence measure to prevent you from
using bindings generated with one version of UniFFI on a library
compiled with another, which is very useful, but an extremely
confusing failure mode).
With this change, an updated version of UniFFI will invalidate
the gradle task that generates the bindings, causing them to
be regenerated with the new version.
The rust-ece crate has had its interface simplified to remove footguns,
let's update to that release and get a few cleanups of our own while
we're at it.
This is a substantial refactor of the fxa-client crate, intended to bring it
up to speed with our latest best-practices around developing cross-platform
Rust components, in order to ease ongoing maintenance.
THe core change here is that I've deleted the hand-written Kotlin and Swift
bindings, replacing them with autogenerated bindings thanks to UniFFI.
There is still a little bit of hand-written Kotlin, since we have a layer that
automatically manages persistence via a callback. There is still a nontrivial
amount of hand-written Swift, since we have a higher-level state machine built
atop the lower-level fxa-client functionality (such state-machine also exists
for Kotlin, but lives in the android-components repo). If UniFFI works out then
we should look into moving more of that logic into shared Rust code over time.
To support the introduction of UniFFI, I have restructured to Rust crate so
that its public interface deliberately parallels the interface offered to
Kotlin and Swift, and have moved the implementation details into a submodule
named `internal`. It's my opinionated belief that structuring the crate this
way will help us focus on producing a nice consumer API, which is not always
the same thing as producing a nice Rust crate.
On top of that, I've also revamped the documentation in the crate, leaning
in to the use of `cargo doc` as the source of truth for both developer-
and consumer-facing documentation. Let's consider that an experiment and
see how we like it in practice.
Unfortunately, this is a big PR, but I don't think I could have made it
too much smaller. Hopefully it will be easier to review than its size
suggests since it's mostly additions and deletions rather than complex
changes.
Ben Dean-Kawamura
nox1134
David Durst
James Hugman
Mike Hommey
Sammy Khamis
Mark Hammond
Tarik Eshaq
jhugman
lmarceau
Sammy Khamis
Tommaso Piazza
Janet Dragojevic
Ryan Kelly
Ryan Kelly
Dan Mosedale
Edouard Oger