Looking at the recent drag & drop / copy & paste code, it is fairly clear it no longer needs the itemId (aka parentId) in the insertionPoint. The other uses seem to be mainly for the bookmarks properties dialog - there's a few places where it is used, but I think the dialog could simply do a promiseItemId, if it needs it at all. This would help simplify at least some of the existing cases in tests where we're having to go and get the IDs rather than using GUIDs all the time.

Having looked through a bit more, I'm pretty sure that the bookmark properties dialog no longer needs the id in the insertion point (though it does need to get it, but there's async methods available where we can easily do that). Unfortunately the drag and drop parts are blocked by onDrop needing to be synchronous. That's bug 1382992.

Pushed by mak77@bonardo.net: https://hg.mozilla.org/integration/autoland/rev/3aa3ae050bab Remove itemId (aka parentId) from PlacesInsertionPoint. r=Standard8 https://hg.mozilla.org/integration/autoland/rev/5173f2ffbc1d Remove no longer necessary getConcreteItemId(). r=Standard8 https://hg.mozilla.org/integration/autoland/rev/edc3b095d718 Remove no longer necessary PlacesUtils.toolbarFolderId. r=Standard8 https://hg.mozilla.org/integration/autoland/rev/2321ee1c9ab1 Remove no longer necessary PlacesUtils.placesRootId. r=Standard8 https://hg.mozilla.org/integration/autoland/rev/fdd9bc0c987b Remove no longer necessary PlacesUtils.bookmarksMenuFolderId. r=Standard8