Split BrowserProvider into History and Bookmarks

NEW
Unassigned

Status

()

5 years ago
5 years ago

People

(Reporter: rnewman, Unassigned)

Tracking

Trunk
All
Android
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [qa?])

(Reporter)

Description

5 years ago
This is a distinction we probably want for Sync.next; it would allow for accurate change notifications and correct checkbox names in Settings (see Bug 808813).

For the current codebase I'd split, keep one (history) named "Browser", and keep only that one registered for syncing with the 1.1 SyncAdapter. In Elm we can rename and register both.

First step in this bug is to assess how painful this split would be. The alternative is to have a fake provider.
How would things like our combined view work in this case? We will probably always need some way to join the bookmarks and history data for awesomescren/top sites kinds of queries.

However, I would love to take this opportunity to clean up the mess that is BrowserProvider, because currently these queries can cause us performance grief.
(Reporter)

Comment 2

5 years ago
(In reply to :Margaret Leibovic from comment #1)
> How would things like our combined view work in this case? We will probably
> always need some way to join the bookmarks and history data for
> awesomescren/top sites kinds of queries.

I imagine they'll still be backed by the same DB, so the combined view would just live in one of the two providers.

> However, I would love to take this opportunity to clean up the mess that is
> BrowserProvider, because currently these queries can cause us performance
> grief.

Yeah, I just wish it wasn't such an intimidating undertaking :D
Whiteboard: [qa?]
(Reporter)

Comment 3

5 years ago
16:25:41 < margaret> i'm noticing some things that are basically the same in BrowserProvider/TabsProvider that could be moved into some shared spot
(In reply to Richard Newman [:rnewman] from comment #3)
> 16:25:41 < margaret> i'm noticing some things that are basically the same in
> BrowserProvider/TabsProvider that could be moved into some shared spot

I filed bug 941357 about this.
(Reporter)

Updated

5 years ago
Assignee: rnewman → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.