Ensure that BrowserProvider functions correctly prior to initial profile construction

NEW
Unassigned

Status

()

Firefox for Android
Data Providers
4 years ago
4 years ago

People

(Reporter: rnewman, Unassigned)

Tracking

Trunk
All
Android
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
BrowserDB is intended to be used from Fennec, not from arbitrary other code -- that's what BrowserProvider is for.

But BrowserProvider doesn't have the power to completely init a profile. That requires distribution processing, creating directories, writing to profiles.ini, etc.

I'm pretty sure we already checked that the behavior was acceptable to Sync (probably failure if the profile doesn't exist), but we should see what happens with the Share activity:

* It might, being an activity, trigger post-install referrer intent handling, and accidentally launch the browser.

* It might do so and just init the profile (perhaps only for distribution users), which would be great.

* It might drop the post-install referrer intent on the ground, which would not be cool.

* We might be able to recognize this situation and open Firefox, then redeliver the share intent.

* We might elect to fix this, either by initing the profile from the share overlay service, or by allowing BrowserProvider to create parts of the profile.


Step 1 is to figure out what happens if you share right after a clean install.

This is not a hard blocker to Bug 1044794; definitely for Nightly, I don't mind if we just drop shares on the floor if you've never opened the browser.
You need to log in before you can comment on or make changes to this bug.