New Migration Wizard - Sneak peek - by setting browser.migrate.content-modal.enabled to true in about:config. No need to restart.
Bug 1529276 - resource:///modules/WindowsJumpLists.jsm still does main thread I/O
Still hacking on WindowsJumpLists!
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
Update methods so that tasks and custom lists are added in the same method call. So a single populate method that takes something like… (taskDescriptions, customTitle, customListDescriptions)
Finish the URL removal thing. Basically, if an item was removed via the shell, the next call to AppendCategory cannot include that item with the same display name - the next call needs to display something else entirely.
Implement clearJumpList (it’s called deleteActiveList)
Handle the URL removal case
Handle re-entry to buildList
What was with that NS_ERROR_FAILURE we saw after caling .update() not long after startup?
See how Thunderbird uses JumpListBuilder in case there are things we need to support there.
It’s a simple usage. They don’t have any custom items. We should support the no-custom-items case.
How about private browsing windows? How do the icon caches work for those? How do the built lists work for those?
Make our approach preffable. Put all the old stuff back (gulp), and update WindowsJumpList to use the new mechanism on a pref.
Figure out how to make the above testable. Then write tests.
Let’s update WinTaskbar to have a new method that can be accessed from native code (so not through XPCOM), called, like, DoCreateJumpListBuilder or something. Have it take an argument that is a reference to something that implements a JumpListManager interface. Have JumpListBuilder move that thing to the background thread - the background thread owns it. Then, in our tests, have our GTest call DoCreateJumpListBuilder, passing it something that mocks out JumpListManager. And then call it’s populateJumpList method for testing.
Next week, I am travelling and won’t be able to stream! Sorry!