Q: I would love if you could explain how to see what the MSRV of a specific Firefox release is using. The schedule on https://firefox-source-docs.mozilla.org/writing-rust-code/update-policy.html#schedule hasn’t been updated for Firefox 117 and 118 (and now 119). I filed a docs bug (https://bugzilla.mozilla.org/show_bug.cgi?id=1860181), but it hasn’t gained any traction. Not that I’m expecting you to do anything about this, I was just hoping you could point me in the right direction of figuring out what the MSRV for a specific Firefox release is.
A: I think it’s defined here in mozilla-central: https://searchfox.org/mozilla-central/rev/01a0d864a9442d0fe2dbd4beee5c88b9b46e96bd/python/mozboot/mozboot/util.py#14
A: I’ve needinfo’d glandium to see if my assumptions on the MSRV’s for 117-120 are correct, and if so, we can go ahead and update that doc. It might be worth automating the construction of that document at some point!
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.
Why aren’t the favicons working?
It was always this way - there’s a moment in time, right after the page visits, where the favicon hasn’t yet been written to disk, but after it has been, the favicon becomes present. Usually the update immediately after.
Investigate shutdown crashes by adding MOZ_ASSERT(mThread == PR_GetCurrentThread()); basically everywhere. Especially at shutdown.
I KNOW WHAT”S HAPPENING. The JumpListBuilder is created on the main thread. That class creates a LazyIdleThread (mIOThread) which is responsible for instantiating the JumpListBackend (aka the NativeJumpListBackend). BUT GUESS WHAT: A LazyIdleThread will shut itself down after a period of inactivity - that’s part of how it works! That means that when it comes time to shutting everything down, we’re asking a LazyIdleThread to destroy the JumpListBackend which might not be the same thread that created it, thus hitting our assertion! What we might need to do is to either, 1: destroy the JumpListBackend anytime the LazyIdleThread is shut down. 2: move the JumpListBackend destruction responsibility to the main thread.
Nika suggests using NS_INLINE_DECL_REFCOUNTING_ONEVENTTARGET
After doing a removal, I saw a NS_ERROR_UNEXPECTED, and then an NS_ERROR_FAILURE for each subsequent update. Why is that?
We need to ask Windows for the set of URLs to remove before we query Places and populate with the new list. That means adding a new function.
Write a GTest for the JumpListBuilder
SetAppId
CheckForRemovals
Need to get the JS string[] thing out and compare! Fun!
Make WaitForResolver::SpinUntilResolved return resolve JSValue
PopulateJumpList
Uh… how come when I pass in empty arrays it’s still returning NS_OK? Whattttttt is happening?
This is fine because we can pass empty arrays to clear out the jump list! The only rule that seems to be enforced is that a custom string must be supplied if and custom tasks are supplied.
Figure out how to convert our description objects into JS Values. There might be helpers for this via DictionaryBase
Write a new kind of matcher to match against the ShellLink that has been passed to AddUserTasks and compare it to the WindowsJumpListShortcutDescription!
Testing with optional arguments
Factor out descriptions definitions into a helper function?
Test ClearJumpList
Maybe all of our mocks should be StrictMocks?
Do I really need to convert each WindowsJumpListShortcutDescription jsval into a rooted JSval before initting to the structure?
nsMainThreadPtrHolder promiseHolders on JumpListBuilder?
Need to double-check all limits on IShellLink properties to ensure the strings aren’t too long.
Update the freceny SQL query to actually sort by number of visits!
Write a test for long description
Assign((u”string %i”, i)) might be what saves us here.
Manually test long title
Further de-duplicate tests (especially PopulateJumpList tests) by putting preamble and post-amble into a helper function
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.
Consider making the rejection value of populateJumpList not an nsresult but a more descriptive ErrorResult type.
See if we should ClearJumpList on kPrefTaskbarEnabled pref change or TOPIC_CLEAR_PRIVATE_DATA
Codetribute:
Find a good first bug to start contributing on a Mozilla projects (Firefox, Thunderbird, and more). See the above link for creating a Bugzilla account first!