Closed Bug 1360359 Opened 7 years ago Closed 3 years ago

Round-tripping Form Autofill sync engine

Categories

(Firefox for Android Graveyard :: Android Sync, enhancement, P3)

enhancement

Tracking

(Not tracked)

RESOLVED INCOMPLETE

People

(Reporter: Grisha, Assigned: Grisha)

Details

Attachments

(3 files)

We're adding a new Form Autofill sync engine on Desktop to sync "user profiles". Let's land a simple round-tripping engine on Android in unison, even though we won't be using that data on mobile just yet.

Main goal for now is to provide a measure of data redundancy for the new data type.

Proposed behaviour:
- store profiles as JSON blobs in form_autofill table in the main browser.db
-- schema: id|guid|json|created|modified|is_deleted
- for now this table will be only accessed by sync. No local modifications are supported
- INSERT OR REPLACE incoming records
- upload records only on "first sync" to our current node, that is whenever we're syncing since=0

Desktop's implementation of profile storage is backed by a JSON file. Proposed storage above might not be ideal for an eventual implementation of autofill on Fennec, but it shouldn't be difficult to migrate/modify it when the time comes and the storage requirements are clearer.
Random thought, but is there any reason we can't do this for addons and prefs too?
Generally, no hard reason, just development bandwidth - but as you can see here, we can put something together reasonably quickly. As with anything mobile, we need to be mindful of our footprint on the device, especially for features that don't provide immediate benefit to the user other than data redundancy.

I'm not very familiar with the two engines and what their data looks like. Out of the two, add-ons will have less storage impact? IIRC prefs are used for all sorts of interesting things - but that might also make them more valuable.
Assignee: nobody → gkruglov
Status: NEW → ASSIGNED
Priority: -- → P1
(In reply to Mark Hammond [:markh] from comment #5)
> Random thought, but is there any reason we can't do this for addons and
> prefs too?

Add-ons and prefs are app-scoped, so maybe it'd be a bit weird to be snapshotting another app's prefs…
(In reply to Richard Newman [:rnewman] from comment #7)
> Add-ons and prefs are app-scoped, so maybe it'd be a bit weird to be
> snapshotting another app's prefs…

Yeah, but as mentioned in comment 0, it's more about redundancy. I was 1/2 expecting that one table as described in comment 0 (but with the table having a better name) would almost get all engines "for free", but I'm really not bothered at all, and Grisha's point about trying to minimize resources is a good one.
Priority: P1 → P2
Priority: P2 → P3
Product: Android Background Services → Firefox for Android
We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: