Closed
Bug 1044791
Opened 10 years ago
Closed 4 years ago
[meta] Backend for handling requests from overlays
Categories
(Firefox for Android Graveyard :: Overlays, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: ckitching, Assigned: ckitching)
References
Details
(Keywords: meta)
Meta bug to track the work related to the overlay backend.
The backend's task is to provide an interface for receiving intents from the overlay frontend and performing tasks on Fennec in response.
At time of writing, the requests the backend seems to need to support are:
1) Add to bookmarks (Bookmarks the URL provided in the body of the request)
2) Add to reading list (Adds the given URL to the reading list)
3) Send tab (Delegate to Sync's existing Send Tab handler, perhaps with refactoring to allow the frontend to provide a different UI for target device selection)
4) Open tab in background (Not relevant for Bug 1040967, but likely necessary for phase 2)
In the general case of an overlay interaction, Fennec does not have a foreground activity. It therefore seems natural to design the backend as a service to which intents may be dispatched causing operations to occur silently in the background.
Ideally, work the service does in the direction of partially loading Fennec (such as initialising the database) should not be repeated when the browser is subsequently started.
To perfectly implement these features, we'll need the ability to start Gecko headless. This will likely boil down to creating a "Gecko service" to which both the browser, GeckoView, and the overlay backend are all clients. This would allow for the loading of tabs in the background in response to overlay requests, meaning when you subsequently launch the browser all your tabs are already there waiting for you, your reading list material has been stored to disk, and your bookmarks have had their favicon downloaded.
Unfortunately, that turns out to be rather less of a straightforward refactor than I'd hoped. Instead I propose doing this as a three-stage progression (stage 3 likely to be handled by someone else, due to my imminent vanishment):
Stage 1 (working prototype exists at time of writing):
1) By starting the BrowserDB and writing. An attempt to fetch favicons from the database for can be made, but the lack of headless gecko prevents us from obtaining either a favicon or title from the webpage. Bookmarking, then, shall use the title provided in the intent (if any), the favicon in the database already (if any), and the url.
The approach of fetching the page from Java and trying to decode it to get the title/favicon is discouraged: This will occur without the user's cookies (bookmarking the login screen), as well as being slightly "ick" for duplication of much logic (at least some of which would prove useful, however: Bug 507641)
2) The semantics of adding to the reading list will need to be changed (Bug 1044781).
It will not be possible to store the added page locally (to be read offline) without headless Gecko support. (the "bookmark the login page" problem exists here, too).
3) should be a simple refactor.
4) is not supported.
After stage 1, we will have a sufficient backend to satisfy the sharing part of Bug 1040967, though some room for improvement will remain.
Stage 2:
Add support for 4) using a "to-do list". Tabs to be opened in the background are queued up in persistent storage which is checked by Fennec on startup. Once Gecko is alive, the queued tabs are spawned (either using the existing "zombiefication" framework, or some mechanism for loading them in batches of sensible sizes).
This will be sufficient to support an overlay frontend handling view intents, however that ends up being designed, allowing the complete solution of Bug 1040967.
Stage 3:
Add headless Gecko support to Fennec and leverage it to enhance all of the above.
Opening of tabs in the background can now load tabs right away (preventing the user from having to wait for them to load once they open Fennec).
Favicons/titles for bookmarked entries can now be fetched by the service, preventing weirdly-blank entries from appearing in the bookmarks table.
Add-to-reading-list requests can now download and store pages for offline viewing.
Comment 1•4 years ago
|
||
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: 4 years ago
Resolution: --- → INCOMPLETE
Updated•4 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•