KeyframeEffect and KeyframeEffectReadOnly constructors can run in the caller
compartment, which is okay because of the following reasons:
1. The target window global is used for most operation:
* KeyframeEffectReadOnly::ConstructKeyframeEffect uses the target window
global instead of current global.
* KeyframeEffectParamsFromUnion which receives `aGlobal.CallerType()`
In Xray case, Web Animations API can be disabled on web content
(currently disabled on beta/release by default), and in that case some API
won't work even it's triggered from WebExtensions, but it should be fine.
2. GetKeyframesFromObject is executed in the caller's compartment to access
the passed-in JSObject that is keyframe, with iterable/iterator protocols.
This operation doesn't perform any GCThing allocation on the target window
global.
Previously, all errors would be reported in <module> and you would only know the name of the whole failing test. This patch adds in the filename and line number to the stack traces, as well as the C++ "fragment" that was executing (very helpful when manually running gdb on the gdb-tests binary.)
--HG--
extra : rebase_source : cc1c5cdb7a2737d925ca3dbd2030833845d3f922
What it's doing is not so complicated.
Source-Repo: https://github.com/servo/servo
Source-Revision: d423e54d58d6cced950896eed1957ee2989f4eee
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 5f2eb141315f4abbc2e2340950d43679aaf79f42
AccessibleNode::GetParentObject is a non-overriding final virtual function. GetParentObject is a common virtual function in many DOM classes, but AccessibleNode does not derive from any base classes that define virtual GetParentObject or have any derived classes of its own.
WebCryptoTask::CalculateResult and CallCallback are non-overriding final virtual functions that mirror virtual function names in the CryptoTask class, even though WebCryptoTask does not actually derive from CryptoTask.
nsWindowBase::GetWindowHandle is a non-overriding final virtual function. The only other function called GetWindowHandle is MouseScrollHandler::EventInfo::GetWindowHandle, which is not related to the nsWindowBase class.
MozReview-Commit-ID: 4ldSAyP3ZpP
--HG--
extra : rebase_source : cd6fea309c042183db59653ed39e1e63b70c6a63
The meaning of "possibly-changed" is provided by the big comment above
MustSendToContentProcesses.
On a new profile this reduces the number of prefs sent like so:
- Command-line: 222 --> 3
- IPC: 3129 --> 130
On an older profile:
- Command-line: 222 --> 3
- IPC: 3165 --> 180
MozReview-Commit-ID: DcgedhXhZd8
--HG--
extra : rebase_source : acef424fab5031347cbcbd5c3e6a24ee66895ef9
This makes it possible to implement nsDisplayBlend blob image invalidation.
It currently only includes an implementation for Skia and DrawTargetRecording.
All other backends will crash when used.
MozReview-Commit-ID: 2GhdDxi4jHG
Along with removing the view source standalone windows and prefs this patch:
1) Re-structures several of the view source tests that were only testing the old
standalone windows to now test view source in tab.
2) Adds support viewSourceUtils.viewSource() to open a browser window when there
aren't any open (for browser toolbox view source).
3) Cleans up some of the API for viewSourceUtils and removes the old deprecated
ways of calling it.
MozReview-Commit-ID: DI6sgZwbCf
--HG--
extra : rebase_source : 64677186122f74ab95912d5f3f173cf37472458a
The behavior that this test expects is not the same as when viewing
source in a browser tab.
MozReview-Commit-ID: EwzrCz0VCJY
--HG--
extra : rebase_source : 6e4f994d86527e6608088fb84c1be8870be3c62e
closeConnection is a new API introduced in N. We don't really support it
at the moment but we also don't want the default behavior, so we
implement a dummy.
MozReview-Commit-ID: JY1Tl30X2s7
--HG--
extra : rebase_source : a64371a05aed9db957df2a97da5b23c90760cdb1
Getting the selection offsets in onCreateInputConnection can fail
because of us being on a wrong thread. The solution is to cache the last
selection offsets and use those in onCreateInputConnection.
MozReview-Commit-ID: AOlZsuOvzHm
--HG--
extra : rebase_source : 42f35bc60219707fc29db7cc2803f64313806244
The file copies and renames make this patch look a bit confusing. Here's what
happens:
ThreadInfo.h:
Most of the code gets moved into RegisteredThread.h and ProfiledThreadData.h,
but a small piece remains in ThreadInfo.h.
ThreadInfo.cpp:
Gets split into RegisteredThread.cpp and ProfiledThreadData.cpp.
ThreadInfo.cpp itself goes away.
In the mercurial changeset, I've marked ThreadInfo.h as being copied to both
RegisteredThread.h and to ProfiledThreadData.h, and ThreadInfo.cpp as being
copied to RegisteredThread.cpp and as being renamed to ProfiledThreadData.cpp.
MozReview-Commit-ID: 1j1imAv9cTd
--HG--
rename : tools/profiler/core/ThreadInfo.cpp => tools/profiler/core/ProfiledThreadData.cpp
rename : tools/profiler/core/ThreadInfo.h => tools/profiler/core/ProfiledThreadData.h
rename : tools/profiler/core/ThreadInfo.cpp => tools/profiler/core/RegisteredThread.cpp
rename : tools/profiler/core/ThreadInfo.h => tools/profiler/core/RegisteredThread.h
extra : rebase_source : 91310691d5e46246ec03305511c1b86ab458b0b9