Open
Bug 1382992
Opened 4 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)
Firefox
Bookmarks & History
Tracking
()
NEW
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).
Reporter | ||
Comment 1•3 years ago
|
||
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.
Updated•3 years ago
|
Summary: Figure out what do to with canDrop() → Figure out what do to with canDrop() with respect to sync vs async
You need to log in
before you can comment on or make changes to this bug.
Description
•