Currently imagelib's DecodePool spawns the maximum number of threads
during startup, based on the number of processors. This patch changes it
to spawn a single thread on startup (which cannot fail), and more up to
the maximum as jobs are added to the queue. A thread will only be
spawned if there is a backlog present when a new job is added. This
typically results in fewer threads allocated in the parent process, as
well as deferred spawning in the content processes.
Originally we attempted to finalize the current frame from the contained
decoder in nsICODecoder::FinishResource. This is wrong because we
haven't acquired the frame from the contained decoder yet. This happens
in nsICODecoder::GetFinalStateFromContainedDecoder, and so
imgFrame::Finalize call should be moved there. This was causing us to
use fallback image sharing with WebRender after a GPU process crash,
instead of shared surfaces, because it can't get a new file handle for
the surface data until we have finished writing all of the image data.
When in permanent private browsing mode, always return false
for isAutomaticRestoreEnabled. This ensures that there will
not be any confusion inside nsBrowserContentHandler.defaultArgs
as to whether a one time session restore will occur.
Also, for consistency and in case someone looks at the pref,
avoid setting browser.sessionstore.resume_session = true during
browser shutdown.
This bug occurred when staging was not used during the update
process. On Windows it always occurred because staging is not
used even when it should be (https://trac.torproject.org/18292).
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
Andrew Osmond
Jon Coppeard
Kathy Brade
Brindusan Cristian
Benjamin Bouvier
Xidorn Quan
Richard Marti
Dorel Luca
Jonathan Kew
Tooru Fujisawa
Steve Fink
David Keeler
Daniel Stenberg
J. Ryan Stinnett
Emilio Cobos Álvarez
Gurzau Raul
Ed Lee
Oriol Brufau
Prathiksha
Chris Peterson
Nicholas Nethercote
Luke Wagner
Jeff Walden
Andreea Pavel
Jeff Muizelaar
Brendan Dahl
Jim Chen
Jonathan Kingston
Markus Stange