Closed
Bug 1049046
Opened 10 years ago
Closed 9 years ago
Migrated browser bookmarks placement on home screen
Categories
(Firefox OS Graveyard :: Gaia::System, defect)
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).
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → kyle
Assignee | ||
Comment 1•10 years ago
|
||
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)
Comment 2•10 years ago
|
||
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)
Assignee | ||
Comment 3•10 years ago
|
||
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)
Comment 4•10 years ago
|
||
(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)
Updated•10 years ago
|
Target Milestone: 2.1 S2 (15aug) → 2.1 S3 (29aug)
Comment 5•10 years ago
|
||
Removing blocking of meta since this already blocks a user story which blocks the meta.
No longer blocks: 945827
Updated•10 years ago
|
Target Milestone: 2.1 S3 (29aug) → 2.1 S4 (12sep)
Updated•10 years ago
|
Target Milestone: 2.1 S4 (12sep) → ---
Assignee | ||
Comment 6•9 years ago
|
||
Marking invalid since I assume things are going to change drastically in v3 anyways.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•