Normally the docshell stops the content viewer in nsDocShell::Stop(), but in this
case it won't be stopped in that function since the new content viewer has never
been associated with this docshell.
dom/base/test/test_bug1126851.html is a test case that we bail out
from CreateContentViewer() due to win.close() in an unload event callback.
MozReview-Commit-ID: 7O7TmwHN9re
--HG--
extra : rebase_source : 8f50efd4b582d3283ad482fd896b5d558c0e8269
There are four call sites of FirePageHideNotification(). Two of them are
handled in this patch. The other two will be taken care of in the subsequent
patches in this patch series respectively.
Without this fix, the test case in this patch causes assertions when
cycle collection happens.
MozReview-Commit-ID: 6GSxjdfXGcY
--HG--
extra : rebase_source : 998b95ae90a1ad80dc177d5eecf1a592ba375116
We bail out the function to make sure we don't process CreateContentViewer
and mLoadingURI is not re-initialized in the function while destroying the
docshell.
MozReview-Commit-ID: AYJ1t2N786N
--HG--
extra : rebase_source : b02c6a061a8938936b40195e166ac2b6c187406d
When the window is destroyed in unload event callbacks for the previous
document, we haven't started loading, i.e. we haven't called BlockOnload()
for the new document in nsContentSink::WillBuildModelImpl, so if we called
nsDocument::StopDocumentLoad() in such cases, UnblockOnload calls will mismatch
BlockOnload calls.
MozReview-Commit-ID: HjLtmGGvXKS
--HG--
extra : rebase_source : 8d81afd5cd7988cb165d9fee5dcfbf5fbf702331
Virtual function declarations should specify only one of `virtual`, `final`, or `override`, as per the Mozilla C++ style guide:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style
This lint warns about:
virtual void Bad1() final
void Bad2() final override
void Bad3() override final
Caveats: This lint doesn't warn about `virtual void NotBad() override` at this time because there are 8000+ instances. It also doesn't warn about function declarations that span multiple lines because the regex can't match across line breaks.
MozReview-Commit-ID: LcBsOAKKgz7
--HG--
extra : rebase_source : 4da72ffac59acdc9796e3f540f24bb97af989cd0
Note that this patch also replaces legacy VK_* with KEY_*, and replaces
synthesizeKey() for inputting some characters with sendString() because
it's better and clearer what it does and it sets shiftKey state properly.
MozReview-Commit-ID: De4enbjux3T
--HG--
extra : rebase_source : 2296b84bff8e22f01eeb48cd8614fac5db11136a
Most callers of EventUtils.synthesizeKey() call it only with the first argument,
aKey. Therefore, it should be optional argument.
This patch also fixes a bug of EventUtils.sendChar(). It sets shiftKey to
true even for "0" - "9" and " ". When I replace syntesizeKey() which just
type text with sendString() in the following patch, I hit this bug.
MozReview-Commit-ID: 9ndL9jLho2N
--HG--
extra : rebase_source : d9dc6bd5f9091da674f0481b4b0098694360a125
Currently, we dispatch keypress event when Enter is pressed without modifiers
or only with Shift key. However, the other browsers dispatch keypress event
for Ctrl + Enter in any platforms even if it doesn't cause any text input.
So, we should fire keypress event for Ctrl + Enter even in strict keypress
dispatching mode.
Note that with other modifiers, it depends on browser and/or platform.
So, anyway, web developers shouldn't use keypress event to catch
Alt + Enter, Meta + Enter and two or more modifiers + Enter.
MozReview-Commit-ID: 3uUMkhL5VfJ
--HG--
extra : rebase_source : 8149acd958b238c8216f683a42fa05c3cf24570a
This patch adds an inner class to CacheIRSpewer that manages access to the
CacheIRSpewer and dramatically simplifies the consuming code.
Note: this changes the CacheIRSpewer to no longer use LockGuard; instead
the raw mutex is managed by CacheIRSpewer. This is because the RAII nature
of CacheIRSpewer::Guard prevents constructing the LockGuard if-and-only-if
the spewer is enabled.
Puts Remote (Synced) Tab matches before other history results.
Changes deduping algorithm to replace simple history matches with tab matches when the url is the same.
Keeps overriding a Remote Tab with a Local Tab when the url is the same.
MozReview-Commit-ID: 76urDklKtRF
--HG--
extra : rebase_source : f5d37af3d0c0714e0f33b5548c4bb3b90519543b
The image decoding thread pool can grow to be quite large, up to 32
threads, depending on the number of processors on the system. If the
user is not actively browsing, these threads are occupying resources
which could be reused elsewhere. After the timeout period, it will
release up to half of the threads in the pool.
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.
Hiroyuki Ikezoe
Nihanth Subramanya
Miko Mynttinen
shindli
Honza Bambas
Sebastian Hengst
Rail Aliiev
Cosmin Sabou
Chris Peterson
Jason Orendorff
Jeff Muizelaar
Jonathan Kew
Masayuki Nakano
Matthew Gaudet
Paolo Amadini
Johann Hofmann
Margareta Eliza Balazs
Marco Bonardo
Andrew Osmond
Jon Coppeard
Kathy Brade
Brindusan Cristian
Benjamin Bouvier
Xidorn Quan
Richard Marti
Dorel Luca
Tooru Fujisawa
Steve Fink