First, let’s see what it takes to not coalesce items in the Windows Task Tray
Because ultimately, that might be the most sensible solution - each profile is mapped to a different spot on the tray.
This appears to be how Chromium does it - they’re setting a AppUserModelID per profile
It turns out we’ve got a mechanism to do this already. It got added back in bug 577867 but it appears to only work for private browsing windows.
mconley to talk to Priv/Sec teams to figure out what’s going on with the AUMID stuff.
Let’s try to make the WindowsJumpList stuff happen off of the main thread! Exciting!
This may or may not actually contribute to the permanent private browsing thing we’ve been looking at, but it’s righteous work because of the placement it has in the hang stats list (currently #4!)
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 SetAppUserModelId return a Promise
Make addListToBuild return a Promise
Make commitListBuild return a Promise instead of using that old callback mechanism
Make deleteActiveList return a Promise
Update all of the callers of the above methods!
Remove locks and monitors
Migrate off of dedicated lazy thread to background thread pool
Goal: I want to make AddListToBuild do most of its work off of the main thread