Goal: I want the JumpListManager to only ever be accessed off of the main thread, so that the main thread in the parent process never has to await a lock.
Get rid of maxListItems, since it doesn’t appear to be used
Get rid of isListCommitted
Make .available return a Promise
Make abortListBuild return a Promise
Make deleteActiveList return a Promise
Make SetAppUserModelId return a Promise
Add WebIDL for JumpListShortcutDescription and add populateJumpList method to JumpListBuilder.
Custom List (this is the Frequently Visited stuff) - Frequent is ENABLED by default - Recent is DISABLED by default - Don’t need separators
Tasks
Figure out how to make the above testable.
Make populateJumpList work to create jump list items all in one shot
Implement clearJumpList
See if the above works. If it does, get rid of old changes that we don’t need and merge patches down
Update WindowsJumpList.jsm to use the new API instead of the old one.
Update WindowsJumpList.jsm to be simpler so that it doesn’t try to do so much lazy stuff since now it’s all off of the main thread
Remove the old implementation! Hooray!
Migrate off of dedicated lazy thread to background thread pool
Question: “What is easiest way to succeed with applying an old patch, bump it to tip and deal with merge conflicts? To handle review feedback. Is it best to apply somewhere close in the Mercurial tree where it was committed?”
Answer: It’s best if you can take advantage of the VCS’s smarts when reviving an old patch. moz-phab patch XYZ –apply-to here just uses the patch command under the hood to apply the patch directly. Rebase the old patch from where it was onto the tip. That will take advantage of what the VCS knows about what has happened since that commit was made.