If you want to hear more about our release model and how “the trains” work, check out Episode 270, around 44m20s in
WindowsJumpLists! Let’s keep going!
A lot of the complexity that we’re dealing with architecturally is because we’re trying to maintain the old backend while adding the new capability with a new backend, but the two backends share some infrastructure.
What I want to do is determine if we can do a better job of separating out the jumplist backend by reading a pref at runtime and choosing the right implementation.
TODO
Rename nsIJumpListBuilder to nsILegacyJumpListBuilder
Add createLegacyJumpListBuilder to nsIWinTaskBar to use the old mechanism
Update WindowsJumpList to use the legacy interface
Create a new nsIJumpListBuilder
Document NativeJumpListBackend
Populate nsIJumpListBuilder using the code we developed in the previous iteration
Have createJumpListBuilder in nsIWinTaskBar use that
Figure out why the JumpListBuilder isn’t returning the URLs of the previous
It’s working! It’s just that you have to remember to actually remove the item for it to show up in the list.
Update WindowsJumpLists to choose the right builder based on the pref and treat them correctly based on that pref.
Write a gtest for the JumpListBuilder
Write a front-end test that registers a fake nsIWinTaskbar or otherwise produces a fake nsIJumpListBuilder to make sure it gets passed the right things.
Make a note to migrate the new jump list builder off of the dedicated lazy thread and use the IO thread pool instead.