The current bookmark tree structure has desktop bookmarks as the root with mobile bookmarks as a subfolder. Local bookmarks are then created and displayed in the root alongside the desktop folder. This is confusing. We need to create a 'fake' mobile root folder that takes the existing mobile bookmarks in the desktop folder and displays them as root. This faking of the mobile root folder should be done when fetching bookmarks from the database so the UI doesn't care. Care should be taken that this doesn't affect the merging of local bookmarks back into the tree ready for bi-directional sync (i.e. we don't change the abiliy to add and merge new bookmarks back into the mobile folder) Care should be taken to ensure that any edits to bookmarks in the existing mobile bookmarks folder are made in the correct place in the tree on disk.

(In reply to Emily Toop (:fluffyemily) from comment #0) > The current bookmark tree structure has desktop bookmarks as the root with > mobile bookmarks as a subfolder. Local bookmarks are then created and > displayed in the root alongside the desktop folder. This is confusing. I had to read this a few times to make it match up to my understanding: when you say 'tree structure' and 'desktop bookmarks' you mean the Desktop Bookmarks folder, right? To rephrase: The current bookmark tree structure is rooted in the local/merged mobile bookmarks folder (mobile______). The local and merged mobile bookmarks that are children of mobile______ are displayed in the first list you see. A fake Desktop Bookmarks folder (desktop_____) is prepended to the list if non-empty, and the three/four remote roots (toolbar_____, menu________, unfiled_____, mobile______ (optional)) are children of that folder. In the fully merged case, there is no remote mobile folder. > We need to create a 'fake' mobile root folder that takes the existing mobile > bookmarks in the desktop folder and displays them as root. So where do the local mobile bookmarks go? Or do you mean visually merging the two? > This faking of the mobile root folder should be done when fetching bookmarks > from the database so the UI doesn't care. The UI will care about at least one thing: you can't edit or delete unmerged remote mobile bookmarks, by definition. So if you're intermixing the list, you'll have different behaviors for adjacent items. (The column for this is already returned from queries and handled by the list items, so this should Just Work®.)

It's possible then that I have misunderstood this requirement. I read it as currently our bookmarks structure _as displayed to the user_ is: * local mobile bookmarks * desktop folder -> - toolbar folder - unsorted folder - remote mobile folder - other folders Of these, the subfolders of desktop are the actual folders that live on the server What we want to do is display _all_ mobile bookmarks at the root alongside the local mobile bookmarks, despite the fact that is not where they actually live. Therefore we have to somehow tell the UI to display things that way. I was envisaging that we did this when we requested our bookmarks rather than have the UI layer understand these things. We would then need some kind of translation/mutation of the actual bookmarks structure to some structure that is purely there for the UI to understand, and translate it back again when changes are made. If this is not the requirement, and everything is perfectly fine the way it is, I am unsure what the requirement is wrt the simplification of the UI from the users perspective.

Okay, I think we're on the same page. I'd technically phrase this as: include (as best we can) buffer mobile bookmarks in the top-level mobile bookmarks list. There's one outstanding question: do you want this to apply to just the entirely-unmerged state, or also to the synced-but-now-can't state? Regardless, this means undoing part of Bug 1253441, which added remote mobile bookmarks to Desktop Bookmarks, particularly the changes to SQLiteBookmarksModel line 203 and 742. The direction-aware part on line 121 will need to change to also fetch from the buffer, but how you alter that code depends on what the fallback behavior should be. Areas of complexity and concern: * The root view will now include some editable and some non-editable items. * You'll have to figure out how to order these -- some kind of timestamp. * You'll have to figure out what happens when the buffer and local+mirror both include a record with a given GUID. You can provoke this situation by syncing bidirectionally, then by introducing corruption, then deleting, adding, and changing some mobile bookmarks. You can write a test for this. * When there's a folder in one of the two sequences -- buffer or local+mirror -- you'll have to decide whether to recursively query both stores as you descend into it. That gets hairy real fast.

(In reply to Emily Toop (:fluffyemily) from comment #2) > What we want to do is display _all_ mobile bookmarks at the root alongside > the local mobile bookmarks, despite the fact that is not where they actually > live. Yes, this ^ Uneditable items will show the management options but they will be disabled. They will appear in ascending order. The user *could* manually reorder these on Desktop, but we're not providing this functionality at this time.