The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55444
--HG--
extra : moz-landing-system : lando
Don't swizzle the terminate method in process types that don't initialize the nsApplication.
Differential Revision: https://phabricator.services.mozilla.com/D26397
--HG--
extra : moz-landing-system : lando
This patch initializes some HAL components greedily so that we can get rid of
lazy initializers within the code. Observers are still lazily initialized
because they can be instanced within content processes but that doesn't always
happen and we don't want to pay the memory price for structures we don't use.
Shutdown is now happening at a fixed time for all HAL components save
WakeLocks. This ensures that we don't destroy an object while still iterating
over it, something that could happen before.
Finally a workaround for a compiler limitation has been removed.
Differential Revision: https://phabricator.services.mozilla.com/D3100
--HG--
extra : moz-landing-system : lando
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : dd000a05bfc2da40c586644d33ca4508fa5330f6
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : 59e4a6ced7d14d2a01c0b79e944078ea84cae523
Categories are useful to indicate: This much % of time was spent in this category.
The EVENTS category isn't a very good match for this. This category is currently
only set on labels of functions that handle the processing of an event. But
those functions are usually closer to the base of the stack, and the actual CPU
work during the processing of an event is usually in another category closer to
the top of the stack, e.g. in JS if we're running an event handler, or in LAYOUT
if we're hit testing the position of the event.
This changeset removes the EVENTS category and replaces all uses of it with the
OTHER category.
MozReview-Commit-ID: JPm5hQiBkvp
--HG--
extra : rebase_source : 66f8ee003d2f70111f4cff16d6e2d906ef4bf10b
Categories are useful to indicate: This much % of time was spent in this category.
The EVENTS category isn't a very good match for this. This category is currently
only set on labels of functions that handle the processing of an event. But
those functions are usually closer to the base of the stack, and the actual CPU
work during the processing of an event is usually in another category closer to
the top of the stack, e.g. in JS if we're running an event handler, or in LAYOUT
if we're hit testing the position of the event.
This changeset removes the EVENTS category and replaces all uses of it with the
OTHER category.
MozReview-Commit-ID: JPm5hQiBkvp
--HG--
extra : rebase_source : fb1ff20aeebb7ac494227e62ba2101039578808c
Categories are useful to indicate: This much % of time was spent in this category.
The EVENTS category isn't a very good match for this. This category is currently
only set on labels of functions that handle the processing of an event. But
those functions are usually closer to the base of the stack, and the actual CPU
work during the processing of an event is usually in another category closer to
the top of the stack, e.g. in JS if we're running an event handler, or in LAYOUT
if we're hit testing the position of the event.
This changeset removes the EVENTS category and replaces all uses of it with the
OTHER category.
MozReview-Commit-ID: JPm5hQiBkvp
--HG--
extra : rebase_source : 34fb2ca94151403a6d7ffd5a8b840f00a8bb4afb
Fairly straightforward, just a blanket removal. Haven't heard
anything on dev-platform or fx-data-dev regarding this removal,
so I think it's likely safe to remove on Nightly, and we can
revert if anyone makes a fuss.
As part of removing the HangMonitor, I renamed a few things and
reorganized the namespaces to not depend on a HangMonitor
namespace. Hopefully this doesn't produce too much noise in the
diff, it just seemed appropriate to move everything around
rather than keep dangling vestiges of the old system.
MozReview-Commit-ID: 8C8NFnOP5GU
--HG--
extra : rebase_source : a8840bd26f4b01b756ffa72345ababb625048550
* OSX
Make the lock of the type kIOPMAssertionTypeNoDisplaySleep and kIOPMAssertionTypeNoIdleSleep
as a singleton. Won't need to require an extra lock.
* Windows
Add |mRequireForDisplay| to ensure the "audio-playing" won't overwrite the previous
display requirement.
* Android
Add "audio-playing" and "video-playing", and make sure the audio-lock won't be cancel
when receiving "WakeLockDelegate.STATE_LOCKED_BACKGROUND".
MozReview-Commit-ID: 97oNX7H2qij
--HG--
extra : rebase_source : 24fa8b267ad97d668fa55462d1f61ef5c92b632f
According to [1], kIOPMAssertionTypeNoDisplaySleep prevents display sleep and
kIOPMAssertionTypeNoIdleSleep prevents idle sleep.
We should use kIOPMAssertionTypeNoIdleSleep for audio playing, because it won't
need to block the display.
[1] https://developer.apple.com/library/content/qa/qa1340/_index.html
---
On Windows, ES_DISPLAY_REQUIRED forces display on, and ES_SYSTEM_REQUIRED forces
system on working state [2].
[2] https://msdn.microsoft.com/zh-tw/library/windows/desktop/aa373208(v=vs.85).aspx
MozReview-Commit-ID: Izs29PdzQOW
--HG--
extra : rebase_source : d0726131735b9cedf566f937204e585345b9d5e3
For knowing the wake lock usage more clearly, we should use more specific topic name.
In OSX, you can use "$ pmset -g assertions" to check all the wakelock.
In Windows, using "$ powser -energy" to generate the energy report.
MozReview-Commit-ID: rAXnkxTvLc
--HG--
extra : rebase_source : 42ebf204673d3c913739f64c71c24af20d37c95d
Before this change we were trying to change the settings from both the content
and parent processes, so this doesn't change any functionality. This allows to
remove access to the com.apple.PowerManagement.control mach service from the
content process.
MozReview-Commit-ID: 3DOhqG5U6oz
--HG--
extra : rebase_source : dee0b97c444ae95cfc8f80cb0fb99aa9e2658d51
This patch makes the following changes to the macros.
- Removes PROFILER_LABEL_FUNC. It's only suitable for use in functions outside
classes, due to PROFILER_FUNCTION_NAME not getting class names, and it was
mostly misused.
- Removes PROFILER_FUNCTION_NAME. It's no longer used, and __func__ is
universally available now anyway.
- Combines the first two string literal arguments of PROFILER_LABEL and
PROFILER_LABEL_DYNAMIC into a single argument. There was no good reason for
them to be separate, and it forced a '::' in the label, which isn't always
appropriate. Also, the meaning of the "name_space" argument was interpreted
in an interesting variety of ways.
- Adds an "AUTO_" prefix to PROFILER_LABEL and PROFILER_LABEL_DYNAMIC, to make
it clearer they construct RAII objects rather than just being function calls.
(I myself have screwed up the scoping because of this in the past.)
- Fills in the 'js::ProfileEntry::Category::' qualifier within the macro, so
the caller doesn't need to. This makes a *lot* more of the uses fit onto a
single line.
The patch also makes the following changes to the macro uses (beyond those
required by the changes described above).
- Fixes a bunch of labels that had gotten out of sync with the name of the
class and/or function that encloses them.
- Removes a useless PROFILER_LABEL use within a trivial scope in
EventStateManager::DispatchMouseOrPointerEvent(). It clearly wasn't serving
any useful purpose. It also serves as extra evidence that the AUTO_ prefix is
a good idea.
- Tweaks DecodePool::SyncRunIf{Preferred,Possible} so that the labelling is
done within them, instead of at their callsites, because that's a more
standard way of doing things.
--HG--
extra : rebase_source : 318d1bc6fc1425a94aacbf489dd46e4f83211de4
ScreenHelperCocoa is the platform dependent part of the original
nsScreenManagerCocoa and nsScreenCocoa. It registers
NSApplicationDidChangeScreenParametersNotification and pushes updates
to ScreenManager. See patch part 4. for how ScreenManager works.
MozReview-Commit-ID: 1A5ha4Ys2dL
--HG--
rename : widget/cocoa/nsScreenManagerCocoa.h => widget/cocoa/ScreenHelperCocoa.h
rename : widget/cocoa/nsScreenManagerCocoa.mm => widget/cocoa/ScreenHelperCocoa.mm
extra : rebase_source : c7737e18656710c36f6c04ac71a17deeca3224a5
widget/cocoa/nsAppShell.mm:113:47 [-Wmismatched-parameter-types] conflicting parameter types in implementation of 'nextEventMatchingMask:untilDate:inMode:dequeue:': 'NSEventMask' (aka 'unsigned long long') vs 'NSUInteger' (aka 'unsigned long')
NSWindow's nextEventMatchingMask method expects a parameter of type NSEventMask, not NSUInteger, when building x86_64 with SDK 10.12:
https://developer.apple.com/reference/appkit/nswindow/1419304-nexteventmatchingmask
This is motivated by three separate but related problems:
1. Our concept of recursion depth is broken for things that run from AfterProcessNextEvent observers (e.g. Promises). We decrement the recursionDepth counter before firing observers, so a Promise callback running at the lowest event loop depth has a recursion depth of 0 (whereas a regular nsIRunnable would be 1). This is a problem because it's impossible to distinguish a Promise running after a sync XHR's onreadystatechange handler from a top-level event (since the former runs with depth 2 - 1 = 1, and the latter runs with just 1).
2. The nsIThreadObserver mechanism that is used by a lot of code to run "after" the current event is a poor fit for anything that runs script. First, the order the observers fire in is the order they were added, not anything fixed by spec. Additionally, running script can cause the event loop to spin, which is a big source of pain here (bholley has some nasty bug caused by this).
3. We run Promises from different points in the code for workers and main thread. The latter runs from XPConnect's nsIThreadObserver callbacks, while the former runs from a hardcoded call to run Promises in the worker event loop. What workers do is particularly problematic because it means we can't get the right recursion depth no matter what we do to nsThread.
The solve this, this patch does the following:
1. Consolidate some handling of microtasks and all handling of stable state from appshell and WorkerPrivate into CycleCollectedJSRuntime.
2. Make the recursionDepth counter only available to CycleCollectedJSRuntime (and its consumers) and remove it from the nsIThreadInternal and nsIThreadObserver APIs.
3. Adjust the recursionDepth counter so that microtasks run with the recursionDepth of the task they are associated with.
4. Introduce the concept of metastable state to replace appshell's RunBeforeNextEvent. Metastable state is reached after every microtask or task is completed. This provides the semantics that bent and I want for IndexedDB, where transactions autocommit at the end of a microtask and do not "spill" from one microtask into a subsequent microtask. This differs from appshell's RunBeforeNextEvent in two ways:
a) It fires between microtasks, which was the motivation for starting this.
b) It no longer ensures that we're at the same event loop depth in the native event queue. bent decided we don't care about this.
5. Reorder stable state to happen after microtasks such as Promises, per HTML. Right now we call the regular thread observers, including appshell, before the main thread observer (XPConnect), so stable state tasks happen before microtasks.
