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"
|
|
|
|
#include "nsGlobalWindow.h"
|
2017-01-10 06:16:31 +03:00
|
|
|
#include "mozilla/Logging.h"
|
2018-08-13 18:09:56 +03:00
|
|
|
#include "mozilla/PerformanceCounter.h"
|
2021-03-22 19:29:52 +03:00
|
|
|
#include "mozilla/ProfilerMarkers.h"
|
2020-12-07 17:21:28 +03:00
|
|
|
#include "mozilla/ScopeExit.h"
|
2019-07-26 22:15:44 +03:00
|
|
|
#include "mozilla/StaticPrefs_dom.h"
|
2019-07-26 04:10:23 +03:00
|
|
|
#include "mozilla/StaticPrefs_privacy.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-26 21:18:20 +03:00
|
|
|
#include "nsINamed.h"
|
2018-08-13 18:09:56 +03:00
|
|
|
#include "mozilla/dom/DocGroup.h"
|
2020-11-23 19:21:38 +03:00
|
|
|
#include "mozilla/dom/Document.h"
|
2018-12-16 12:21:16 +03:00
|
|
|
#include "mozilla/dom/PopupBlocker.h"
|
2020-06-26 22:08:53 +03:00
|
|
|
#include "mozilla/dom/ContentChild.h"
|
2019-06-15 00:04:19 +03:00
|
|
|
#include "mozilla/dom/TimeoutHandler.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;
|
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
LazyLogModule gTimeoutLog("Timeout");
|
2017-01-10 06:16:31 +03:00
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
static int32_t gRunningTimeoutDepth = 0;
|
|
|
|
|
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.
|
2019-07-26 06:07:42 +03:00
|
|
|
double denominator = std::max(
|
|
|
|
aIsBackground
|
|
|
|
? StaticPrefs::dom_timeout_background_budget_regeneration_rate()
|
2019-07-26 23:32:25 +03:00
|
|
|
: StaticPrefs::dom_timeout_foreground_budget_regeneration_rate(),
|
2019-07-26 06:07:42 +03:00
|
|
|
1);
|
2017-06-14 18:47:38 +03:00
|
|
|
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.
|
2019-07-26 23:06:08 +03:00
|
|
|
int32_t maxBudget =
|
|
|
|
aIsBackground
|
|
|
|
? StaticPrefs::dom_timeout_background_throttling_max_budget()
|
2019-07-26 23:09:34 +03:00
|
|
|
: StaticPrefs::dom_timeout_foreground_throttling_max_budget();
|
2017-06-14 18:47:38 +03:00
|
|
|
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(
|
2019-07-27 00:11:41 +03:00
|
|
|
-StaticPrefs::dom_timeout_budget_throttling_max_delay() /
|
2019-07-26 06:07:42 +03:00
|
|
|
std::max(
|
|
|
|
aIsBackground
|
|
|
|
? StaticPrefs::dom_timeout_background_budget_regeneration_rate()
|
2019-07-26 23:32:25 +03:00
|
|
|
: StaticPrefs::dom_timeout_foreground_budget_regeneration_rate(),
|
2019-07-26 06:07:42 +03:00
|
|
|
1));
|
2017-08-18 15:16:47 +03:00
|
|
|
}
|
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
|
2019-04-11 17:12:43 +03:00
|
|
|
if (mWindow.IsPlayingAudio()) {
|
2017-06-14 18:47:38 +03:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
return false;
|
2017-05-02 14:23:00 +03:00
|
|
|
}
|
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
void TimeoutManager::SetLoading(bool value) {
|
|
|
|
// When moving from loading to non-loading, we may need to
|
|
|
|
// reschedule any existing timeouts from the idle timeout queue
|
|
|
|
// to the normal queue.
|
|
|
|
MOZ_LOG(gTimeoutLog, LogLevel::Debug, ("%p: SetLoading(%d)", this, value));
|
|
|
|
if (mIsLoading && !value) {
|
|
|
|
MoveIdleToActive();
|
|
|
|
}
|
|
|
|
// We don't immediately move existing timeouts to the idle queue if we
|
|
|
|
// move to loading. When they would have fired, we'll see we're loading
|
|
|
|
// and move them then.
|
|
|
|
mIsLoading = value;
|
|
|
|
}
|
|
|
|
|
|
|
|
void TimeoutManager::MoveIdleToActive() {
|
|
|
|
uint32_t num = 0;
|
|
|
|
TimeStamp when;
|
|
|
|
TimeStamp now;
|
|
|
|
// Ensure we maintain the ordering of timeouts, so timeouts
|
|
|
|
// never fire before a timeout set for an earlier time, or
|
|
|
|
// before a timeout for the same time already submitted.
|
|
|
|
// See https://html.spec.whatwg.org/#dom-settimeout #16 and #17
|
|
|
|
while (RefPtr<Timeout> timeout = mIdleTimeouts.GetLast()) {
|
|
|
|
if (num == 0) {
|
|
|
|
when = timeout->When();
|
|
|
|
}
|
|
|
|
timeout->remove();
|
|
|
|
mTimeouts.InsertFront(timeout);
|
2019-09-18 04:22:12 +03:00
|
|
|
if (profiler_can_accept_markers()) {
|
2019-01-26 20:18:06 +03:00
|
|
|
if (num == 0) {
|
|
|
|
now = TimeStamp::Now();
|
|
|
|
}
|
|
|
|
TimeDuration elapsed = now - timeout->SubmitTime();
|
|
|
|
TimeDuration target = timeout->When() - timeout->SubmitTime();
|
|
|
|
TimeDuration delta = now - timeout->When();
|
|
|
|
nsPrintfCString marker(
|
|
|
|
"Releasing deferred setTimeout() for %dms (original target time was "
|
|
|
|
"%dms (%dms delta))",
|
|
|
|
int(elapsed.ToMilliseconds()), int(target.ToMilliseconds()),
|
|
|
|
int(delta.ToMilliseconds()));
|
|
|
|
// don't have end before start...
|
2020-11-19 00:54:13 +03:00
|
|
|
PROFILER_MARKER_TEXT(
|
|
|
|
"setTimeout deferred release", DOM,
|
|
|
|
MarkerOptions(
|
|
|
|
MarkerTiming::Interval(
|
|
|
|
delta.ToMilliseconds() >= 0 ? timeout->When() : now, now),
|
|
|
|
MarkerInnerWindowId(mWindow.WindowID())),
|
|
|
|
marker);
|
2019-01-26 20:18:06 +03:00
|
|
|
}
|
|
|
|
num++;
|
|
|
|
}
|
|
|
|
if (num > 0) {
|
|
|
|
MOZ_ALWAYS_SUCCEEDS(MaybeSchedule(when));
|
|
|
|
mIdleExecutor->Cancel();
|
|
|
|
}
|
|
|
|
MOZ_LOG(gTimeoutLog, LogLevel::Debug,
|
|
|
|
("%p: Moved %d timeouts from Idle to active", this, num));
|
|
|
|
}
|
|
|
|
|
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
|
2019-07-27 00:11:41 +03:00
|
|
|
// "dom.timeout.budget_throttling_max_delay" to not entirely starve
|
|
|
|
// the timeouts.
|
2017-06-14 18:47:38 +03:00
|
|
|
//
|
|
|
|
// 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 =
|
2019-07-26 22:21:47 +03:00
|
|
|
isBackground ? TimeDuration::FromMilliseconds(
|
|
|
|
StaticPrefs::dom_min_background_timeout_value())
|
2017-06-14 18:47:38 +03:00
|
|
|
: TimeDuration();
|
2020-09-07 16:23:34 +03:00
|
|
|
bool budgetThrottlingEnabled = BudgetThrottlingEnabled(isBackground);
|
|
|
|
if (budgetThrottlingEnabled && 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
|
|
|
}
|
2020-09-07 16:23:34 +03:00
|
|
|
if (!budgetThrottlingEnabled && isBackground) {
|
2020-08-27 17:58:21 +03:00
|
|
|
return TimeDuration::FromMilliseconds(
|
2020-09-07 16:23:34 +03:00
|
|
|
StaticPrefs::
|
|
|
|
dom_min_background_timeout_value_without_budget_throttling());
|
2020-08-27 17:58:21 +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 || mFiringIdStack.IsEmpty()) {
|
|
|
|
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.
|
2020-01-20 19:17:06 +03:00
|
|
|
std::swap(low, high);
|
2017-05-19 23:45:55 +03:00
|
|
|
}
|
|
|
|
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);
|
|
|
|
}
|
|
|
|
|
2020-07-24 18:29:07 +03:00
|
|
|
// The number of nested timeouts before we start clamping. HTML says 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:47 +03:00
|
|
|
TimeDuration 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) {
|
2019-07-26 22:15:44 +03:00
|
|
|
uint32_t minTimeoutValue = StaticPrefs::dom_min_timeout_value();
|
|
|
|
result = TimeDuration::Max(result,
|
|
|
|
TimeDuration::FromMilliseconds(minTimeoutValue));
|
2017-06-16 03:30:47 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
return result;
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
|
2018-08-13 18:09:56 +03:00
|
|
|
PerformanceCounter* TimeoutManager::GetPerformanceCounter() {
|
2019-01-02 16:05:23 +03:00
|
|
|
Document* doc = mWindow.GetDocument();
|
2018-08-13 18:09:56 +03:00
|
|
|
if (doc) {
|
|
|
|
dom::DocGroup* docGroup = doc->GetDocGroup();
|
|
|
|
if (docGroup) {
|
|
|
|
return docGroup->GetPerformanceCounter();
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
2017-05-30 14:08:11 +03:00
|
|
|
void TimeoutManager::RecordExecution(Timeout* aRunningTimeout,
|
|
|
|
Timeout* aTimeout) {
|
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.
|
2018-10-12 21:01:19 +03:00
|
|
|
TimeDuration duration = budgetManager.RecordExecution(now, aRunningTimeout);
|
2017-06-14 18:47:38 +03:00
|
|
|
|
|
|
|
UpdateBudget(now, duration);
|
2018-08-13 18:09:56 +03:00
|
|
|
|
|
|
|
// This is an ad-hoc way to use the counters for the timers
|
|
|
|
// that should be removed at somepoint. See Bug 1482834
|
|
|
|
PerformanceCounter* counter = GetPerformanceCounter();
|
|
|
|
if (counter) {
|
|
|
|
counter->IncrementExecutionDuration(duration.ToMicroseconds());
|
|
|
|
}
|
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);
|
2018-08-13 18:09:56 +03:00
|
|
|
PerformanceCounter* counter = GetPerformanceCounter();
|
|
|
|
if (counter) {
|
|
|
|
counter->IncrementDispatchCounter(DispatchCategory(TaskCategory::Timer));
|
|
|
|
}
|
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-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;
|
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
TimeoutManager::TimeoutManager(nsGlobalWindowInner& aWindow,
|
|
|
|
uint32_t aMaxIdleDeferMS)
|
2016-12-03 01:22:48 +03:00
|
|
|
: mWindow(aWindow),
|
2019-01-26 20:18:06 +03:00
|
|
|
mExecutor(new TimeoutExecutor(this, false, 0)),
|
|
|
|
mIdleExecutor(new TimeoutExecutor(this, true, aMaxIdleDeferMS)),
|
2018-10-12 21:01:19 +03:00
|
|
|
mTimeouts(*this),
|
2016-12-03 01:22:48 +03:00
|
|
|
mTimeoutIdCounter(1),
|
2017-05-19 23:45:55 +03:00
|
|
|
mNextFiringId(InvalidFiringId + 1),
|
2019-02-26 07:52:11 +03:00
|
|
|
#ifdef DEBUG
|
2019-02-06 02:00:24 +03:00
|
|
|
mFiringIndex(0),
|
|
|
|
mLastFiringIndex(-1),
|
|
|
|
#endif
|
2016-12-03 01:22:48 +03:00
|
|
|
mRunningTimeout(nullptr),
|
2019-01-26 20:18:06 +03:00
|
|
|
mIdleTimeouts(*this),
|
2016-12-03 01:22:48 +03:00
|
|
|
mIdleCallbackTimeoutCounter(1),
|
2017-06-14 18:47:38 +03:00
|
|
|
mLastBudgetUpdate(TimeStamp::Now()),
|
|
|
|
mExecutionBudget(GetMaxBudget(mWindow.IsBackgroundInternal())),
|
|
|
|
mThrottleTimeouts(false),
|
|
|
|
mThrottleTrackingTimeouts(false),
|
2019-01-26 20:18:06 +03:00
|
|
|
mBudgetThrottleTimeouts(false),
|
|
|
|
mIsLoading(false) {
|
|
|
|
MOZ_LOG(gTimeoutLog, LogLevel::Debug,
|
2017-01-10 06:16:31 +03:00
|
|
|
("TimeoutManager %p created, tracking bucketing %s\n", this,
|
2018-12-14 14:40:16 +03:00
|
|
|
StaticPrefs::privacy_trackingprotection_annotate_channels()
|
|
|
|
? "enabled"
|
|
|
|
: "disabled"));
|
2017-01-10 06:16:31 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
TimeoutManager::~TimeoutManager() {
|
2018-04-04 03:10:16 +03:00
|
|
|
MOZ_DIAGNOSTIC_ASSERT(mWindow.IsDying());
|
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();
|
2019-01-26 20:18:06 +03:00
|
|
|
mIdleExecutor->Shutdown();
|
2017-06-01 03:13:19 +03:00
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
MOZ_LOG(gTimeoutLog, LogLevel::Debug,
|
|
|
|
("TimeoutManager %p destroyed\n", this));
|
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; }
|
|
|
|
|
2019-06-15 00:04:19 +03:00
|
|
|
nsresult TimeoutManager::SetTimeout(TimeoutHandler* aHandler, int32_t interval,
|
|
|
|
bool aIsInterval, Timeout::Reason aReason,
|
|
|
|
int32_t* aReturn) {
|
2016-12-03 01:22:48 +03:00
|
|
|
// If we don't have a document (we could have been unloaded since
|
|
|
|
// the call to setTimeout was made), do nothing.
|
2019-01-02 16:05:23 +03:00
|
|
|
nsCOMPtr<Document> doc = mWindow.GetExtantDoc();
|
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 (!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();
|
2019-02-26 07:52:11 +03:00
|
|
|
#ifdef DEBUG
|
2019-02-16 08:31:37 +03:00
|
|
|
timeout->mFiringIndex = -1;
|
|
|
|
#endif
|
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
|
2018-12-16 12:21:16 +03:00
|
|
|
timeout->mPopupState = PopupBlocker::openAbused;
|
2017-06-16 03:30:47 +03:00
|
|
|
|
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 &&
|
2018-12-16 12:21:16 +03:00
|
|
|
PopupBlocker::GetPopupControlState() < PopupBlocker::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.
|
2019-07-26 22:28:30 +03:00
|
|
|
if (interval <= StaticPrefs::dom_disable_open_click_delay()) {
|
2018-12-16 12:21:16 +03:00
|
|
|
timeout->mPopupState = PopupBlocker::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);
|
2020-05-20 17:08:59 +03:00
|
|
|
|
2020-05-21 13:06:15 +03:00
|
|
|
timeout->mTimeoutId = GetTimeoutId(aReason);
|
2020-05-24 23:59:08 +03:00
|
|
|
mTimeouts.Insert(timeout, sort);
|
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
*aReturn = timeout->mTimeoutId;
|
|
|
|
|
2017-06-14 18:47:38 +03:00
|
|
|
MOZ_LOG(
|
2019-01-26 20:18:06 +03:00
|
|
|
gTimeoutLog, 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) "
|
2018-10-12 21:01:19 +03:00
|
|
|
"returned 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(), timeout->mTimeoutId,
|
|
|
|
int(mExecutionBudget.ToMilliseconds())));
|
2017-01-10 06:16:31 +03:00
|
|
|
|
2016-12-03 01:22:48 +03:00
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
// Make sure we clear it no matter which list it's in
|
2016-12-03 01:22:48 +03:00
|
|
|
void TimeoutManager::ClearTimeout(int32_t aTimerId, Timeout::Reason aReason) {
|
2019-01-26 20:18:06 +03:00
|
|
|
if (ClearTimeoutInternal(aTimerId, aReason, false) ||
|
|
|
|
mIdleTimeouts.IsEmpty()) {
|
|
|
|
return; // no need to check the other list if we cleared the timeout
|
|
|
|
}
|
|
|
|
ClearTimeoutInternal(aTimerId, aReason, true);
|
|
|
|
}
|
2016-12-03 01:22:48 +03:00
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
bool TimeoutManager::ClearTimeoutInternal(int32_t aTimerId,
|
|
|
|
Timeout::Reason aReason,
|
|
|
|
bool aIsIdle) {
|
|
|
|
uint32_t timerId = (uint32_t)aTimerId;
|
|
|
|
Timeouts& timeouts = aIsIdle ? mIdleTimeouts : mTimeouts;
|
|
|
|
RefPtr<TimeoutExecutor>& executor = aIsIdle ? mIdleExecutor : mExecutor;
|
2017-06-09 05:13:36 +03:00
|
|
|
bool deferredDeletion = false;
|
2020-05-20 17:08:59 +03:00
|
|
|
|
2020-05-24 23:59:08 +03:00
|
|
|
Timeout* timeout = timeouts.GetTimeout(timerId, aReason);
|
|
|
|
if (!timeout) {
|
2020-05-21 13:06:15 +03:00
|
|
|
return false;
|
2020-05-24 23:59:08 +03:00
|
|
|
}
|
|
|
|
bool firstTimeout = timeout == timeouts.GetFirst();
|
|
|
|
|
|
|
|
MOZ_LOG(gTimeoutLog, LogLevel::Debug,
|
|
|
|
("%s(TimeoutManager=%p, timeout=%p, ID=%u)\n",
|
|
|
|
timeout->mReason == Timeout::Reason::eIdleCallbackTimeout
|
|
|
|
? "CancelIdleCallback"
|
2020-11-18 12:05:59 +03:00
|
|
|
: timeout->mIsInterval ? "ClearInterval"
|
|
|
|
: "ClearTimeout",
|
2020-05-24 23:59:08 +03:00
|
|
|
this, timeout, timeout->mTimeoutId));
|
|
|
|
|
|
|
|
if (timeout->mRunning) {
|
|
|
|
/* We're running from inside the timeout. Mark this
|
|
|
|
timeout for deferred deletion by the code in
|
|
|
|
RunTimeout() */
|
|
|
|
timeout->mIsInterval = false;
|
|
|
|
deferredDeletion = true;
|
|
|
|
} else {
|
|
|
|
/* Delete the aTimeout from the pending aTimeout list */
|
|
|
|
timeout->remove();
|
|
|
|
}
|
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()) {
|
2020-05-24 23:59:08 +03:00
|
|
|
return true;
|
2017-06-01 03:13:19 +03:00
|
|
|
}
|
|
|
|
|
2017-06-09 05:13:36 +03:00
|
|
|
// Stop the executor and restart it at the next soonest deadline.
|
2019-01-26 20:18:06 +03:00
|
|
|
executor->Cancel();
|
2017-06-01 03:13:19 +03:00
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
Timeout* nextTimeout = timeouts.GetFirst();
|
2017-06-01 03:13:19 +03:00
|
|
|
if (nextTimeout) {
|
2019-01-26 20:18:06 +03:00
|
|
|
if (aIsIdle) {
|
|
|
|
MOZ_ALWAYS_SUCCEEDS(
|
|
|
|
executor->MaybeSchedule(nextTimeout->When(), TimeDuration(0)));
|
|
|
|
} else {
|
|
|
|
MOZ_ALWAYS_SUCCEEDS(MaybeSchedule(nextTimeout->When()));
|
|
|
|
}
|
2017-06-01 03:13:19 +03:00
|
|
|
}
|
2020-05-24 23:59:08 +03:00
|
|
|
return true;
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
|
2017-06-01 03:13:19 +03:00
|
|
|
void TimeoutManager::RunTimeout(const TimeStamp& aNow,
|
2019-01-26 20:18:06 +03:00
|
|
|
const TimeStamp& aTargetDeadline,
|
|
|
|
bool aProcessIdle) {
|
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;
|
|
|
|
}
|
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
Timeouts& timeouts(aProcessIdle ? mIdleTimeouts : mTimeouts);
|
|
|
|
|
2017-05-19 23:45:55 +03:00
|
|
|
// Limit the overall time spent in RunTimeout() to reduce jank.
|
|
|
|
uint32_t totalTimeLimitMS =
|
2019-07-26 06:07:41 +03:00
|
|
|
std::max(1u, StaticPrefs::dom_timeout_max_consecutive_callbacks_ms());
|
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
|
2019-03-19 23:52:03 +03:00
|
|
|
RefPtr<nsGlobalWindowInner> window(&mWindow);
|
|
|
|
// Accessing members of mWindow here is safe, because the lifetime of
|
|
|
|
// TimeoutManager is the same as the lifetime of the containing
|
|
|
|
// nsGlobalWindow.
|
2016-12-03 01:22:48 +03:00
|
|
|
|
|
|
|
// 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.
|
2019-02-06 02:00:24 +03:00
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
for (Timeout* timeout = timeouts.GetFirst(); timeout != nullptr;
|
2018-10-12 21:01:19 +03:00
|
|
|
timeout = timeout->getNext()) {
|
|
|
|
if (totalTimeLimit.IsZero() || timeout->When() > deadline) {
|
|
|
|
nextDeadline = timeout->When();
|
|
|
|
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
|
|
|
|
2018-10-12 21:01:19 +03:00
|
|
|
if (IsInvalidFiringId(timeout->mFiringId)) {
|
|
|
|
// Mark any timeouts that are on the list to be fired with the
|
|
|
|
// firing depth so that we can reentrantly run timeouts
|
|
|
|
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
|
|
|
|
2018-10-12 21:01:19 +03:00
|
|
|
numTimersToRun += 1;
|
2017-03-02 19:33:11 +03:00
|
|
|
|
2018-10-12 21:01:19 +03:00
|
|
|
// Run only a limited number of timers based on the configured maximum.
|
|
|
|
if (numTimersToRun % kNumTimersPerInitialElapsedCheck == 0) {
|
|
|
|
now = TimeStamp::Now();
|
|
|
|
TimeDuration elapsed(now - start);
|
|
|
|
if (elapsed >= initialTimeLimit) {
|
|
|
|
nextDeadline = timeout->When();
|
|
|
|
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
|
|
|
}
|
|
|
|
}
|
2019-01-26 20:18:06 +03:00
|
|
|
if (aProcessIdle) {
|
|
|
|
MOZ_LOG(
|
|
|
|
gTimeoutLog, LogLevel::Debug,
|
|
|
|
("Running %u deferred timeouts on idle (TimeoutManager=%p), "
|
|
|
|
"nextDeadline = %gms from now",
|
2019-02-16 01:43:24 +03:00
|
|
|
numTimersToRun, this,
|
|
|
|
nextDeadline.IsNull() ? 0.0 : (nextDeadline - now).ToMilliseconds()));
|
2019-01-26 20:18:06 +03:00
|
|
|
}
|
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());
|
2019-01-26 20:18:06 +03:00
|
|
|
if (aProcessIdle) {
|
|
|
|
// We don't want to update timing budget for idle queue firings, and
|
|
|
|
// all timeouts in the IdleTimeouts list have hit their deadlines,
|
|
|
|
// and so should run as soon as possible.
|
|
|
|
MOZ_ALWAYS_SUCCEEDS(
|
|
|
|
mIdleExecutor->MaybeSchedule(nextDeadline, TimeDuration()));
|
|
|
|
} else {
|
|
|
|
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
|
|
|
{
|
2018-10-12 21:01:19 +03:00
|
|
|
// Use a nested scope in order to make sure the strong references held while
|
|
|
|
// iterating are freed after the loop.
|
|
|
|
|
|
|
|
// The next timeout to run. This is used to advance the loop, but
|
|
|
|
// we cannot set it until we've run the current timeout, since
|
|
|
|
// running the current timeout might remove the immediate next
|
|
|
|
// timeout.
|
|
|
|
RefPtr<Timeout> next;
|
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
for (RefPtr<Timeout> timeout = timeouts.GetFirst(); timeout != nullptr;
|
2018-10-12 21:01:19 +03:00
|
|
|
timeout = next) {
|
2018-11-08 20:10:59 +03:00
|
|
|
next = timeout->getNext();
|
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
|
2019-02-19 16:48:05 +03:00
|
|
|
// a Timeout for another RunTimeout() on the call stack (such as in
|
|
|
|
// the case of nested event loops, for alert() or more likely XHR).
|
|
|
|
// Just skip it.
|
2017-06-08 15:51:58 +03:00
|
|
|
if (IsValidFiringId(timeout->mFiringId)) {
|
2019-01-26 20:18:06 +03:00
|
|
|
MOZ_LOG(gTimeoutLog, LogLevel::Debug,
|
|
|
|
("Skipping Run%s(TimeoutManager=%p, timeout=%p) since "
|
2019-02-23 01:22:50 +03:00
|
|
|
"firingId %d is valid (processing firingId %d)"
|
2019-02-26 07:52:11 +03:00
|
|
|
#ifdef DEBUG
|
2019-02-23 01:22:50 +03:00
|
|
|
" - FiringIndex %" PRId64 " (mLastFiringIndex %" PRId64 ")"
|
|
|
|
#endif
|
|
|
|
,
|
2019-01-26 20:18:06 +03:00
|
|
|
timeout->mIsInterval ? "Interval" : "Timeout", this,
|
2019-02-23 01:22:50 +03:00
|
|
|
timeout.get(), timeout->mFiringId, firingId
|
2019-02-26 07:52:11 +03:00
|
|
|
#ifdef DEBUG
|
2019-02-23 01:22:50 +03:00
|
|
|
,
|
|
|
|
timeout->mFiringIndex, mFiringIndex
|
|
|
|
#endif
|
|
|
|
));
|
2019-02-26 07:52:11 +03:00
|
|
|
#ifdef DEBUG
|
2019-02-19 16:48:05 +03:00
|
|
|
// The old FiringIndex assumed no recursion; recursion can cause
|
|
|
|
// other timers to get fired "in the middle" of a sequence we've
|
|
|
|
// already assigned firingindexes to. Since we're not going to
|
|
|
|
// run this timeout now, remove any FiringIndex that was already
|
|
|
|
// set.
|
|
|
|
|
|
|
|
// Since all timers that have FiringIndexes set *must* be ready
|
|
|
|
// to run and have valid FiringIds, all of them will be 'skipped'
|
|
|
|
// and reset if we recurse - we don't have to look through the
|
|
|
|
// list past where we'll stop on the first InvalidFiringId.
|
|
|
|
timeout->mFiringIndex = -1;
|
|
|
|
#endif
|
2017-06-08 15:51:58 +03:00
|
|
|
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
|
|
|
|
2019-02-06 02:00:24 +03:00
|
|
|
// Record the first time we try to fire a timeout, and ensure that
|
|
|
|
// all actual firings occur in that order. This ensures that we
|
|
|
|
// retain compliance with the spec language
|
|
|
|
// (https://html.spec.whatwg.org/#dom-settimeout) specifically items
|
|
|
|
// 15 ("If method context is a Window object, wait until the Document
|
|
|
|
// associated with method context has been fully active for a further
|
|
|
|
// timeout milliseconds (not necessarily consecutively)") and item 16
|
|
|
|
// ("Wait until any invocations of this algorithm that had the same
|
|
|
|
// method context, that started before this one, and whose timeout is
|
|
|
|
// equal to or less than this one's, have completed.").
|
2019-02-26 07:52:11 +03:00
|
|
|
#ifdef DEBUG
|
2019-02-06 02:00:24 +03:00
|
|
|
if (timeout->mFiringIndex == -1) {
|
|
|
|
timeout->mFiringIndex = mFiringIndex++;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
if (mIsLoading && !aProcessIdle) {
|
|
|
|
// Any timeouts that would fire during a load will be deferred
|
|
|
|
// until the load event occurs, but if there's an idle time,
|
|
|
|
// they'll be run before the load event.
|
2017-05-19 23:45:55 +03:00
|
|
|
timeout->remove();
|
2019-01-26 20:18:06 +03:00
|
|
|
// MOZ_RELEASE_ASSERT(timeout->When() <= (TimeStamp::Now()));
|
|
|
|
mIdleTimeouts.InsertBack(timeout);
|
|
|
|
if (MOZ_LOG_TEST(gTimeoutLog, LogLevel::Debug)) {
|
|
|
|
uint32_t num = 0;
|
|
|
|
for (Timeout* t = mIdleTimeouts.GetFirst(); t != nullptr;
|
|
|
|
t = t->getNext()) {
|
|
|
|
num++;
|
|
|
|
}
|
|
|
|
MOZ_LOG(
|
|
|
|
gTimeoutLog, LogLevel::Debug,
|
|
|
|
("Deferring Run%s(TimeoutManager=%p, timeout=%p (%gms in the "
|
|
|
|
"past)) (%u deferred)",
|
|
|
|
timeout->mIsInterval ? "Interval" : "Timeout", this,
|
|
|
|
timeout.get(), (now - timeout->When()).ToMilliseconds(), num));
|
|
|
|
}
|
|
|
|
MOZ_ALWAYS_SUCCEEDS(mIdleExecutor->MaybeSchedule(now, TimeDuration()));
|
|
|
|
} else {
|
|
|
|
// 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();
|
|
|
|
|
|
|
|
if (!scx) {
|
|
|
|
// No context means this window was closed or never properly
|
|
|
|
// initialized for this language. This timer will never fire
|
|
|
|
// so just remove it.
|
|
|
|
timeout->remove();
|
|
|
|
continue;
|
|
|
|
}
|
2016-12-03 01:22:48 +03:00
|
|
|
|
2019-02-26 07:52:11 +03:00
|
|
|
#ifdef DEBUG
|
2019-02-19 16:48:05 +03:00
|
|
|
if (timeout->mFiringIndex <= mLastFiringIndex) {
|
|
|
|
MOZ_LOG(gTimeoutLog, LogLevel::Debug,
|
|
|
|
("Incorrect firing index for Run%s(TimeoutManager=%p, "
|
|
|
|
"timeout=%p) with "
|
|
|
|
"firingId %d - FiringIndex %" PRId64
|
|
|
|
" (mLastFiringIndex %" PRId64 ")",
|
|
|
|
timeout->mIsInterval ? "Interval" : "Timeout", this,
|
|
|
|
timeout.get(), timeout->mFiringId, timeout->mFiringIndex,
|
|
|
|
mFiringIndex));
|
|
|
|
}
|
2019-02-26 07:52:11 +03:00
|
|
|
MOZ_ASSERT(timeout->mFiringIndex > mLastFiringIndex);
|
2019-02-06 02:00:24 +03:00
|
|
|
mLastFiringIndex = timeout->mFiringIndex;
|
|
|
|
#endif
|
2019-03-19 23:52:03 +03:00
|
|
|
// This timeout is good to run.
|
|
|
|
bool timeout_was_cleared = window->RunTimeoutHandler(timeout, scx);
|
2019-01-26 20:18:06 +03:00
|
|
|
MOZ_LOG(gTimeoutLog, LogLevel::Debug,
|
|
|
|
("Run%s(TimeoutManager=%p, timeout=%p) returned %d\n",
|
|
|
|
timeout->mIsInterval ? "Interval" : "Timeout", this,
|
|
|
|
timeout.get(), !!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
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
if (timeout_was_cleared) {
|
|
|
|
// Make sure we're not holding any Timeout objects alive.
|
|
|
|
next = nullptr;
|
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
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
// Since ClearAllTimeouts() was called the lists should be empty.
|
|
|
|
MOZ_DIAGNOSTIC_ASSERT(!HasTimeouts());
|
2017-05-19 23:45:55 +03:00
|
|
|
|
2019-01-26 20:18:06 +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
|
|
|
|
2019-01-26 20:18:06 +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;
|
|
|
|
now = TimeStamp::Now();
|
2017-06-01 03:13:19 +03:00
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
// If we have a regular interval timer, we re-schedule the
|
|
|
|
// timeout, accounting for clock drift.
|
|
|
|
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
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
// Running a timeout can cause another timeout to be deleted, so
|
|
|
|
// we need to reset the pointer to the following timeout.
|
|
|
|
next = timeout->getNext();
|
2016-12-03 01:22:48 +03:00
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
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
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
if (needsReinsertion) {
|
|
|
|
// Insert interval timeout onto the corresponding list sorted in
|
|
|
|
// deadline order. AddRefs timeout.
|
|
|
|
// Always re-insert into the normal time queue!
|
|
|
|
mTimeouts.Insert(timeout, mWindow.IsFrozen()
|
|
|
|
? Timeouts::SortBy::TimeRemaining
|
|
|
|
: Timeouts::SortBy::TimeWhen);
|
|
|
|
}
|
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
|
|
|
// 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()) {
|
2018-10-12 21:01:19 +03:00
|
|
|
if (next) {
|
2019-01-26 20:18:06 +03:00
|
|
|
if (aProcessIdle) {
|
|
|
|
// We don't want to update timing budget for idle queue firings,
|
|
|
|
// and all timeouts in the IdleTimeouts list have hit their
|
|
|
|
// deadlines, and so should run as soon as possible.
|
|
|
|
|
|
|
|
// Shouldn't need cancelling since it never waits
|
|
|
|
MOZ_ALWAYS_SUCCEEDS(
|
|
|
|
mIdleExecutor->MaybeSchedule(next->When(), TimeDuration()));
|
|
|
|
} else {
|
|
|
|
// 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(next->When(), now));
|
2017-06-14 18:47:38 +03:00
|
|
|
}
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2017-07-06 17:01:40 +03:00
|
|
|
bool TimeoutManager::RescheduleTimeout(Timeout* aTimeout,
|
|
|
|
const TimeStamp& aLastCallbackTime,
|
|
|
|
const TimeStamp& aCurrentNow) {
|
|
|
|
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
|
|
|
|
2019-02-26 07:52:11 +03:00
|
|
|
#ifdef DEBUG
|
2019-02-06 02:00:24 +03:00
|
|
|
aTimeout->mFiringIndex = -1;
|
|
|
|
#endif
|
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
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
MOZ_LOG(gTimeoutLog, LogLevel::Debug,
|
2017-01-10 06:16:31 +03:00
|
|
|
("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();
|
2019-01-26 20:18:06 +03:00
|
|
|
mIdleExecutor->Cancel();
|
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
|
|
|
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;
|
|
|
|
});
|
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
// Clear out our lists
|
2018-10-12 21:01:19 +03:00
|
|
|
mTimeouts.Clear();
|
2019-01-26 20:18:06 +03:00
|
|
|
mIdleTimeouts.Clear();
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
|
2016-12-14 03:06:21 +03:00
|
|
|
void TimeoutManager::Timeouts::Insert(Timeout* aTimeout, SortBy aSortBy) {
|
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) {
|
2020-05-24 23:59:08 +03:00
|
|
|
aTimeout->SetTimeoutContainer(mTimeouts);
|
2016-12-03 01:22:48 +03:00
|
|
|
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() {
|
2019-01-26 20:18:06 +03:00
|
|
|
MOZ_LOG(gTimeoutLog, LogLevel::Debug, ("Suspend(TimeoutManager=%p)\n", this));
|
2017-01-10 06:16:31 +03:00
|
|
|
|
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();
|
2019-01-26 20:18:06 +03:00
|
|
|
mIdleExecutor->Cancel();
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void TimeoutManager::Resume() {
|
2019-01-26 20:18:06 +03:00
|
|
|
MOZ_LOG(gTimeoutLog, LogLevel::Debug, ("Resume(TimeoutManager=%p)\n", this));
|
2017-01-10 06:16:31 +03:00
|
|
|
|
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.
|
2019-04-11 17:12:43 +03:00
|
|
|
if (mWindow.IsDocumentLoaded() && !mThrottleTimeouts) {
|
2017-06-14 18:47:38 +03:00
|
|
|
MaybeStartThrottleTimeout();
|
2017-04-25 12:20:00 +03:00
|
|
|
}
|
|
|
|
|
2018-10-12 21:01:19 +03:00
|
|
|
Timeout* nextTimeout = mTimeouts.GetFirst();
|
2017-06-16 03:30:47 +03:00
|
|
|
if (nextTimeout) {
|
2017-06-14 18:47:38 +03:00
|
|
|
MOZ_ALWAYS_SUCCEEDS(MaybeSchedule(nextTimeout->When()));
|
2017-06-01 03:13:19 +03:00
|
|
|
}
|
2019-01-26 20:18:06 +03:00
|
|
|
nextTimeout = mIdleTimeouts.GetFirst();
|
|
|
|
if (nextTimeout) {
|
|
|
|
MOZ_ALWAYS_SUCCEEDS(
|
|
|
|
mIdleExecutor->MaybeSchedule(nextTimeout->When(), TimeDuration()));
|
|
|
|
}
|
2016-12-03 01:22:48 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void TimeoutManager::Freeze() {
|
2019-01-26 20:18:06 +03:00
|
|
|
MOZ_LOG(gTimeoutLog, LogLevel::Debug, ("Freeze(TimeoutManager=%p)\n", this));
|
2017-01-10 06:16:31 +03:00
|
|
|
|
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() {
|
2019-01-26 20:18:06 +03:00
|
|
|
MOZ_LOG(gTimeoutLog, LogLevel::Debug, ("Thaw(TimeoutManager=%p)\n", this));
|
2017-01-10 06:16:31 +03:00
|
|
|
|
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()) {
|
2018-10-12 21:01:19 +03:00
|
|
|
Timeout* nextTimeout = mTimeouts.GetFirst();
|
2017-06-14 04:08:27 +03:00
|
|
|
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
|
|
|
}
|
2019-01-26 20:18:06 +03:00
|
|
|
// the Idle queue should all be past their firing time, so there we just
|
|
|
|
// need to restart the queue
|
|
|
|
|
|
|
|
// XXX May not be needed if we don't stop the idle queue, as
|
|
|
|
// MinSchedulingDelay isn't relevant here
|
|
|
|
nextTimeout = mIdleTimeouts.GetFirst();
|
|
|
|
if (nextTimeout) {
|
|
|
|
mIdleExecutor->Cancel();
|
|
|
|
MOZ_ALWAYS_SUCCEEDS(
|
|
|
|
mIdleExecutor->MaybeSchedule(nextTimeout->When(), TimeDuration()));
|
|
|
|
}
|
2017-06-14 04:08:27 +03:00
|
|
|
}
|
2017-06-14 04:08:27 +03:00
|
|
|
}
|
|
|
|
|
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:
|
2020-02-21 13:41:47 +03:00
|
|
|
~ThrottleTimeoutsCallback() = default;
|
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) {
|
2019-04-11 17:12:43 +03:00
|
|
|
mWindow->TimeoutManager().StartThrottlingTimeouts();
|
2017-02-13 23:58:39 +03:00
|
|
|
mWindow = nullptr;
|
|
|
|
return NS_OK;
|
|
|
|
}
|
|
|
|
|
|
|
|
} // namespace
|
|
|
|
|
2017-07-28 16:31:00 +03:00
|
|
|
bool 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.
|
2019-07-26 23:06:08 +03:00
|
|
|
if ((aIsBackground
|
|
|
|
? StaticPrefs::dom_timeout_background_throttling_max_budget()
|
2019-07-26 23:09:34 +03:00
|
|
|
: StaticPrefs::dom_timeout_foreground_throttling_max_budget()) < 0) {
|
2017-07-28 16:31:00 +03:00
|
|
|
return false;
|
|
|
|
}
|
2017-07-20 18:06:20 +03:00
|
|
|
|
|
|
|
if (!mBudgetThrottleTimeouts || IsActive()) {
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Check if there are any active IndexedDB databases
|
2019-04-11 17:12:43 +03:00
|
|
|
if (mWindow.HasActiveIndexedDBDatabases()) {
|
2017-07-20 18:06:20 +03:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2017-08-04 13:28:15 +03:00
|
|
|
// Check if we have active PeerConnection
|
2019-04-11 17:12:43 +03:00
|
|
|
if (mWindow.HasActivePeerConnections()) {
|
2017-07-20 18:06:20 +03:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2019-04-11 17:12:43 +03:00
|
|
|
if (mWindow.HasOpenWebSockets()) {
|
2017-07-20 18:06:20 +03:00
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2017-06-14 18:47:38 +03:00
|
|
|
void 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
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
MOZ_LOG(gTimeoutLog, LogLevel::Debug,
|
2017-02-13 23:58:39 +03:00
|
|
|
("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;
|
2019-07-26 23:14:48 +03:00
|
|
|
mBudgetThrottleTimeouts =
|
|
|
|
StaticPrefs::dom_timeout_enable_budget_timer_throttling();
|
2017-06-14 18:47:38 +03:00
|
|
|
mThrottleTimeoutsTimer = nullptr;
|
2017-02-13 23:58:39 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void TimeoutManager::OnDocumentLoaded() {
|
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
|
|
|
}
|
|
|
|
|
2017-06-14 18:47:38 +03:00
|
|
|
void TimeoutManager::MaybeStartThrottleTimeout() {
|
2019-07-26 06:07:41 +03:00
|
|
|
if (StaticPrefs::dom_timeout_throttling_delay() <= 0 || mWindow.IsDying() ||
|
2018-04-04 03:10:16 +03:00
|
|
|
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
|
|
|
|
2019-01-26 20:18:06 +03:00
|
|
|
MOZ_LOG(gTimeoutLog, LogLevel::Debug,
|
2017-02-13 23:58:39 +03:00
|
|
|
("TimeoutManager %p delaying tracking timeout throttling by %dms\n",
|
2019-07-26 06:07:41 +03:00
|
|
|
this, StaticPrefs::dom_timeout_throttling_delay()));
|
2017-02-13 23:58:39 +03:00
|
|
|
|
2017-06-14 18:47:38 +03:00
|
|
|
nsCOMPtr<nsITimerCallback> callback = 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,
|
2019-07-26 06:07:41 +03:00
|
|
|
StaticPrefs::dom_timeout_throttling_delay(),
|
|
|
|
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() {
|
2020-04-07 18:17:47 +03:00
|
|
|
return mWindow.GetBrowsingContextGroup()->GetTimerEventQueue();
|
2017-06-01 03:13:19 +03:00
|
|
|
}
|