2016-12-03 01:22:48 +03:00
|
|
|
/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
|
|
|
|
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
|
|
|
|
/* This Source Code Form is subject to the terms of the Mozilla Public
|
|
|
|
* License, v. 2.0. If a copy of the MPL was not distributed with this
|
|
|
|
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
|
|
|
|
|
|
|
|
#include "TimeoutManager.h"
|
2017-12-06 14:56:32 +03:00
|
|
|
#include "nsContentUtils.h"
|
2016-12-03 01:22:48 +03:00
|
|
|
#include "nsGlobalWindow.h"
|
2017-01-10 06:16:31 +03:00
|
|
|
#include "mozilla/Logging.h"
|
2017-05-02 14:23:00 +03:00
|
|
|
#include "mozilla/Telemetry.h"
|
2016-12-03 01:22:48 +03:00
|
|
|
#include "mozilla/ThrottledEventQueue.h"
|
|
|
|
#include "mozilla/TimeStamp.h"
|
2017-07-20 18:06:20 +03:00
|
|
|
#include "nsIDocShell.h"
|
2017-07-26 21:18:20 +03:00
|
|
|
#include "nsINamed.h"
|
2016-12-03 01:22:48 +03:00
|
|
|
#include "nsITimeoutHandler.h"
|
|
|
|
#include "mozilla/dom/TabGroup.h"
|
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-16 00:17:38 +03:00
|
|
|
#include "OrderedTimeoutIterator.h"
|
2017-06-01 03:13:19 +03:00
|
|
|
#include "TimeoutExecutor.h"
|
2017-06-16 10:17:09 +03:00
|
|
|
#include "TimeoutBudgetManager.h"
|
2017-06-14 18:47:38 +03:00
|
|
|
#include "mozilla/net/WebSocketEventService.h"
|
|
|
|
#include "mozilla/MediaManager.h"
|
|
|
|
|
2016-12-14 03:06:21 +03:00
|
|
|
using namespace mozilla;
|
2016-12-03 01:22:48 +03:00
|
|
|
using namespace mozilla::dom;
|
|
|
|
|
2017-01-10 06:16:31 +03:00
|
|
|
static LazyLogModule gLog("Timeout");
|
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
static int32_t gRunningTimeoutDepth = 0;
|
|
|
|
|
|
|
|
// The default shortest interval/timeout we permit
|
2017-06-16 03:30:47 +03:00
|
|
|
#define DEFAULT_MIN_CLAMP_TIMEOUT_VALUE 4 // 4ms
|
2016-12-03 01:22:48 +03:00
|
|
|
#define DEFAULT_MIN_BACKGROUND_TIMEOUT_VALUE 1000 // 1000ms
|
2016-12-22 06:56:45 +03:00
|
|
|
#define DEFAULT_MIN_TRACKING_TIMEOUT_VALUE 4 // 4ms
|
|
|
|
#define DEFAULT_MIN_TRACKING_BACKGROUND_TIMEOUT_VALUE 1000 // 1000ms
|
2017-06-16 03:30:47 +03:00
|
|
|
static int32_t gMinClampTimeoutValue = 0;
|
2016-12-22 06:56:45 +03:00
|
|
|
static int32_t gMinBackgroundTimeoutValue = 0;
|
|
|
|
static int32_t gMinTrackingTimeoutValue = 0;
|
|
|
|
static int32_t gMinTrackingBackgroundTimeoutValue = 0;
|
2017-06-14 18:47:38 +03:00
|
|
|
static int32_t gTimeoutThrottlingDelay = 0;
|
2017-01-10 06:16:31 +03:00
|
|
|
static bool gAnnotateTrackingChannels = false;
|
2017-05-02 14:23:00 +03:00
|
|
|
|
2017-06-14 18:47:38 +03:00
|
|
|
#define DEFAULT_BACKGROUND_BUDGET_REGENERATION_FACTOR 100 // 1ms per 100ms
|
|
|
|
#define DEFAULT_FOREGROUND_BUDGET_REGENERATION_FACTOR 1 // 1ms per 1ms
|
|
|
|
#define DEFAULT_BACKGROUND_THROTTLING_MAX_BUDGET 50 // 50ms
|
|
|
|
#define DEFAULT_FOREGROUND_THROTTLING_MAX_BUDGET -1 // infinite
|
|
|
|
#define DEFAULT_BUDGET_THROTTLING_MAX_DELAY 15000 // 15s
|
|
|
|
#define DEFAULT_ENABLE_BUDGET_TIMEOUT_THROTTLING false
|
|
|
|
static int32_t gBackgroundBudgetRegenerationFactor = 0;
|
|
|
|
static int32_t gForegroundBudgetRegenerationFactor = 0;
|
|
|
|
static int32_t gBackgroundThrottlingMaxBudget = 0;
|
|
|
|
static int32_t gForegroundThrottlingMaxBudget = 0;
|
|
|
|
static int32_t gBudgetThrottlingMaxDelay = 0;
|
|
|
|
static bool gEnableBudgetTimeoutThrottling = false;
|
|
|
|
|
2017-05-19 23:45:55 +03:00
|
|
|
// static
|
|
|
|
const uint32_t TimeoutManager::InvalidFiringId = 0;
|
|
|
|
|
2017-06-14 18:47:38 +03:00
|
|
|
namespace
|
|
|
|
{
|
|
|
|
double
|
|
|
|
GetRegenerationFactor(bool aIsBackground)
|
|
|
|
{
|
|
|
|
// Lookup function for "dom.timeout.{background,
|
|
|
|
// foreground}_budget_regeneration_rate".
|
|
|
|
|
|
|
|
// Returns the rate of regeneration of the execution budget as a
|
|
|
|
// fraction. If the value is 1.0, the amount of time regenerated is
|
|
|
|
// equal to time passed. At this rate we regenerate 1ms/ms. If it is
|
|
|
|
// 0.01 the amount regenerated is 1% of time passed. At this rate we
|
|
|
|
// regenerate 1ms/100ms, etc.
|
|
|
|
double denominator =
|
|
|
|
std::max(aIsBackground ? gBackgroundBudgetRegenerationFactor
|
|
|
|
: gForegroundBudgetRegenerationFactor,
|
|
|
|
1);
|
|
|
|
return 1.0 / denominator;
|
|
|
|
}
|
|
|
|
|
|
|
|
TimeDuration
|
|
|
|
GetMaxBudget(bool aIsBackground)
|
|
|
|
{
|
|
|
|
// Lookup function for "dom.timeout.{background,
|
|
|
|
// foreground}_throttling_max_budget".
|
|
|
|
|
|
|
|
// Returns how high a budget can be regenerated before being
|
|
|
|
// clamped. If this value is less or equal to zero,
|
|
|
|
// TimeDuration::Forever() is implied.
|
|
|
|
int32_t maxBudget = aIsBackground ? gBackgroundThrottlingMaxBudget
|
|
|
|
: gForegroundThrottlingMaxBudget;
|
|
|
|
return maxBudget > 0 ? TimeDuration::FromMilliseconds(maxBudget)
|
|
|
|
: TimeDuration::Forever();
|
|
|
|
}
|
2017-08-18 15:16:47 +03:00
|
|
|
|
|
|
|
TimeDuration
|
|
|
|
GetMinBudget(bool aIsBackground)
|
|
|
|
{
|
|
|
|
// The minimum budget is computed by looking up the maximum allowed
|
|
|
|
// delay and computing how long time it would take to regenerate
|
|
|
|
// that budget using the regeneration factor. This number is
|
|
|
|
// expected to be negative.
|
|
|
|
return TimeDuration::FromMilliseconds(
|
|
|
|
- gBudgetThrottlingMaxDelay /
|
|
|
|
std::max(aIsBackground ? gBackgroundBudgetRegenerationFactor
|
|
|
|
: gForegroundBudgetRegenerationFactor,
|
|
|
|
1));
|
|
|
|
}
|
2017-06-14 18:47:38 +03:00
|
|
|
} // namespace
|
|
|
|
|
|
|
|
//
|
|
|
|
|
2017-05-02 14:23:00 +03:00
|
|
|
bool
|
|
|
|
TimeoutManager::IsBackground() const
|
|
|
|
{
|
2017-06-14 18:47:38 +03:00
|
|
|
return !IsActive() && mWindow.IsBackgroundInternal();
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
|
|
|
TimeoutManager::IsActive() const
|
|
|
|
{
|
|
|
|
// A window is considered active if:
|
|
|
|
// * It is a chrome window
|
|
|
|
// * It is playing audio
|
|
|
|
//
|
|
|
|
// Note that a window can be considered active if it is either in the
|
|
|
|
// foreground or in the background.
|
|
|
|
|
|
|
|
if (mWindow.IsChromeWindow()) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check if we're playing audio
|
|
|
|
if (mWindow.AsInner()->IsPlayingAudio()) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
2017-05-02 14:23:00 +03:00
|
|
|
}
|
|
|
|
|
2017-06-14 18:47:38 +03:00
|
|
|
|
2017-05-19 23:45:55 +03:00
|
|
|
uint32_t
|
|
|
|
TimeoutManager::CreateFiringId()
|
|
|
|
{
|
|
|
|
uint32_t id = mNextFiringId;
|
|
|
|
mNextFiringId += 1;
|
|
|
|
if (mNextFiringId == InvalidFiringId) {
|
|
|
|
mNextFiringId += 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
mFiringIdStack.AppendElement(id);
|
|
|
|
|
|
|
|
return id;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
TimeoutManager::DestroyFiringId(uint32_t aFiringId)
|
|
|
|
{
|
|
|
|
MOZ_DIAGNOSTIC_ASSERT(!mFiringIdStack.IsEmpty());
|
|
|
|
MOZ_DIAGNOSTIC_ASSERT(mFiringIdStack.LastElement() == aFiringId);
|
2018-03-13 16:51:33 +03:00
|
|
|
mFiringIdStack.RemoveLastElement();
|
2017-05-19 23:45:55 +03:00
|
|
|
}
|
|
|
|
|
2017-06-05 22:42:33 +03:00
|
|
|
bool
|
|
|
|
TimeoutManager::IsValidFiringId(uint32_t aFiringId) const
|
|
|
|
{
|
|
|
|
return !IsInvalidFiringId(aFiringId);
|
|
|
|
}
|
|
|
|
|
2017-06-14 04:08:27 +03:00
|
|
|
TimeDuration
|
|
|
|
TimeoutManager::MinSchedulingDelay() const
|
|
|
|
{
|
2017-06-14 18:47:38 +03:00
|
|
|
if (IsActive()) {
|
|
|
|
return TimeDuration();
|
|
|
|
}
|
|
|
|
|
|
|
|
bool isBackground = mWindow.IsBackgroundInternal();
|
|
|
|
|
|
|
|
// If a window isn't active as defined by TimeoutManager::IsActive()
|
|
|
|
// and we're throttling timeouts using an execution budget, we
|
|
|
|
// should adjust the minimum scheduling delay if we have used up all
|
|
|
|
// of our execution budget. Note that a window can be active or
|
|
|
|
// inactive regardless of wether it is in the foreground or in the
|
|
|
|
// background. Throttling using a budget depends largely on the
|
|
|
|
// regeneration factor, which can be specified separately for
|
|
|
|
// foreground and background windows.
|
|
|
|
//
|
|
|
|
// The value that we compute is the time in the future when we again
|
|
|
|
// have a positive execution budget. We do this by taking the
|
|
|
|
// execution budget into account, which if it positive implies that
|
|
|
|
// we have time left to execute, and if it is negative implies that
|
|
|
|
// we should throttle it until the budget again is positive. The
|
|
|
|
// factor used is the rate of budget regeneration.
|
|
|
|
//
|
|
|
|
// We clamp the delay to be less than or equal to
|
|
|
|
// gBudgetThrottlingMaxDelay to not entirely starve the timeouts.
|
|
|
|
//
|
|
|
|
// Consider these examples assuming we should throttle using
|
|
|
|
// budgets:
|
|
|
|
//
|
|
|
|
// mExecutionBudget is 20ms
|
|
|
|
// factor is 1, which is 1 ms/ms
|
|
|
|
// delay is 0ms
|
|
|
|
// then we will compute the minimum delay:
|
|
|
|
// max(0, - 20 * 1) = 0
|
|
|
|
//
|
|
|
|
// mExecutionBudget is -50ms
|
|
|
|
// factor is 0.1, which is 1 ms/10ms
|
|
|
|
// delay is 1000ms
|
|
|
|
// then we will compute the minimum delay:
|
|
|
|
// max(1000, - (- 50) * 1/0.1) = max(1000, 500) = 1000
|
|
|
|
//
|
|
|
|
// mExecutionBudget is -15ms
|
|
|
|
// factor is 0.01, which is 1 ms/100ms
|
|
|
|
// delay is 1000ms
|
|
|
|
// then we will compute the minimum delay:
|
|
|
|
// max(1000, - (- 15) * 1/0.01) = max(1000, 1500) = 1500
|
|
|
|
TimeDuration unthrottled =
|
|
|
|
isBackground ? TimeDuration::FromMilliseconds(gMinBackgroundTimeoutValue)
|
|
|
|
: TimeDuration();
|
2017-07-28 16:31:00 +03:00
|
|
|
if (BudgetThrottlingEnabled(isBackground) &&
|
|
|
|
mExecutionBudget < TimeDuration()) {
|
2017-06-14 18:47:38 +03:00
|
|
|
// Only throttle if execution budget is less than 0
|
|
|
|
double factor = 1.0 / GetRegenerationFactor(mWindow.IsBackgroundInternal());
|
2017-08-18 15:16:47 +03:00
|
|
|
return TimeDuration::Max(unthrottled, -mExecutionBudget.MultDouble(factor));
|
2017-06-14 04:08:27 +03:00
|
|
|
}
|
2017-06-14 18:47:38 +03:00
|
|
|
//
|
|
|
|
return unthrottled;
|
|
|
|
}
|
|
|
|
|
|
|
|
nsresult
|
|
|
|
TimeoutManager::MaybeSchedule(const TimeStamp& aWhen, const TimeStamp& aNow)
|
|
|
|
{
|
|
|
|
MOZ_DIAGNOSTIC_ASSERT(mExecutor);
|
|
|
|
|
|
|
|
// Before we can schedule the executor we need to make sure that we
|
|
|
|
// have an updated execution budget.
|
|
|
|
UpdateBudget(aNow);
|
|
|
|
return mExecutor->MaybeSchedule(aWhen, MinSchedulingDelay());
|
2017-06-14 04:08:27 +03:00
|
|
|
}
|
|
|
|
|
2017-05-19 23:45:55 +03:00
|
|
|
bool
|
|
|
|
TimeoutManager::IsInvalidFiringId(uint32_t aFiringId) const
|
|
|
|
{
|
|
|
|
// Check the most common ways to invalidate a firing id first.
|
|
|
|
// These should be quite fast.
|
|
|
|
if (aFiringId == InvalidFiringId ||
|
2017-06-05 22:42:33 +03:00
|
|
|
mFiringIdStack.IsEmpty()) {
|
2017-05-19 23:45:55 +03:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-06-05 22:42:33 +03:00
|
|
|
if (mFiringIdStack.Length() == 1) {
|
|
|
|
return mFiringIdStack[0] != aFiringId;
|
|
|
|
}
|
|
|
|
|
2017-05-19 23:45:55 +03:00
|
|
|
// Next do a range check on the first and last items in the stack
|
|
|
|
// of active firing ids. This is a bit slower.
|
|
|
|
uint32_t low = mFiringIdStack[0];
|
|
|
|
uint32_t high = mFiringIdStack.LastElement();
|
|
|
|
MOZ_DIAGNOSTIC_ASSERT(low != high);
|
|
|
|
if (low > high) {
|
|
|
|
// If the first element is bigger than the last element in the
|
|
|
|
// stack, that means mNextFiringId wrapped around to zero at
|
|
|
|
// some point.
|
|
|
|
Swap(low, high);
|
|
|
|
}
|
|
|
|
MOZ_DIAGNOSTIC_ASSERT(low < high);
|
|
|
|
|
|
|
|
if (aFiringId < low || aFiringId > high) {
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Finally, fall back to verifying the firing id is not anywhere
|
|
|
|
// in the stack. This could be slow for a large stack, but that
|
|
|
|
// should be rare. It can only happen with deeply nested event
|
|
|
|
// loop spinning. For example, a page that does a lot of timers
|
|
|
|
// and a lot of sync XHRs within those timers could be slow here.
|
|
|
|
return !mFiringIdStack.Contains(aFiringId);
|
|
|
|
}
|
|
|
|
|
2017-06-16 03:30:47 +03:00
|
|
|
// The number of nested timeouts before we start clamping. HTML5 says 1, WebKit
|
|
|
|
// uses 5.
|
2017-07-25 18:35:12 +03:00
|
|
|
#define DOM_CLAMP_TIMEOUT_NESTING_LEVEL 5u
|
2017-06-16 03:30:47 +03:00
|
|
|
|
2017-06-16 03:30:48 +03:00
|
|
|
TimeDuration
|
2017-06-16 03:30:47 +03:00
|
|
|
TimeoutManager::CalculateDelay(Timeout* aTimeout) const {
|
2017-06-16 03:30:47 +03:00
|
|
|
MOZ_DIAGNOSTIC_ASSERT(aTimeout);
|
2017-06-16 03:30:48 +03:00
|
|
|
TimeDuration result = aTimeout->mInterval;
|
2017-06-16 03:30:47 +03:00
|
|
|
|
2017-07-25 18:35:12 +03:00
|
|
|
if (aTimeout->mNestingLevel >= DOM_CLAMP_TIMEOUT_NESTING_LEVEL) {
|
2017-06-16 03:30:48 +03:00
|
|
|
result = TimeDuration::Max(
|
|
|
|
result, TimeDuration::FromMilliseconds(gMinClampTimeoutValue));
|
2017-06-16 03:30:47 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if (aTimeout->mIsTracking && mThrottleTrackingTimeouts) {
|
2017-06-16 03:30:48 +03:00
|
|
|
result = TimeDuration::Max(
|
|
|
|
result, TimeDuration::FromMilliseconds(gMinTrackingTimeoutValue));
|
2017-06-16 03:30:47 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return result;
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
|
2017-05-30 14:08:11 +03:00
|
|
|
void
|
|
|
|
TimeoutManager::RecordExecution(Timeout* aRunningTimeout,
|
|
|
|
Timeout* aTimeout)
|
|
|
|
{
|
|
|
|
if (mWindow.IsChromeWindow()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-06-19 11:11:47 +03:00
|
|
|
TimeoutBudgetManager& budgetManager = TimeoutBudgetManager::Get();
|
2017-05-30 14:08:11 +03:00
|
|
|
TimeStamp now = TimeStamp::Now();
|
2017-06-19 11:11:47 +03:00
|
|
|
|
2017-05-30 14:08:11 +03:00
|
|
|
if (aRunningTimeout) {
|
|
|
|
// If we're running a timeout callback, record any execution until
|
|
|
|
// now.
|
2017-06-14 18:47:38 +03:00
|
|
|
TimeDuration duration = budgetManager.RecordExecution(
|
2017-06-19 11:11:47 +03:00
|
|
|
now, aRunningTimeout, mWindow.IsBackgroundInternal());
|
|
|
|
budgetManager.MaybeCollectTelemetry(now);
|
2017-06-14 18:47:38 +03:00
|
|
|
|
|
|
|
UpdateBudget(now, duration);
|
2017-05-30 14:08:11 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if (aTimeout) {
|
|
|
|
// If we're starting a new timeout callback, start recording.
|
2017-06-19 11:11:47 +03:00
|
|
|
budgetManager.StartRecording(now);
|
2017-05-30 14:08:11 +03:00
|
|
|
} else {
|
2017-06-19 11:11:47 +03:00
|
|
|
// Else stop by clearing the start timestamp.
|
|
|
|
budgetManager.StopRecording();
|
2017-05-30 14:08:11 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-14 18:47:38 +03:00
|
|
|
void
|
|
|
|
TimeoutManager::UpdateBudget(const TimeStamp& aNow, const TimeDuration& aDuration)
|
|
|
|
{
|
|
|
|
if (mWindow.IsChromeWindow()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// The budget is adjusted by increasing it with the time since the
|
|
|
|
// last budget update factored with the regeneration rate. If a
|
|
|
|
// runnable has executed, subtract that duration from the
|
|
|
|
// budget. The budget updated without consideration of wether the
|
|
|
|
// window is active or not. If throttling is enabled and the window
|
|
|
|
// is active and then becomes inactive, an overdrawn budget will
|
|
|
|
// still be counted against the minimum delay.
|
2017-07-28 16:31:00 +03:00
|
|
|
bool isBackground = mWindow.IsBackgroundInternal();
|
|
|
|
if (BudgetThrottlingEnabled(isBackground)) {
|
2017-06-14 18:47:38 +03:00
|
|
|
double factor = GetRegenerationFactor(isBackground);
|
|
|
|
TimeDuration regenerated = (aNow - mLastBudgetUpdate).MultDouble(factor);
|
2017-08-18 15:16:47 +03:00
|
|
|
// Clamp the budget to the range of minimum and maximum allowed budget.
|
|
|
|
mExecutionBudget = TimeDuration::Max(
|
|
|
|
GetMinBudget(isBackground),
|
|
|
|
TimeDuration::Min(GetMaxBudget(isBackground),
|
|
|
|
mExecutionBudget - aDuration + regenerated));
|
2017-08-25 16:06:28 +03:00
|
|
|
} else {
|
|
|
|
// If budget throttling isn't enabled, reset the execution budget
|
|
|
|
// to the max budget specified in preferences. Always doing this
|
|
|
|
// will catch the case of BudgetThrottlingEnabled going from
|
|
|
|
// returning true to returning false. This prevent us from looping
|
|
|
|
// in RunTimeout, due to totalTimeLimit being set to zero and no
|
|
|
|
// timeouts being executed, even though budget throttling isn't
|
|
|
|
// active at the moment.
|
|
|
|
mExecutionBudget = GetMaxBudget(isBackground);
|
2017-06-14 18:47:38 +03:00
|
|
|
}
|
2017-08-25 16:06:28 +03:00
|
|
|
|
2017-06-14 18:47:38 +03:00
|
|
|
mLastBudgetUpdate = aNow;
|
|
|
|
}
|
|
|
|
|
2016-12-16 00:24:43 +03:00
|
|
|
#define TRACKING_SEPARATE_TIMEOUT_BUCKETING_STRATEGY 0 // Consider all timeouts coming from tracking scripts as tracking
|
|
|
|
// These strategies are useful for testing.
|
|
|
|
#define ALL_NORMAL_TIMEOUT_BUCKETING_STRATEGY 1 // Consider all timeouts as normal
|
|
|
|
#define ALTERNATE_TIMEOUT_BUCKETING_STRATEGY 2 // Put every other timeout in the list of tracking timeouts
|
|
|
|
#define RANDOM_TIMEOUT_BUCKETING_STRATEGY 3 // Put timeouts into either the normal or tracking timeouts list randomly
|
|
|
|
static int32_t gTimeoutBucketingStrategy = 0;
|
|
|
|
|
2017-06-14 18:47:38 +03:00
|
|
|
#define DEFAULT_TIMEOUT_THROTTLING_DELAY -1 // Only positive integers cause us to introduce a delay for
|
2017-02-13 23:58:39 +03:00
|
|
|
// timeout throttling.
|
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
// The longest interval (as PRIntervalTime) we permit, or that our
|
|
|
|
// timer code can handle, really. See DELAY_INTERVAL_LIMIT in
|
|
|
|
// nsTimerImpl.h for details.
|
|
|
|
#define DOM_MAX_TIMEOUT_VALUE DELAY_INTERVAL_LIMIT
|
|
|
|
|
|
|
|
uint32_t TimeoutManager::sNestingLevel = 0;
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
2017-05-19 23:45:55 +03:00
|
|
|
// The maximum number of milliseconds to allow consecutive timer callbacks
|
|
|
|
// to run in a single event loop runnable.
|
|
|
|
#define DEFAULT_MAX_CONSECUTIVE_CALLBACKS_MILLISECONDS 4
|
|
|
|
uint32_t gMaxConsecutiveCallbacksMilliseconds;
|
|
|
|
|
2017-06-23 17:03:30 +03:00
|
|
|
// Only propagate the open window click permission if the setTimeout() is equal
|
|
|
|
// to or less than this value.
|
|
|
|
#define DEFAULT_DISABLE_OPEN_CLICK_DELAY 0
|
|
|
|
int32_t gDisableOpenClickDelay;
|
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
} // anonymous namespace
|
|
|
|
|
2017-11-04 01:25:38 +03:00
|
|
|
TimeoutManager::TimeoutManager(nsGlobalWindowInner& aWindow)
|
2016-12-03 01:22:48 +03:00
|
|
|
: mWindow(aWindow),
|
2017-06-01 03:13:19 +03:00
|
|
|
mExecutor(new TimeoutExecutor(this)),
|
2017-06-05 22:42:33 +03:00
|
|
|
mNormalTimeouts(*this),
|
|
|
|
mTrackingTimeouts(*this),
|
2016-12-03 01:22:48 +03:00
|
|
|
mTimeoutIdCounter(1),
|
2017-05-19 23:45:55 +03:00
|
|
|
mNextFiringId(InvalidFiringId + 1),
|
2016-12-03 01:22:48 +03:00
|
|
|
mRunningTimeout(nullptr),
|
|
|
|
mIdleCallbackTimeoutCounter(1),
|
2017-06-14 18:47:38 +03:00
|
|
|
mLastBudgetUpdate(TimeStamp::Now()),
|
|
|
|
mExecutionBudget(GetMaxBudget(mWindow.IsBackgroundInternal())),
|
|
|
|
mThrottleTimeouts(false),
|
|
|
|
mThrottleTrackingTimeouts(false),
|
|
|
|
mBudgetThrottleTimeouts(false)
|
2016-12-03 01:22:48 +03:00
|
|
|
{
|
2017-01-10 06:16:31 +03:00
|
|
|
MOZ_LOG(gLog, LogLevel::Debug,
|
|
|
|
("TimeoutManager %p created, tracking bucketing %s\n",
|
|
|
|
this, gAnnotateTrackingChannels ? "enabled" : "disabled"));
|
|
|
|
}
|
|
|
|
|
|
|
|
TimeoutManager::~TimeoutManager()
|
|
|
|
{
|
2017-05-15 14:06:28 +03:00
|
|
|
MOZ_DIAGNOSTIC_ASSERT(mWindow.AsInner()->InnerObjectsFreed());
|
2017-06-14 18:47:38 +03:00
|
|
|
MOZ_DIAGNOSTIC_ASSERT(!mThrottleTimeoutsTimer);
|
2017-02-13 23:58:39 +03:00
|
|
|
|
2017-06-01 03:13:19 +03:00
|
|
|
mExecutor->Shutdown();
|
|
|
|
|
2017-01-10 06:16:31 +03:00
|
|
|
MOZ_LOG(gLog, LogLevel::Debug,
|
|
|
|
("TimeoutManager %p destroyed\n", this));
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
/* static */
|
|
|
|
void
|
|
|
|
TimeoutManager::Initialize()
|
|
|
|
{
|
2017-06-16 03:30:47 +03:00
|
|
|
Preferences::AddIntVarCache(&gMinClampTimeoutValue,
|
2016-12-03 01:22:48 +03:00
|
|
|
"dom.min_timeout_value",
|
2017-06-16 03:30:47 +03:00
|
|
|
DEFAULT_MIN_CLAMP_TIMEOUT_VALUE);
|
2016-12-03 01:22:48 +03:00
|
|
|
Preferences::AddIntVarCache(&gMinBackgroundTimeoutValue,
|
|
|
|
"dom.min_background_timeout_value",
|
|
|
|
DEFAULT_MIN_BACKGROUND_TIMEOUT_VALUE);
|
2016-12-22 06:56:45 +03:00
|
|
|
Preferences::AddIntVarCache(&gMinTrackingTimeoutValue,
|
|
|
|
"dom.min_tracking_timeout_value",
|
|
|
|
DEFAULT_MIN_TRACKING_TIMEOUT_VALUE);
|
|
|
|
Preferences::AddIntVarCache(&gMinTrackingBackgroundTimeoutValue,
|
|
|
|
"dom.min_tracking_background_timeout_value",
|
2016-12-14 23:52:57 +03:00
|
|
|
DEFAULT_MIN_TRACKING_BACKGROUND_TIMEOUT_VALUE);
|
2016-12-16 00:24:43 +03:00
|
|
|
Preferences::AddIntVarCache(&gTimeoutBucketingStrategy,
|
|
|
|
"dom.timeout_bucketing_strategy",
|
|
|
|
TRACKING_SEPARATE_TIMEOUT_BUCKETING_STRATEGY);
|
2017-06-14 18:47:38 +03:00
|
|
|
Preferences::AddIntVarCache(&gTimeoutThrottlingDelay,
|
|
|
|
"dom.timeout.throttling_delay",
|
|
|
|
DEFAULT_TIMEOUT_THROTTLING_DELAY);
|
|
|
|
|
2017-01-10 06:16:31 +03:00
|
|
|
Preferences::AddBoolVarCache(&gAnnotateTrackingChannels,
|
|
|
|
"privacy.trackingprotection.annotate_channels",
|
|
|
|
false);
|
2017-02-06 05:50:12 +03:00
|
|
|
|
2017-05-19 23:45:55 +03:00
|
|
|
Preferences::AddUintVarCache(&gMaxConsecutiveCallbacksMilliseconds,
|
|
|
|
"dom.timeout.max_consecutive_callbacks_ms",
|
|
|
|
DEFAULT_MAX_CONSECUTIVE_CALLBACKS_MILLISECONDS);
|
2017-06-23 17:03:30 +03:00
|
|
|
|
|
|
|
Preferences::AddIntVarCache(&gDisableOpenClickDelay,
|
|
|
|
"dom.disable_open_click_delay",
|
|
|
|
DEFAULT_DISABLE_OPEN_CLICK_DELAY);
|
2017-06-14 18:47:38 +03:00
|
|
|
Preferences::AddIntVarCache(&gBackgroundBudgetRegenerationFactor,
|
|
|
|
"dom.timeout.background_budget_regeneration_rate",
|
|
|
|
DEFAULT_BACKGROUND_BUDGET_REGENERATION_FACTOR);
|
|
|
|
Preferences::AddIntVarCache(&gForegroundBudgetRegenerationFactor,
|
|
|
|
"dom.timeout.foreground_budget_regeneration_rate",
|
|
|
|
DEFAULT_FOREGROUND_BUDGET_REGENERATION_FACTOR);
|
|
|
|
Preferences::AddIntVarCache(&gBackgroundThrottlingMaxBudget,
|
|
|
|
"dom.timeout.background_throttling_max_budget",
|
|
|
|
DEFAULT_BACKGROUND_THROTTLING_MAX_BUDGET);
|
|
|
|
Preferences::AddIntVarCache(&gForegroundThrottlingMaxBudget,
|
|
|
|
"dom.timeout.foreground_throttling_max_budget",
|
|
|
|
DEFAULT_FOREGROUND_THROTTLING_MAX_BUDGET);
|
|
|
|
Preferences::AddIntVarCache(&gBudgetThrottlingMaxDelay,
|
|
|
|
"dom.timeout.budget_throttling_max_delay",
|
|
|
|
DEFAULT_BUDGET_THROTTLING_MAX_DELAY);
|
|
|
|
Preferences::AddBoolVarCache(&gEnableBudgetTimeoutThrottling,
|
|
|
|
"dom.timeout.enable_budget_timer_throttling",
|
|
|
|
DEFAULT_ENABLE_BUDGET_TIMEOUT_THROTTLING);
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
uint32_t
|
|
|
|
TimeoutManager::GetTimeoutId(Timeout::Reason aReason)
|
|
|
|
{
|
|
|
|
switch (aReason) {
|
|
|
|
case Timeout::Reason::eIdleCallbackTimeout:
|
|
|
|
return ++mIdleCallbackTimeoutCounter;
|
|
|
|
case Timeout::Reason::eTimeoutOrInterval:
|
|
|
|
default:
|
|
|
|
return ++mTimeoutIdCounter;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-19 23:45:55 +03:00
|
|
|
bool
|
|
|
|
TimeoutManager::IsRunningTimeout() const
|
|
|
|
{
|
|
|
|
return mRunningTimeout;
|
|
|
|
}
|
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
nsresult
|
|
|
|
TimeoutManager::SetTimeout(nsITimeoutHandler* aHandler,
|
|
|
|
int32_t interval, bool aIsInterval,
|
|
|
|
Timeout::Reason aReason, int32_t* aReturn)
|
|
|
|
{
|
|
|
|
// If we don't have a document (we could have been unloaded since
|
|
|
|
// the call to setTimeout was made), do nothing.
|
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-16 00:17:38 +03:00
|
|
|
nsCOMPtr<nsIDocument> doc = mWindow.GetExtantDoc();
|
|
|
|
if (!doc) {
|
2016-12-03 01:22:48 +03:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2017-07-25 18:35:12 +03:00
|
|
|
// Disallow negative intervals.
|
|
|
|
interval = std::max(0, interval);
|
2016-12-03 01:22:48 +03:00
|
|
|
|
|
|
|
// Make sure we don't proceed with an interval larger than our timer
|
|
|
|
// code can handle. (Note: we already forced |interval| to be non-negative,
|
|
|
|
// so the uint32_t cast (to avoid compiler warnings) is ok.)
|
|
|
|
uint32_t maxTimeoutMs = PR_IntervalToMilliseconds(DOM_MAX_TIMEOUT_VALUE);
|
|
|
|
if (static_cast<uint32_t>(interval) > maxTimeoutMs) {
|
|
|
|
interval = maxTimeoutMs;
|
|
|
|
}
|
|
|
|
|
|
|
|
RefPtr<Timeout> timeout = new Timeout();
|
2017-06-16 03:30:47 +03:00
|
|
|
timeout->mWindow = &mWindow;
|
2016-12-03 01:22:48 +03:00
|
|
|
timeout->mIsInterval = aIsInterval;
|
2017-06-16 03:30:48 +03:00
|
|
|
timeout->mInterval = TimeDuration::FromMilliseconds(interval);
|
2016-12-03 01:22:48 +03:00
|
|
|
timeout->mScriptHandler = aHandler;
|
|
|
|
timeout->mReason = aReason;
|
|
|
|
|
2017-06-16 03:30:47 +03:00
|
|
|
// No popups from timeouts by default
|
|
|
|
timeout->mPopupState = openAbused;
|
|
|
|
|
2016-12-22 06:34:52 +03:00
|
|
|
switch (gTimeoutBucketingStrategy) {
|
|
|
|
default:
|
|
|
|
case TRACKING_SEPARATE_TIMEOUT_BUCKETING_STRATEGY: {
|
|
|
|
const char* filename = nullptr;
|
|
|
|
uint32_t dummyLine = 0, dummyColumn = 0;
|
|
|
|
aHandler->GetLocation(&filename, &dummyLine, &dummyColumn);
|
|
|
|
timeout->mIsTracking = doc->IsScriptTracking(nsDependentCString(filename));
|
2017-01-10 06:16:31 +03:00
|
|
|
|
|
|
|
MOZ_LOG(gLog, LogLevel::Debug,
|
|
|
|
("Classified timeout %p set from %s as %stracking\n",
|
|
|
|
timeout.get(), filename, timeout->mIsTracking ? "" : "non-"));
|
2016-12-22 06:34:52 +03:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case ALL_NORMAL_TIMEOUT_BUCKETING_STRATEGY:
|
|
|
|
// timeout->mIsTracking is already false!
|
|
|
|
MOZ_DIAGNOSTIC_ASSERT(!timeout->mIsTracking);
|
2017-01-10 06:16:31 +03:00
|
|
|
|
|
|
|
MOZ_LOG(gLog, LogLevel::Debug,
|
|
|
|
("Classified timeout %p unconditionally as normal\n",
|
|
|
|
timeout.get()));
|
2016-12-22 06:34:52 +03:00
|
|
|
break;
|
|
|
|
case ALTERNATE_TIMEOUT_BUCKETING_STRATEGY:
|
|
|
|
timeout->mIsTracking = (mTimeoutIdCounter % 2) == 0;
|
2017-01-10 06:16:31 +03:00
|
|
|
|
|
|
|
MOZ_LOG(gLog, LogLevel::Debug,
|
|
|
|
("Classified timeout %p as %stracking (alternating mode)\n",
|
|
|
|
timeout.get(), timeout->mIsTracking ? "" : "non-"));
|
2016-12-22 06:34:52 +03:00
|
|
|
break;
|
|
|
|
case RANDOM_TIMEOUT_BUCKETING_STRATEGY:
|
|
|
|
timeout->mIsTracking = (rand() % 2) == 0;
|
2017-01-10 06:16:31 +03:00
|
|
|
|
|
|
|
MOZ_LOG(gLog, LogLevel::Debug,
|
|
|
|
("Classified timeout %p as %stracking (random mode)\n",
|
|
|
|
timeout.get(), timeout->mIsTracking ? "" : "non-"));
|
2016-12-22 06:34:52 +03:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2017-07-25 18:35:12 +03:00
|
|
|
timeout->mNestingLevel = sNestingLevel < DOM_CLAMP_TIMEOUT_NESTING_LEVEL
|
|
|
|
? sNestingLevel + 1 : sNestingLevel;
|
2017-06-16 03:30:47 +03:00
|
|
|
|
|
|
|
// Now clamp the actual interval we will use for the timer based on
|
2017-06-16 03:30:48 +03:00
|
|
|
TimeDuration realInterval = CalculateDelay(timeout);
|
2017-06-14 18:47:38 +03:00
|
|
|
TimeStamp now = TimeStamp::Now();
|
|
|
|
timeout->SetWhenOrTimeRemaining(now, realInterval);
|
2016-12-03 01:22:48 +03:00
|
|
|
|
|
|
|
// If we're not suspended, then set the timer.
|
|
|
|
if (!mWindow.IsSuspended()) {
|
2017-06-14 18:47:38 +03:00
|
|
|
nsresult rv = MaybeSchedule(timeout->When(), now);
|
2016-12-03 01:22:48 +03:00
|
|
|
if (NS_FAILED(rv)) {
|
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
if (gRunningTimeoutDepth == 0 &&
|
2017-11-18 01:09:20 +03:00
|
|
|
nsContentUtils::GetPopupControlState() < openBlocked) {
|
2016-12-03 01:22:48 +03:00
|
|
|
// This timeout is *not* set from another timeout and it's set
|
|
|
|
// while popups are enabled. Propagate the state to the timeout if
|
|
|
|
// its delay (interval) is equal to or less than what
|
|
|
|
// "dom.disable_open_click_delay" is set to (in ms).
|
|
|
|
|
|
|
|
// This is checking |interval|, not realInterval, on purpose,
|
|
|
|
// because our lower bound for |realInterval| could be pretty high
|
|
|
|
// in some cases.
|
2017-06-23 17:03:30 +03:00
|
|
|
if (interval <= gDisableOpenClickDelay) {
|
2017-11-18 01:09:20 +03:00
|
|
|
timeout->mPopupState = nsContentUtils::GetPopupControlState();
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
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-16 00:17:38 +03:00
|
|
|
Timeouts::SortBy sort(mWindow.IsFrozen() ? Timeouts::SortBy::TimeRemaining
|
|
|
|
: Timeouts::SortBy::TimeWhen);
|
2016-12-22 06:34:52 +03:00
|
|
|
if (timeout->mIsTracking) {
|
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-16 00:17:38 +03:00
|
|
|
mTrackingTimeouts.Insert(timeout, sort);
|
|
|
|
} else {
|
|
|
|
mNormalTimeouts.Insert(timeout, sort);
|
|
|
|
}
|
2016-12-03 01:22:48 +03:00
|
|
|
|
|
|
|
timeout->mTimeoutId = GetTimeoutId(aReason);
|
|
|
|
*aReturn = timeout->mTimeoutId;
|
|
|
|
|
2017-06-14 18:47:38 +03:00
|
|
|
MOZ_LOG(gLog,
|
|
|
|
LogLevel::Debug,
|
2017-02-13 23:58:39 +03:00
|
|
|
("Set%s(TimeoutManager=%p, timeout=%p, delay=%i, "
|
2017-06-14 18:47:38 +03:00
|
|
|
"minimum=%f, throttling=%s, state=%s(%s), realInterval=%f) "
|
|
|
|
"returned %stracking timeout ID %u, budget=%d\n",
|
2017-01-10 06:16:31 +03:00
|
|
|
aIsInterval ? "Interval" : "Timeout",
|
|
|
|
this, timeout.get(), interval,
|
2017-06-16 03:30:48 +03:00
|
|
|
(CalculateDelay(timeout) - timeout->mInterval).ToMilliseconds(),
|
2017-06-14 18:47:38 +03:00
|
|
|
mThrottleTimeouts
|
|
|
|
? "yes"
|
|
|
|
: (mThrottleTimeoutsTimer ? "pending" : "no"),
|
|
|
|
IsActive() ? "active" : "inactive",
|
|
|
|
mWindow.IsBackgroundInternal() ? "background" : "foreground",
|
|
|
|
realInterval.ToMilliseconds(),
|
2017-01-10 06:16:31 +03:00
|
|
|
timeout->mIsTracking ? "" : "non-",
|
2017-06-14 18:47:38 +03:00
|
|
|
timeout->mTimeoutId,
|
|
|
|
int(mExecutionBudget.ToMilliseconds())));
|
2017-01-10 06:16:31 +03:00
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
TimeoutManager::ClearTimeout(int32_t aTimerId, Timeout::Reason aReason)
|
|
|
|
{
|
|
|
|
uint32_t timerId = (uint32_t)aTimerId;
|
|
|
|
|
2017-06-01 03:13:19 +03:00
|
|
|
bool firstTimeout = true;
|
2017-06-09 05:13:36 +03:00
|
|
|
bool deferredDeletion = false;
|
2017-06-01 03:13:19 +03:00
|
|
|
|
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-16 00:17:38 +03:00
|
|
|
ForEachUnorderedTimeoutAbortable([&](Timeout* aTimeout) {
|
2017-01-10 06:16:31 +03:00
|
|
|
MOZ_LOG(gLog, LogLevel::Debug,
|
|
|
|
("Clear%s(TimeoutManager=%p, timeout=%p, aTimerId=%u, ID=%u, tracking=%d)\n", aTimeout->mIsInterval ? "Interval" : "Timeout",
|
|
|
|
this, aTimeout, timerId, aTimeout->mTimeoutId,
|
|
|
|
int(aTimeout->mIsTracking)));
|
|
|
|
|
2016-12-14 02:14:02 +03:00
|
|
|
if (aTimeout->mTimeoutId == timerId && aTimeout->mReason == aReason) {
|
|
|
|
if (aTimeout->mRunning) {
|
|
|
|
/* We're running from inside the aTimeout. Mark this
|
|
|
|
aTimeout for deferred deletion by the code in
|
2016-12-03 01:22:48 +03:00
|
|
|
RunTimeout() */
|
2016-12-14 02:14:02 +03:00
|
|
|
aTimeout->mIsInterval = false;
|
2017-06-09 05:13:36 +03:00
|
|
|
deferredDeletion = true;
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
else {
|
2016-12-14 02:14:02 +03:00
|
|
|
/* Delete the aTimeout from the pending aTimeout list */
|
|
|
|
aTimeout->remove();
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
2016-12-14 02:14:02 +03:00
|
|
|
return true; // abort!
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
2017-06-01 03:13:19 +03:00
|
|
|
|
|
|
|
firstTimeout = false;
|
|
|
|
|
2016-12-14 02:14:02 +03:00
|
|
|
return false;
|
|
|
|
});
|
2017-06-01 03:13:19 +03:00
|
|
|
|
2017-06-09 05:13:36 +03:00
|
|
|
// We don't need to reschedule the executor if any of the following are true:
|
|
|
|
// * If the we weren't cancelling the first timeout, then the executor's
|
|
|
|
// state doesn't need to change. It will only reflect the next soonest
|
|
|
|
// Timeout.
|
|
|
|
// * If we did cancel the first Timeout, but its currently running, then
|
|
|
|
// RunTimeout() will handle rescheduling the executor.
|
|
|
|
// * If the window has become suspended then we should not start executing
|
|
|
|
// Timeouts.
|
|
|
|
if (!firstTimeout || deferredDeletion || mWindow.IsSuspended()) {
|
2017-06-01 03:13:19 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-06-09 05:13:36 +03:00
|
|
|
// Stop the executor and restart it at the next soonest deadline.
|
2017-06-01 03:13:19 +03:00
|
|
|
mExecutor->Cancel();
|
|
|
|
|
2017-06-08 15:51:59 +03:00
|
|
|
OrderedTimeoutIterator iter(mNormalTimeouts, mTrackingTimeouts);
|
2017-06-01 03:13:19 +03:00
|
|
|
Timeout* nextTimeout = iter.Next();
|
|
|
|
if (nextTimeout) {
|
2017-06-14 18:47:38 +03:00
|
|
|
MOZ_ALWAYS_SUCCEEDS(MaybeSchedule(nextTimeout->When()));
|
2017-06-01 03:13:19 +03:00
|
|
|
}
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2017-06-01 03:13:19 +03:00
|
|
|
TimeoutManager::RunTimeout(const TimeStamp& aNow, const TimeStamp& aTargetDeadline)
|
2016-12-03 01:22:48 +03:00
|
|
|
{
|
2017-06-01 03:13:19 +03:00
|
|
|
MOZ_DIAGNOSTIC_ASSERT(!aNow.IsNull());
|
2017-06-01 03:13:18 +03:00
|
|
|
MOZ_DIAGNOSTIC_ASSERT(!aTargetDeadline.IsNull());
|
2017-06-01 03:13:18 +03:00
|
|
|
|
2017-06-09 05:13:37 +03:00
|
|
|
MOZ_ASSERT_IF(mWindow.IsFrozen(), mWindow.IsSuspended());
|
2016-12-03 01:22:48 +03:00
|
|
|
if (mWindow.IsSuspended()) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-05-19 23:45:55 +03:00
|
|
|
// Limit the overall time spent in RunTimeout() to reduce jank.
|
|
|
|
uint32_t totalTimeLimitMS = std::max(1u, gMaxConsecutiveCallbacksMilliseconds);
|
2017-06-14 18:47:38 +03:00
|
|
|
const TimeDuration totalTimeLimit =
|
|
|
|
TimeDuration::Min(TimeDuration::FromMilliseconds(totalTimeLimitMS),
|
|
|
|
TimeDuration::Max(TimeDuration(), mExecutionBudget));
|
2017-05-19 23:45:55 +03:00
|
|
|
|
|
|
|
// Allow up to 25% of our total time budget to be used figuring out which
|
|
|
|
// timers need to run. This is the initial loop in this method.
|
2017-06-14 18:47:38 +03:00
|
|
|
const TimeDuration initialTimeLimit =
|
2017-05-19 23:45:55 +03:00
|
|
|
TimeDuration::FromMilliseconds(totalTimeLimit.ToMilliseconds() / 4);
|
|
|
|
|
|
|
|
// Ammortize overhead from from calling TimeStamp::Now() in the initial
|
|
|
|
// loop, though, by only checking for an elapsed limit every N timeouts.
|
|
|
|
const uint32_t kNumTimersPerInitialElapsedCheck = 100;
|
|
|
|
|
|
|
|
// Start measuring elapsed time immediately. We won't potentially expire
|
|
|
|
// the time budget until at least one Timeout has run, though.
|
2017-06-01 03:13:19 +03:00
|
|
|
TimeStamp now(aNow);
|
|
|
|
TimeStamp start = now;
|
2017-05-19 23:45:55 +03:00
|
|
|
|
2017-05-19 23:45:55 +03:00
|
|
|
uint32_t firingId = CreateFiringId();
|
|
|
|
auto guard = MakeScopeExit([&] {
|
|
|
|
DestroyFiringId(firingId);
|
|
|
|
});
|
2016-12-03 01:22:48 +03:00
|
|
|
|
|
|
|
// Make sure that the window and the script context don't go away as
|
|
|
|
// a result of running timeouts
|
|
|
|
nsCOMPtr<nsIScriptGlobalObject> windowKungFuDeathGrip(&mWindow);
|
|
|
|
// Silence the static analysis error about windowKungFuDeathGrip. Accessing
|
|
|
|
// members of mWindow here is safe, because the lifetime of TimeoutManager is
|
|
|
|
// the same as the lifetime of the containing nsGlobalWindow.
|
|
|
|
Unused << windowKungFuDeathGrip;
|
|
|
|
|
|
|
|
// A native timer has gone off. See which of our timeouts need
|
|
|
|
// servicing
|
|
|
|
TimeStamp deadline;
|
|
|
|
|
2017-06-01 03:13:18 +03:00
|
|
|
if (aTargetDeadline > now) {
|
2016-12-03 01:22:48 +03:00
|
|
|
// The OS timer fired early (which can happen due to the timers
|
|
|
|
// having lower precision than TimeStamp does). Set |deadline| to
|
|
|
|
// be the time when the OS timer *should* have fired so that any
|
2017-06-01 03:13:18 +03:00
|
|
|
// timers that *should* have fired *will* be fired now.
|
2016-12-03 01:22:48 +03:00
|
|
|
|
2017-06-01 03:13:18 +03:00
|
|
|
deadline = aTargetDeadline;
|
2016-12-03 01:22:48 +03:00
|
|
|
} else {
|
|
|
|
deadline = now;
|
|
|
|
}
|
|
|
|
|
2017-06-01 03:13:19 +03:00
|
|
|
TimeStamp nextDeadline;
|
2017-06-08 15:51:59 +03:00
|
|
|
uint32_t numTimersToRun = 0;
|
2017-06-01 03:13:19 +03:00
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
// The timeout list is kept in deadline order. Discover the latest timeout
|
|
|
|
// whose deadline has expired. On some platforms, native timeout events fire
|
2017-06-01 03:13:18 +03:00
|
|
|
// "early", but we handled that above by setting deadline to aTargetDeadline
|
2016-12-03 01:22:48 +03:00
|
|
|
// if the timer fired early. So we can stop walking if we get to timeouts
|
2017-01-10 19:08:18 +03:00
|
|
|
// whose When() is greater than deadline, since once that happens we know
|
2016-12-03 01:22:48 +03:00
|
|
|
// nothing past that point is expired.
|
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-16 00:17:38 +03:00
|
|
|
{
|
|
|
|
// Use a nested scope in order to make sure the strong references held by
|
|
|
|
// the iterator are freed after the loop.
|
2017-06-08 15:51:59 +03:00
|
|
|
OrderedTimeoutIterator expiredIter(mNormalTimeouts, mTrackingTimeouts);
|
2017-02-28 01:33:30 +03:00
|
|
|
|
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-16 00:17:38 +03:00
|
|
|
while (true) {
|
|
|
|
Timeout* timeout = expiredIter.Next();
|
2017-06-14 18:47:38 +03:00
|
|
|
if (!timeout || totalTimeLimit.IsZero() || timeout->When() > deadline) {
|
2017-06-01 03:13:19 +03:00
|
|
|
if (timeout) {
|
|
|
|
nextDeadline = timeout->When();
|
|
|
|
}
|
2016-12-03 01:22:48 +03:00
|
|
|
break;
|
|
|
|
}
|
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-16 00:17:38 +03:00
|
|
|
|
2017-05-19 23:45:55 +03:00
|
|
|
if (IsInvalidFiringId(timeout->mFiringId)) {
|
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-16 00:17:38 +03:00
|
|
|
// Mark any timeouts that are on the list to be fired with the
|
|
|
|
// firing depth so that we can reentrantly run timeouts
|
2017-05-19 23:45:55 +03:00
|
|
|
timeout->mFiringId = firingId;
|
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-16 00:17:38 +03:00
|
|
|
|
2017-03-02 19:33:11 +03:00
|
|
|
numTimersToRun += 1;
|
|
|
|
|
2017-06-01 03:13:18 +03:00
|
|
|
// Run only a limited number of timers based on the configured maximum.
|
|
|
|
if (numTimersToRun % kNumTimersPerInitialElapsedCheck == 0) {
|
2017-06-01 03:13:19 +03:00
|
|
|
now = TimeStamp::Now();
|
|
|
|
TimeDuration elapsed(now - start);
|
2017-06-14 18:47:38 +03:00
|
|
|
if (elapsed >= initialTimeLimit) {
|
2017-06-01 03:13:19 +03:00
|
|
|
nextDeadline = timeout->When();
|
2017-06-01 03:13:18 +03:00
|
|
|
break;
|
2017-05-19 23:45:55 +03:00
|
|
|
}
|
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-16 00:17:38 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
expiredIter.UpdateIterator();
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-06-01 03:13:19 +03:00
|
|
|
now = TimeStamp::Now();
|
|
|
|
|
|
|
|
// Wherever we stopped in the timer list, schedule the executor to
|
|
|
|
// run for the next unexpired deadline. Note, this *must* be done
|
|
|
|
// before we start executing any content script handlers. If one
|
|
|
|
// of them spins the event loop the executor must already be scheduled
|
|
|
|
// in order for timeouts to fire properly.
|
|
|
|
if (!nextDeadline.IsNull()) {
|
2017-06-09 05:13:37 +03:00
|
|
|
// Note, we verified the window is not suspended at the top of
|
|
|
|
// method and the window should not have been suspended while
|
|
|
|
// executing the loop above since it doesn't call out to js.
|
|
|
|
MOZ_DIAGNOSTIC_ASSERT(!mWindow.IsSuspended());
|
2017-06-14 18:47:38 +03:00
|
|
|
MOZ_ALWAYS_SUCCEEDS(MaybeSchedule(nextDeadline, now));
|
2017-06-01 03:13:19 +03:00
|
|
|
}
|
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
// Maybe the timeout that the event was fired for has been deleted
|
|
|
|
// and there are no others timeouts with deadlines that make them
|
|
|
|
// eligible for execution yet. Go away.
|
2017-06-08 15:51:59 +03:00
|
|
|
if (!numTimersToRun) {
|
2016-12-03 01:22:48 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
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-16 00:17:38 +03:00
|
|
|
// Now we need to search the normal and tracking timer list at the same
|
|
|
|
// time to run the timers in the scheduled order.
|
2016-12-03 01:22:48 +03:00
|
|
|
|
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-16 00:17:38 +03:00
|
|
|
// We stop iterating each list when we go past the last expired timeout from
|
|
|
|
// that list that we have observed above. That timeout will either be the
|
2017-06-05 22:42:33 +03:00
|
|
|
// next item after the last timeout we looked at or nullptr if we have
|
|
|
|
// exhausted the entire list while looking for the last expired timeout.
|
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-16 00:17:38 +03:00
|
|
|
{
|
|
|
|
// Use a nested scope in order to make sure the strong references held by
|
|
|
|
// the iterator are freed after the loop.
|
2017-06-08 15:51:59 +03:00
|
|
|
OrderedTimeoutIterator runIter(mNormalTimeouts, mTrackingTimeouts);
|
2017-05-19 23:45:55 +03:00
|
|
|
while (true) {
|
2017-06-01 03:13:18 +03:00
|
|
|
RefPtr<Timeout> timeout = runIter.Next();
|
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-16 00:17:38 +03:00
|
|
|
if (!timeout) {
|
|
|
|
// We have run out of timeouts!
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
runIter.UpdateIterator();
|
2016-12-03 01:22:48 +03:00
|
|
|
|
2017-06-08 15:51:58 +03:00
|
|
|
// We should only execute callbacks for the set of expired Timeout
|
|
|
|
// objects we computed above.
|
2017-05-19 23:45:55 +03:00
|
|
|
if (timeout->mFiringId != firingId) {
|
2017-06-08 15:51:58 +03:00
|
|
|
// If the FiringId does not match, but is still valid, then this is
|
|
|
|
// a TImeout for another RunTimeout() on the call stack. Just
|
|
|
|
// skip it.
|
|
|
|
if (IsValidFiringId(timeout->mFiringId)) {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// If, however, the FiringId is invalid then we have reached Timeout
|
|
|
|
// objects beyond the list we calculated above. This can happen
|
|
|
|
// if the Timeout just beyond our last expired Timeout is cancelled
|
|
|
|
// by one of the callbacks we've just executed. In this case we
|
|
|
|
// should just stop iterating. We're done.
|
|
|
|
else {
|
|
|
|
break;
|
|
|
|
}
|
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-16 00:17:38 +03:00
|
|
|
}
|
2016-12-03 01:22:48 +03:00
|
|
|
|
2017-05-19 23:45:55 +03:00
|
|
|
MOZ_ASSERT_IF(mWindow.IsFrozen(), mWindow.IsSuspended());
|
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-16 00:17:38 +03:00
|
|
|
if (mWindow.IsSuspended()) {
|
2017-05-19 23:45:55 +03:00
|
|
|
break;
|
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-16 00:17:38 +03:00
|
|
|
}
|
2016-12-03 01:22:48 +03:00
|
|
|
|
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-16 00:17:38 +03:00
|
|
|
// The timeout is on the list to run at this depth, go ahead and
|
|
|
|
// process it.
|
2016-12-03 01:22:48 +03:00
|
|
|
|
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-16 00:17:38 +03:00
|
|
|
// Get the script context (a strong ref to prevent it going away)
|
|
|
|
// for this timeout and ensure the script language is enabled.
|
|
|
|
nsCOMPtr<nsIScriptContext> scx = mWindow.GetContextInternal();
|
2016-12-03 01:22:48 +03:00
|
|
|
|
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-16 00:17:38 +03:00
|
|
|
if (!scx) {
|
|
|
|
// No context means this window was closed or never properly
|
2017-05-19 23:45:55 +03:00
|
|
|
// initialized for this language. This timer will never fire
|
|
|
|
// so just remove it.
|
|
|
|
timeout->remove();
|
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-16 00:17:38 +03:00
|
|
|
continue;
|
|
|
|
}
|
2016-12-03 01:22:48 +03:00
|
|
|
|
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-16 00:17:38 +03:00
|
|
|
// This timeout is good to run
|
|
|
|
bool timeout_was_cleared = mWindow.RunTimeoutHandler(timeout, scx);
|
2017-01-10 06:16:31 +03:00
|
|
|
MOZ_LOG(gLog, LogLevel::Debug,
|
2017-06-01 03:13:18 +03:00
|
|
|
("Run%s(TimeoutManager=%p, timeout=%p, tracking=%d) returned %d\n", timeout->mIsInterval ? "Interval" : "Timeout",
|
2017-06-01 03:13:18 +03:00
|
|
|
this, timeout.get(),
|
2017-06-01 03:13:18 +03:00
|
|
|
int(timeout->mIsTracking),
|
2017-01-10 06:16:31 +03:00
|
|
|
!!timeout_was_cleared));
|
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-16 00:17:38 +03:00
|
|
|
|
|
|
|
if (timeout_was_cleared) {
|
|
|
|
// Make sure the iterator isn't holding any Timeout objects alive.
|
|
|
|
runIter.Clear();
|
|
|
|
|
2017-05-19 23:45:55 +03:00
|
|
|
// Since ClearAllTimeouts() was called the lists should be empty.
|
|
|
|
MOZ_DIAGNOSTIC_ASSERT(!HasTimeouts());
|
|
|
|
|
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-16 00:17:38 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-07-06 17:01:40 +03:00
|
|
|
// If we need to reschedule a setInterval() the delay should be
|
|
|
|
// calculated based on when its callback started to execute. So
|
|
|
|
// save off the last time before updating our "now" timestamp to
|
|
|
|
// account for its callback execution time.
|
|
|
|
TimeStamp lastCallbackTime = now;
|
2017-06-01 03:13:19 +03:00
|
|
|
now = TimeStamp::Now();
|
|
|
|
|
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-16 00:17:38 +03:00
|
|
|
// If we have a regular interval timer, we re-schedule the
|
|
|
|
// timeout, accounting for clock drift.
|
2017-07-06 17:01:40 +03:00
|
|
|
bool needsReinsertion = RescheduleTimeout(timeout, lastCallbackTime, now);
|
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-16 00:17:38 +03:00
|
|
|
|
|
|
|
// Running a timeout can cause another timeout to be deleted, so
|
|
|
|
// we need to reset the pointer to the following timeout.
|
|
|
|
runIter.UpdateIterator();
|
2016-12-03 01:22:48 +03:00
|
|
|
|
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-16 00:17:38 +03:00
|
|
|
timeout->remove();
|
|
|
|
|
|
|
|
if (needsReinsertion) {
|
|
|
|
// Insert interval timeout onto the corresponding list sorted in
|
|
|
|
// deadline order. AddRefs timeout.
|
|
|
|
if (runIter.PickedTrackingIter()) {
|
|
|
|
mTrackingTimeouts.Insert(timeout,
|
|
|
|
mWindow.IsFrozen() ? Timeouts::SortBy::TimeRemaining
|
|
|
|
: Timeouts::SortBy::TimeWhen);
|
|
|
|
} else {
|
|
|
|
mNormalTimeouts.Insert(timeout,
|
|
|
|
mWindow.IsFrozen() ? Timeouts::SortBy::TimeRemaining
|
|
|
|
: Timeouts::SortBy::TimeWhen);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-05-19 23:45:55 +03:00
|
|
|
// Check to see if we have run out of time to execute timeout handlers.
|
|
|
|
// If we've exceeded our time budget then terminate the loop immediately.
|
2017-06-01 03:13:19 +03:00
|
|
|
TimeDuration elapsed = now - start;
|
2017-06-01 03:13:18 +03:00
|
|
|
if (elapsed >= totalTimeLimit) {
|
2017-06-01 03:13:19 +03:00
|
|
|
// We ran out of time. Make sure to schedule the executor to
|
2017-06-09 05:13:37 +03:00
|
|
|
// run immediately for the next timer, if it exists. Its possible,
|
|
|
|
// however, that the last timeout handler suspended the window. If
|
|
|
|
// that happened then we must skip this step.
|
|
|
|
if (!mWindow.IsSuspended()) {
|
|
|
|
RefPtr<Timeout> timeout = runIter.Next();
|
|
|
|
if (timeout) {
|
2017-06-14 18:47:38 +03:00
|
|
|
// If we ran out of execution budget we need to force a
|
|
|
|
// reschedule. By cancelling the executor we will not run
|
|
|
|
// immediately, but instead reschedule to the minimum
|
|
|
|
// scheduling delay.
|
|
|
|
if (mExecutionBudget < TimeDuration()) {
|
|
|
|
mExecutor->Cancel();
|
|
|
|
}
|
|
|
|
|
|
|
|
MOZ_ALWAYS_SUCCEEDS(MaybeSchedule(timeout->When(), now));
|
2017-06-09 05:13:37 +03:00
|
|
|
}
|
2017-06-01 03:13:19 +03:00
|
|
|
}
|
2017-06-01 03:13:18 +03:00
|
|
|
break;
|
2017-05-19 23:45:55 +03:00
|
|
|
}
|
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-16 00:17:38 +03:00
|
|
|
}
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
bool
|
2017-07-06 17:01:40 +03:00
|
|
|
TimeoutManager::RescheduleTimeout(Timeout* aTimeout,
|
|
|
|
const TimeStamp& aLastCallbackTime,
|
|
|
|
const TimeStamp& aCurrentNow)
|
2016-12-03 01:22:48 +03:00
|
|
|
{
|
2017-07-06 17:01:40 +03:00
|
|
|
MOZ_DIAGNOSTIC_ASSERT(aLastCallbackTime <= aCurrentNow);
|
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
if (!aTimeout->mIsInterval) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2017-07-25 18:35:12 +03:00
|
|
|
// Automatically increase the nesting level when a setInterval()
|
|
|
|
// is rescheduled just as if it was using a chained setTimeout().
|
2017-07-25 18:35:12 +03:00
|
|
|
if (aTimeout->mNestingLevel < DOM_CLAMP_TIMEOUT_NESTING_LEVEL) {
|
|
|
|
aTimeout->mNestingLevel += 1;
|
|
|
|
}
|
2017-07-25 18:35:12 +03:00
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
// Compute time to next timeout for interval timer.
|
2017-06-16 03:30:47 +03:00
|
|
|
// Make sure nextInterval is at least CalculateDelay().
|
2017-06-16 03:30:48 +03:00
|
|
|
TimeDuration nextInterval = CalculateDelay(aTimeout);
|
2016-12-03 01:22:48 +03:00
|
|
|
|
2017-07-06 17:01:40 +03:00
|
|
|
TimeStamp firingTime = aLastCallbackTime + nextInterval;
|
|
|
|
TimeDuration delay = firingTime - aCurrentNow;
|
2016-12-03 01:22:48 +03:00
|
|
|
|
|
|
|
// And make sure delay is nonnegative; that might happen if the timer
|
|
|
|
// thread is firing our timers somewhat early or if they're taking a long
|
|
|
|
// time to run the callback.
|
|
|
|
if (delay < TimeDuration(0)) {
|
|
|
|
delay = TimeDuration(0);
|
|
|
|
}
|
|
|
|
|
2017-07-06 17:01:40 +03:00
|
|
|
aTimeout->SetWhenOrTimeRemaining(aCurrentNow, delay);
|
2017-01-10 19:08:18 +03:00
|
|
|
|
2017-06-01 03:13:19 +03:00
|
|
|
if (mWindow.IsSuspended()) {
|
2016-12-03 01:22:48 +03:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-07-06 17:01:40 +03:00
|
|
|
nsresult rv = MaybeSchedule(aTimeout->When(), aCurrentNow);
|
2017-06-01 03:13:19 +03:00
|
|
|
NS_ENSURE_SUCCESS(rv, false);
|
2016-12-03 01:22:48 +03:00
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
TimeoutManager::ClearAllTimeouts()
|
|
|
|
{
|
2016-12-14 02:14:02 +03:00
|
|
|
bool seenRunningTimeout = false;
|
2016-12-03 01:22:48 +03:00
|
|
|
|
2017-01-10 06:16:31 +03:00
|
|
|
MOZ_LOG(gLog, LogLevel::Debug,
|
|
|
|
("ClearAllTimeouts(TimeoutManager=%p)\n", this));
|
|
|
|
|
2017-06-14 18:47:38 +03:00
|
|
|
if (mThrottleTimeoutsTimer) {
|
|
|
|
mThrottleTimeoutsTimer->Cancel();
|
|
|
|
mThrottleTimeoutsTimer = nullptr;
|
2017-04-25 12:20:00 +03:00
|
|
|
}
|
|
|
|
|
2017-06-01 03:13:19 +03:00
|
|
|
mExecutor->Cancel();
|
|
|
|
|
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-16 00:17:38 +03:00
|
|
|
ForEachUnorderedTimeout([&](Timeout* aTimeout) {
|
2016-12-03 01:22:48 +03:00
|
|
|
/* If RunTimeout() is higher up on the stack for this
|
|
|
|
window, e.g. as a result of document.write from a timeout,
|
|
|
|
then we need to reset the list insertion point for
|
|
|
|
newly-created timeouts in case the user adds a timeout,
|
|
|
|
before we pop the stack back to RunTimeout. */
|
2016-12-14 02:14:02 +03:00
|
|
|
if (mRunningTimeout == aTimeout) {
|
|
|
|
seenRunningTimeout = true;
|
2016-12-13 18:23:03 +03:00
|
|
|
}
|
2016-12-03 01:22:48 +03:00
|
|
|
|
|
|
|
// Set timeout->mCleared to true to indicate that the timeout was
|
|
|
|
// cleared and taken out of the list of timeouts
|
2016-12-14 02:14:02 +03:00
|
|
|
aTimeout->mCleared = true;
|
|
|
|
});
|
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
// Clear out our list
|
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-16 00:17:38 +03:00
|
|
|
mNormalTimeouts.Clear();
|
|
|
|
mTrackingTimeouts.Clear();
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2016-12-14 03:06:21 +03:00
|
|
|
TimeoutManager::Timeouts::Insert(Timeout* aTimeout, SortBy aSortBy)
|
2016-12-03 01:22:48 +03:00
|
|
|
{
|
2017-06-01 03:13:18 +03:00
|
|
|
|
2017-06-05 22:42:33 +03:00
|
|
|
// Start at mLastTimeout and go backwards. Stop if we see a Timeout with a
|
|
|
|
// valid FiringId since those timers are currently being processed by
|
|
|
|
// RunTimeout. This optimizes for the common case of insertion at the end.
|
2016-12-03 01:22:48 +03:00
|
|
|
Timeout* prevSibling;
|
2016-12-14 03:06:21 +03:00
|
|
|
for (prevSibling = GetLast();
|
2017-06-05 22:42:33 +03:00
|
|
|
prevSibling &&
|
2016-12-03 01:22:48 +03:00
|
|
|
// This condition needs to match the one in SetTimeoutOrInterval that
|
2017-01-10 19:08:18 +03:00
|
|
|
// determines whether to set When() or TimeRemaining().
|
2016-12-14 03:06:21 +03:00
|
|
|
(aSortBy == SortBy::TimeRemaining ?
|
2017-01-10 19:08:18 +03:00
|
|
|
prevSibling->TimeRemaining() > aTimeout->TimeRemaining() :
|
2017-06-05 22:42:33 +03:00
|
|
|
prevSibling->When() > aTimeout->When()) &&
|
|
|
|
// Check the firing ID last since it will evaluate true in the vast
|
|
|
|
// majority of cases.
|
|
|
|
mManager.IsInvalidFiringId(prevSibling->mFiringId);
|
2016-12-03 01:22:48 +03:00
|
|
|
prevSibling = prevSibling->getPrevious()) {
|
|
|
|
/* Do nothing; just searching */
|
|
|
|
}
|
|
|
|
|
|
|
|
// Now link in aTimeout after prevSibling.
|
|
|
|
if (prevSibling) {
|
|
|
|
prevSibling->setNext(aTimeout);
|
|
|
|
} else {
|
2016-12-14 03:06:21 +03:00
|
|
|
InsertFront(aTimeout);
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
|
2017-05-19 23:45:55 +03:00
|
|
|
aTimeout->mFiringId = InvalidFiringId;
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
Timeout*
|
|
|
|
TimeoutManager::BeginRunningTimeout(Timeout* aTimeout)
|
|
|
|
{
|
|
|
|
Timeout* currentTimeout = mRunningTimeout;
|
|
|
|
mRunningTimeout = aTimeout;
|
|
|
|
++gRunningTimeoutDepth;
|
|
|
|
|
2017-05-30 14:08:11 +03:00
|
|
|
RecordExecution(currentTimeout, aTimeout);
|
2016-12-03 01:22:48 +03:00
|
|
|
return currentTimeout;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
TimeoutManager::EndRunningTimeout(Timeout* aTimeout)
|
|
|
|
{
|
|
|
|
--gRunningTimeoutDepth;
|
|
|
|
|
2017-05-30 14:08:11 +03:00
|
|
|
RecordExecution(mRunningTimeout, aTimeout);
|
2016-12-03 01:22:48 +03:00
|
|
|
mRunningTimeout = aTimeout;
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
TimeoutManager::UnmarkGrayTimers()
|
|
|
|
{
|
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-16 00:17:38 +03:00
|
|
|
ForEachUnorderedTimeout([](Timeout* aTimeout) {
|
2016-12-14 02:14:02 +03:00
|
|
|
if (aTimeout->mScriptHandler) {
|
|
|
|
aTimeout->mScriptHandler->MarkForCC();
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
2016-12-14 02:14:02 +03:00
|
|
|
});
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
TimeoutManager::Suspend()
|
|
|
|
{
|
2017-01-10 06:16:31 +03:00
|
|
|
MOZ_LOG(gLog, LogLevel::Debug,
|
|
|
|
("Suspend(TimeoutManager=%p)\n", this));
|
|
|
|
|
2017-06-14 18:47:38 +03:00
|
|
|
if (mThrottleTimeoutsTimer) {
|
|
|
|
mThrottleTimeoutsTimer->Cancel();
|
|
|
|
mThrottleTimeoutsTimer = nullptr;
|
2017-04-25 12:20:00 +03:00
|
|
|
}
|
|
|
|
|
2017-06-01 03:13:19 +03:00
|
|
|
mExecutor->Cancel();
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
TimeoutManager::Resume()
|
|
|
|
{
|
2017-01-10 06:16:31 +03:00
|
|
|
MOZ_LOG(gLog, LogLevel::Debug,
|
|
|
|
("Resume(TimeoutManager=%p)\n", this));
|
|
|
|
|
2017-04-25 12:20:00 +03:00
|
|
|
// When Suspend() has been called after IsDocumentLoaded(), but the
|
|
|
|
// throttle tracking timer never managed to fire, start the timer
|
|
|
|
// again.
|
2017-06-14 18:47:38 +03:00
|
|
|
if (mWindow.AsInner()->IsDocumentLoaded() && !mThrottleTimeouts) {
|
|
|
|
MaybeStartThrottleTimeout();
|
2017-04-25 12:20:00 +03:00
|
|
|
}
|
|
|
|
|
2017-06-16 03:30:47 +03:00
|
|
|
OrderedTimeoutIterator iter(mNormalTimeouts, mTrackingTimeouts);
|
|
|
|
Timeout* nextTimeout = iter.Next();
|
|
|
|
if (nextTimeout) {
|
2017-06-14 18:47:38 +03:00
|
|
|
MOZ_ALWAYS_SUCCEEDS(MaybeSchedule(nextTimeout->When()));
|
2017-06-01 03:13:19 +03:00
|
|
|
}
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
TimeoutManager::Freeze()
|
|
|
|
{
|
2017-01-10 06:16:31 +03:00
|
|
|
MOZ_LOG(gLog, LogLevel::Debug,
|
|
|
|
("Freeze(TimeoutManager=%p)\n", this));
|
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
TimeStamp now = TimeStamp::Now();
|
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-16 00:17:38 +03:00
|
|
|
ForEachUnorderedTimeout([&](Timeout* aTimeout) {
|
2016-12-03 01:22:48 +03:00
|
|
|
// Save the current remaining time for this timeout. We will
|
|
|
|
// re-apply it when the window is Thaw()'d. This effectively
|
|
|
|
// shifts timers to the right as if time does not pass while
|
|
|
|
// the window is frozen.
|
2017-01-10 19:08:18 +03:00
|
|
|
TimeDuration delta(0);
|
|
|
|
if (aTimeout->When() > now) {
|
|
|
|
delta = aTimeout->When() - now;
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
2017-01-10 19:08:18 +03:00
|
|
|
aTimeout->SetWhenOrTimeRemaining(now, delta);
|
|
|
|
MOZ_DIAGNOSTIC_ASSERT(aTimeout->TimeRemaining() == delta);
|
2016-12-14 02:14:02 +03:00
|
|
|
});
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
TimeoutManager::Thaw()
|
|
|
|
{
|
2017-01-10 06:16:31 +03:00
|
|
|
MOZ_LOG(gLog, LogLevel::Debug,
|
|
|
|
("Thaw(TimeoutManager=%p)\n", this));
|
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
TimeStamp now = TimeStamp::Now();
|
|
|
|
|
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-16 00:17:38 +03:00
|
|
|
ForEachUnorderedTimeout([&](Timeout* aTimeout) {
|
2017-01-10 19:08:18 +03:00
|
|
|
// Set When() back to the time when the timer is supposed to fire.
|
|
|
|
aTimeout->SetWhenOrTimeRemaining(now, aTimeout->TimeRemaining());
|
|
|
|
MOZ_DIAGNOSTIC_ASSERT(!aTimeout->When().IsNull());
|
2016-12-14 02:14:02 +03:00
|
|
|
});
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
2016-12-01 03:32:23 +03:00
|
|
|
|
2017-06-14 04:08:27 +03:00
|
|
|
void
|
|
|
|
TimeoutManager::UpdateBackgroundState()
|
|
|
|
{
|
2017-07-28 16:31:00 +03:00
|
|
|
mExecutionBudget = GetMaxBudget(mWindow.IsBackgroundInternal());
|
|
|
|
|
2017-06-14 04:08:27 +03:00
|
|
|
// When the window moves to the background or foreground we should
|
|
|
|
// reschedule the TimeoutExecutor in case the MinSchedulingDelay()
|
|
|
|
// changed. Only do this if the window is not suspended and we
|
|
|
|
// actually have a timeout.
|
|
|
|
if (!mWindow.IsSuspended()) {
|
|
|
|
OrderedTimeoutIterator iter(mNormalTimeouts, mTrackingTimeouts);
|
|
|
|
Timeout* nextTimeout = iter.Next();
|
|
|
|
if (nextTimeout) {
|
|
|
|
mExecutor->Cancel();
|
2017-06-14 18:47:38 +03:00
|
|
|
MOZ_ALWAYS_SUCCEEDS(MaybeSchedule(nextTimeout->When()));
|
2017-06-14 04:08:27 +03:00
|
|
|
}
|
|
|
|
}
|
2017-06-14 04:08:27 +03:00
|
|
|
}
|
|
|
|
|
2016-12-01 03:32:23 +03:00
|
|
|
bool
|
|
|
|
TimeoutManager::IsTimeoutTracking(uint32_t aTimeoutId)
|
|
|
|
{
|
|
|
|
return mTrackingTimeouts.ForEachAbortable([&](Timeout* aTimeout) {
|
|
|
|
return aTimeout->mTimeoutId == aTimeoutId;
|
|
|
|
});
|
|
|
|
}
|
2017-02-13 23:58:39 +03:00
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
2017-06-14 18:47:38 +03:00
|
|
|
class ThrottleTimeoutsCallback final : public nsITimerCallback
|
2017-07-26 21:18:20 +03:00
|
|
|
, public nsINamed
|
2017-02-13 23:58:39 +03:00
|
|
|
{
|
|
|
|
public:
|
2017-11-04 01:25:38 +03:00
|
|
|
explicit ThrottleTimeoutsCallback(nsGlobalWindowInner* aWindow)
|
2017-02-13 23:58:39 +03:00
|
|
|
: mWindow(aWindow)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
|
|
|
NS_DECL_ISUPPORTS
|
|
|
|
NS_DECL_NSITIMERCALLBACK
|
|
|
|
|
2017-07-26 21:18:20 +03:00
|
|
|
NS_IMETHOD GetName(nsACString& aName) override
|
|
|
|
{
|
|
|
|
aName.AssignLiteral("ThrottleTimeoutsCallback");
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2017-02-13 23:58:39 +03:00
|
|
|
private:
|
2017-06-14 18:47:38 +03:00
|
|
|
~ThrottleTimeoutsCallback() {}
|
2017-02-13 23:58:39 +03:00
|
|
|
|
|
|
|
private:
|
|
|
|
// The strong reference here keeps the Window and hence the TimeoutManager
|
|
|
|
// object itself alive.
|
2017-11-04 01:25:38 +03:00
|
|
|
RefPtr<nsGlobalWindowInner> mWindow;
|
2017-02-13 23:58:39 +03:00
|
|
|
};
|
|
|
|
|
2017-07-26 21:18:20 +03:00
|
|
|
NS_IMPL_ISUPPORTS(ThrottleTimeoutsCallback, nsITimerCallback, nsINamed)
|
2017-02-13 23:58:39 +03:00
|
|
|
|
|
|
|
NS_IMETHODIMP
|
2017-06-14 18:47:38 +03:00
|
|
|
ThrottleTimeoutsCallback::Notify(nsITimer* aTimer)
|
2017-02-13 23:58:39 +03:00
|
|
|
{
|
2017-06-14 18:47:38 +03:00
|
|
|
mWindow->AsInner()->TimeoutManager().StartThrottlingTimeouts();
|
2017-02-13 23:58:39 +03:00
|
|
|
mWindow = nullptr;
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
}
|
|
|
|
|
2017-07-20 18:06:20 +03:00
|
|
|
bool
|
2017-07-28 16:31:00 +03:00
|
|
|
TimeoutManager::BudgetThrottlingEnabled(bool aIsBackground) const
|
2017-07-20 18:06:20 +03:00
|
|
|
{
|
|
|
|
// A window can be throttled using budget if
|
|
|
|
// * It isn't active
|
|
|
|
// * If it isn't using WebRTC
|
|
|
|
// * If it hasn't got open WebSockets
|
|
|
|
// * If it hasn't got active IndexedDB databases
|
2017-07-28 16:31:00 +03:00
|
|
|
|
2017-07-20 18:06:20 +03:00
|
|
|
// Note that we allow both foreground and background to be
|
|
|
|
// considered for budget throttling. What determines if they are if
|
2017-07-28 16:31:00 +03:00
|
|
|
// budget throttling is enabled is the max budget.
|
|
|
|
if ((aIsBackground ? gBackgroundThrottlingMaxBudget
|
|
|
|
: gForegroundThrottlingMaxBudget) < 0) {
|
|
|
|
return false;
|
|
|
|
}
|
2017-07-20 18:06:20 +03:00
|
|
|
|
|
|
|
if (!mBudgetThrottleTimeouts || IsActive()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check if there are any active IndexedDB databases
|
|
|
|
if (mWindow.AsInner()->HasActiveIndexedDBDatabases()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2017-08-04 13:28:15 +03:00
|
|
|
// Check if we have active PeerConnection
|
|
|
|
if (mWindow.AsInner()->HasActivePeerConnections()) {
|
2017-07-20 18:06:20 +03:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2017-08-23 13:12:44 +03:00
|
|
|
if (mWindow.AsInner()->HasOpenWebSockets()) {
|
2017-07-20 18:06:20 +03:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-02-13 23:58:39 +03:00
|
|
|
void
|
2017-06-14 18:47:38 +03:00
|
|
|
TimeoutManager::StartThrottlingTimeouts()
|
2017-02-13 23:58:39 +03:00
|
|
|
{
|
|
|
|
MOZ_ASSERT(NS_IsMainThread());
|
2017-06-14 18:47:38 +03:00
|
|
|
MOZ_DIAGNOSTIC_ASSERT(mThrottleTimeoutsTimer);
|
2017-02-13 23:58:39 +03:00
|
|
|
|
|
|
|
MOZ_LOG(gLog, LogLevel::Debug,
|
|
|
|
("TimeoutManager %p started to throttle tracking timeouts\n", this));
|
|
|
|
|
2017-06-14 18:47:38 +03:00
|
|
|
MOZ_DIAGNOSTIC_ASSERT(!mThrottleTimeouts);
|
|
|
|
mThrottleTimeouts = true;
|
2017-02-13 23:58:39 +03:00
|
|
|
mThrottleTrackingTimeouts = true;
|
2017-06-14 18:47:38 +03:00
|
|
|
mBudgetThrottleTimeouts = gEnableBudgetTimeoutThrottling;
|
|
|
|
mThrottleTimeoutsTimer = nullptr;
|
2017-02-13 23:58:39 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
TimeoutManager::OnDocumentLoaded()
|
2017-04-25 12:20:00 +03:00
|
|
|
{
|
2017-05-26 07:40:12 +03:00
|
|
|
// The load event may be firing again if we're coming back to the page by
|
|
|
|
// navigating through the session history, so we need to ensure to only call
|
2017-06-14 18:47:38 +03:00
|
|
|
// this when mThrottleTimeouts hasn't been set yet.
|
|
|
|
if (!mThrottleTimeouts) {
|
|
|
|
MaybeStartThrottleTimeout();
|
2017-05-26 07:40:12 +03:00
|
|
|
}
|
2017-04-25 12:20:00 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
2017-06-14 18:47:38 +03:00
|
|
|
TimeoutManager::MaybeStartThrottleTimeout()
|
2017-02-13 23:58:39 +03:00
|
|
|
{
|
2017-06-14 18:47:38 +03:00
|
|
|
if (gTimeoutThrottlingDelay <= 0 ||
|
2017-05-23 16:36:08 +03:00
|
|
|
mWindow.AsInner()->InnerObjectsFreed() || mWindow.IsSuspended()) {
|
2017-02-13 23:58:39 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2017-06-14 18:47:38 +03:00
|
|
|
MOZ_DIAGNOSTIC_ASSERT(!mThrottleTimeouts);
|
2017-02-13 23:58:39 +03:00
|
|
|
|
|
|
|
MOZ_LOG(gLog, LogLevel::Debug,
|
|
|
|
("TimeoutManager %p delaying tracking timeout throttling by %dms\n",
|
2017-06-14 18:47:38 +03:00
|
|
|
this, gTimeoutThrottlingDelay));
|
2017-02-13 23:58:39 +03:00
|
|
|
|
|
|
|
nsCOMPtr<nsITimerCallback> callback =
|
2017-06-14 18:47:38 +03:00
|
|
|
new ThrottleTimeoutsCallback(&mWindow);
|
2017-02-13 23:58:39 +03:00
|
|
|
|
2017-10-16 09:15:40 +03:00
|
|
|
NS_NewTimerWithCallback(getter_AddRefs(mThrottleTimeoutsTimer),
|
|
|
|
callback, gTimeoutThrottlingDelay, nsITimer::TYPE_ONE_SHOT,
|
|
|
|
EventTarget());
|
2017-02-13 23:58:39 +03:00
|
|
|
}
|
2017-05-02 14:23:00 +03:00
|
|
|
|
|
|
|
void
|
|
|
|
TimeoutManager::BeginSyncOperation()
|
|
|
|
{
|
|
|
|
// If we're beginning a sync operation, the currently running
|
|
|
|
// timeout will be put on hold. To not get into an inconsistent
|
|
|
|
// state, where the currently running timeout appears to take time
|
|
|
|
// equivalent to the period of us spinning up a new event loop,
|
|
|
|
// record what we have and stop recording until we reach
|
|
|
|
// EndSyncOperation.
|
2017-05-30 14:08:11 +03:00
|
|
|
RecordExecution(mRunningTimeout, nullptr);
|
2017-05-02 14:23:00 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
TimeoutManager::EndSyncOperation()
|
|
|
|
{
|
|
|
|
// If we're running a timeout, restart the measurement from here.
|
2017-05-30 14:08:11 +03:00
|
|
|
RecordExecution(nullptr, mRunningTimeout);
|
2017-05-02 14:23:00 +03:00
|
|
|
}
|
2017-06-01 03:13:19 +03:00
|
|
|
|
|
|
|
nsIEventTarget*
|
|
|
|
TimeoutManager::EventTarget()
|
|
|
|
{
|
|
|
|
return mWindow.EventTargetFor(TaskCategory::Timer);
|
|
|
|
}
|