1382992 - Figure out what do to with canDrop() with respect to sync vs async

Status: RESOLVED FIXED

(Firefox :: Bookmarks & History, enhancement, P3)

Description

[Marco Bonardo [:mak]]

canDrop is synchronous. It currently checks that we don't drop a container inside itself or a descendant container and to do that it has to walk the container hierarchy by doing main-thread I/O.

Collecting the information on drag start is also not possible, because dragstart is a synchronous operation where we must synchronously fill the dataTransfer (there's some ongoing work to make this async but no ETA).

Comment 1

[Marco Bonardo [:mak]]

we could keep an up-to-date bookmarks hierarchy in a memory cache. The main issue would be a synchronous request before the cache has been populated, for which we could retain a synchronous fallback, or throw and let the consumer take the more pessimistic fallback.

Comment 2

[Marco Bonardo [:mak]]

Another alternative may be to use the view (trees and menus should allow to walk up/down the chain), then do a final async check onDrop, where we can use async APIs.

Comment 3

[Marco Bonardo [:mak]]

Attachment: Bug 1382992 - Remove the synchronous getFolderIdForItem() bookmarks API. r=Standard8

Unfortunately the dragover behavior is not trivial to test, thus this relies on
manual testing. The data safety is covered by the undelrying bookmarking API
anyway, so this is just about the UI visual drag indicator.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/487ae9d43aac
Remove the synchronous getFolderIdForItem() bookmarks API. r=Standard8

Comment 5

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/487ae9d43aac