Граф коммитов

9 Коммитов

Автор SHA1 Сообщение Дата
Ehsan Akhgari 4941f9389a Bug 1332752 - Add some logging to TimeoutManager; r=bkelly 2017-01-23 16:04:26 -05:00
Ehsan Akhgari d9ae1e342b Bug 1325467 - Part 2: Let TimeoutManager::DOMMinTimeoutValue know whethe the timeout being scheduled is tracking; r=bkelly 2017-01-17 21:01:16 -05:00
Bill McCloskey 8a53959bbe Bug 1320753 - Make TabGroup event target be a ThrottledEventQueue for timers, workers (r=bkelly)
MozReview-Commit-ID: FCfYz02r8yI
2016-12-23 11:48:13 -08:00
Ehsan Akhgari 35e93a7bdf Bug 1312514 - Part 3: Add a test to ensure that timeouts from tracking scripts end up in the tracking bucket; r=bkelly
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.
2016-12-20 12:40:30 -05:00
Ehsan Akhgari 7326630b5d Bug 1312514 - Part 1: Split tracking and non-tracking timeouts into two separate lists; r=bkelly
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.
2016-12-20 12:40:26 -05:00
Ehsan Akhgari 5dcff2e3c6 Bug 1323337 - Refactor two methods looping over timeouts from TimeoutManager into Timeouts; r=bkelly
With this patch, all of the methods which loop over the timeouts
are refactored in preparation for splitting the list of timeouts
into a tracking and a normal list.
2016-12-14 16:02:22 -05:00
Ehsan Akhgari 32a2d894ed Bug 1323326 - Refactor the normal loops over Timeouts inisde TimeoutManager to use ForEach helpers; r=bkelly
These generic loops need to run in the same way for both normal and
tracking timeouts.  This refactoring allows us to only change the
TimeoutManager ForEach helpers to loop over both linked lists when
splitting the timeouts into two separate lists without needing to
modify each call site separately.
2016-12-14 16:02:21 -05:00
Ehsan Akhgari 7c362efcfe Bug 1323202 - Factor out the timeouts linked list into a separate data structure; r=bkelly
This is in preparation of splitting the timeouts list into normal and
tracking timeouts.
2016-12-13 19:09:19 -05:00
Ehsan Akhgari 443e426d7c Bug 1321903 - Refactor the timeout/interval management code out of nsGlobalWindow; r=bkelly
This code now lives in TimeoutManager.  Note that this is a transition
state, the Timeout list management code also needs to be refactored out
later.

In order to simplify the lifetime management of the new class, its
lifetime is equal to the lifetime of its containing nsGlobalWindow.  In
a few places where we need to dispatch runnables to do asynchronous work
on this object, we hold the containing window alive to guarantee safety.

This patch also removes a bit of dead code that was left over from the
code removed in bug 1281793. See:
https://hg.mozilla.org/mozilla-central/rev/0ac748f4d677#l1.63
2016-12-13 14:08:47 -05:00