feat: add shell.trashItem() to replace shell.moveItemToTrash() #25114
Conversation
|
@electron/wg-api approved this at the August 24, 2020 meeting |
| // XXX: is continue_on_shutdown right? | ||
| base::ThreadPool::PostTask(FROM_HERE, | ||
| {base::MayBlock(), base::WithBaseSyncPrimitives(), | ||
| base::TaskPriority::USER_BLOCKING, |
There was a problem hiding this comment.
why can't this be USER_VISIBLE instead ? given the api being async, are we really required to respond the user interaction immediately ?
There was a problem hiding this comment.
I'm not sure what the distinction is here technically, but Chromium uses this for its "OpenItem" calls: https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/platform_util.cc;l=69;drc=14bd4f1ace32db87ec49e6c535f7910f71f1d89a
There was a problem hiding this comment.
You are right, I thought there would be a priority difference based on the definition here, but seems like they have same priority https://source.chromium.org/chromium/chromium/src/+/master:base/task/thread_pool/task_tracker.cc;l=480
|
@deepak1556 @codebytere ping? |
Co-authored-by: Robo <hop2deep@gmail.com>
|
Release Notes Persisted
|
Description of Change
Closes #11555.
Checklist
npm testpassesRelease Notes
Notes: Added a new asynchronous
shell.trashItem()API, replacing the synchronousshell.moveItemToTrash().