Closed Bug 1049046 Opened 6 years ago Closed 5 years ago

Migrated browser bookmarks placement on home screen

Categories

(Firefox OS Graveyard :: Gaia::System, defect)

x86
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: msandberg, Assigned: qdot)

References

Details

(Whiteboard: [systemsfe])

For users who update to 2.1 and have their browser bookmarks migrated to the home screen:

The bookmarks should be added to the bottom of the home screen as a new group (divider).
Blocks: 945827
Assignee: nobody → kyle
Right now, the bookmark migration has no context for the homescreen. It just uses the datastore API to move from its own IDB to the various datastores. I'm not sure how I could get the browser to actually cause a new divider to show up on the homescreen, short of some sort of odd activity.

Any thoughts, Kevin?
Flags: needinfo?(kgrandon)
Right - adding them to the datastore is easy, but we don't yet have a way to create a new divider. Two dirty hacks I can think of:

1 - Have some inter-app communication endpoint in the vertical homescreen which does nothing more than append a divider to the end of the current item list. Call this with IAC before adding bookmarks to the datastore/launching the homescreen.

2 - Append an extra bit of information to the first migrated bookmark datastore record, and when the homescreen reads that field it can create a new divider. Something like:

{
  id: 'http://mozilla.org',
  url: 'http://mozilla.org',
  metaCreateGroup: true
}

You would probably do the check for the field here: https://github.com/mozilla-b2g/gaia/blob/effe5fc22b6bd6af8a6277687f88c5a92cae6507/apps/verticalhome/js/sources/bookmark.js#L83


I'm not really a fan of either of these options, but they're they best I can think of currently. Modifying the datastore record might be a little bit better if it means using less processes during the migration.
Flags: needinfo?(kgrandon)
Trying to create metadata in the datastore assumes we'd fetch from the bookmarks from the datastore in an ordered way based on insertion, which is not guaranteed as far as I'm aware. So we can't say for sure where the group creation would show up. 

Not only that, how do we know where a bookmark will appear on the homescreen? If a bookmark is made on the homescreen, then moved, where is that data stored?
Flags: needinfo?(kgrandon)
(In reply to Kyle Machulis [:kmachulis] [:qdot] from comment #3)
> Trying to create metadata in the datastore assumes we'd fetch from the
> bookmarks from the datastore in an ordered way based on insertion, which is
> not guaranteed as far as I'm aware. So we can't say for sure where the group
> creation would show up. 

Yeah, it's probably not guaranteed, but given that this is backed by indexedDB with guaranteed insertion order and an update listener, we may be ok. Alternatively we could tack on metadata to each of these bookmark records and have the homescreen insert all of the matching records into the same section. We wouldn't need to keep this field updated, and we could update the record to remove it if we wanted afterwards.


> Not only that, how do we know where a bookmark will appear on the
> homescreen? If a bookmark is made on the homescreen, then moved, where is
> that data stored?

The bookmark data is *always* present in the datastore, as well as positional information in the local homescreen indexedDB. The homescreen receives the datastore update event, and persists the position to it's own indexedDB, then that record is updated whenever it's moved. We do not update the datastore record from homescreen.
Flags: needinfo?(kgrandon)
Target Milestone: 2.1 S2 (15aug) → 2.1 S3 (29aug)
Removing blocking of meta since this already blocks a user story which blocks the meta.
No longer blocks: 945827
Target Milestone: 2.1 S3 (29aug) → 2.1 S4 (12sep)
Target Milestone: 2.1 S4 (12sep) → ---
Marking invalid since I assume things are going to change drastically in v3 anyways.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.