Open Bug 1382992 Opened 3 years ago Updated 2 years ago

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

Categories

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

Product:
Firefox
Component:
Bookmarks & History
Type:
enhancement

Tracking

()

People

(Reporter: mak, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [fxsearch]) 

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).
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.
See Also: → 1047820
Summary: Figure out what do to with canDrop() → Figure out what do to with canDrop() with respect to sync vs async
Blocks: 1457131
You need to log in before you can comment on or make changes to this bug.