This allows developers to manually upgrade packages as desired by running
|cargo update -p <package>| or |cargo update| on gkrust and gkrust-gtest.
Previously this update would happen implicitly as part of |mach vendor rust|,
and made it hard to upgrade specific packages without upgrading everything.
MozReview-Commit-ID: 91GOdtGmwX0
nsImageLoadingContent::Notify is where all image notifications for things like <img> elements go through. The vast majority being implemented in C++. Any image observers implemented in JS must go through ScriptedNotificationObserver.
We only use ScriptedNotificationObserver in tests. The addon repository only has six hits, and four of them seem to be different versions of the same addon. And they don't seem to be among the more popular addons.
The original location of the assert only caught some images anyway. Things like CSS background images don't go through nsImageLoadingContent. ProgressTracker is the origin of all image notifications.
We're adding this test to test_timer_flood.html since it already
examines dispatching thousands of timeouts. Putting the timeouts in the
two buckets randomly ensures that the test isn't biased towards, for
example, alternating ordering of the timeouts.
For simplicity, this test is being added to test_classifier.html which
already has all of the infrastructure necessary for setting up a test
domain as a tracking domain.
This pref allows easier testing and debugging of this feature
by forcing timeouts to end up in the tracking bucket in either
the alternating or random fashion.
This will allow us to schedule these timers differently in the future.
This patch only performs the refactoring, and is not intended to change
any behavior. Specifically, this patch doesn't change the order in
which timeouts are fired -- they should still all be fired according to
the mWhen field.
The implementation works by splitting timeout storage per window into
two Timeouts objects, mNormalTimeouts and mTrackingTimeouts. The ForEach
helper methods are extended to deal with both of these objects, and as a
result, most of the algorithms operating on the list of timeouts work
correctly without any modification, with the notable exception of
RunTimeout.
In RunTimeout(), the order in which Timeout objects are processed does
matter, so for that case we use the OrderedTimeoutIterator class to
iterate over both linked lists simultaneously in the mWhen order. Also,
inserting the dummy timeout when running the timeouts is only necessary
for the linked list where the last expired timeout is coming from, so we
only inject the dummy timer into the corresponding list, therefore we
remember which list we picked the last expired timeout from when
looking for it.
