Since the number of tabs is not actually displayed, having two separate strings from 1 vs many is preferable.
MozReview-Commit-ID: y1dgvsCxmC
--HG--
extra : rebase_source : ad694b2dc7bc44128f909e91a90c4822c0698770
In Javascript, we re-clamp timers to ensure they stay the same. Because of double imprecision
sometimes they don't stay the same, and are clamped downwards. If that happens we detect it,
and if we were originally off by an epsilon from a clamped value, we accept the value in the
name of double imprecision.
However, the epsilons were originally chosen somewhat arbitrarily. They worked for small
numbers, where imprecision from doubles were very small. But large doubles have much less
precise fractional parts. So the epsilons were too large for large numbers where the
imprecision was larger.
MozReview-Commit-ID: HnYYo4cuv96
--HG--
extra : rebase_source : 3a1d70e801fe7b8e1a8b2c191854db3db11751a9
KeyframeEffect and KeyframeEffectReadOnly constructors can run in the caller
compartment, which is okay because the current compartment is used in the
following places and all of them are safe:
1. GlobalObject::CallerType(), that is ultimately passed to
nsDocument::IsWebAnimationsEnabled in KeyframeEffectParamsFromUnion,
to decide whether to copy mIterationComposite/mComposite to
KeyframeEffectParams.
GlobalObject::CallerType() can now be different than the target window's one,
if the caller has the system principal and the target is web content, and
in that case nsDocument::IsWebAnimationsEnabled there always returns true
while Web Animations can be disabled on web content.
honoring the mIterationComposite/mComposite properties is OK, since it just
changes the animation behavior, and this is disabled by default until
remaining spec issues are resolved.
2. GlobalObject::Context(), that is ultimately passed to
KeyframeUtils::GetKeyframesFromObject and used while extracting information
from passed-in keyframe object, with iterable/iterator protocols.
Performing that operation in the caller side is okay, since the same thing
can be done on caller, and the operation doesn't perform any GCThing
allocation on the target window global.
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
This allows the ViewShowing event for the main view to prevent the panel from opening. It also avoids setting up the main view if the panel is not opened.
MozReview-Commit-ID: LK8tBcz6lkK
--HG--
extra : rebase_source : beb721ff996f11d7e162a4ff431c38b30bf42ca6
extra : source : c8115e90ffa8af27ef00cbd0f8da68dce7ce36bd
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
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.
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).
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
Tom Ritter
Andreea Pavel
Johann Hofmann
Francesco Lodolo (:flod)
Marco Bonardo
Ciure Andrei
Edouard Oger
Csoregi Natalia
Tooru Fujisawa
Florian Quèze
Masayuki Nakano
shindli
Paolo Amadini
Nihanth Subramanya
Xidorn Quan
Dorel Luca
Gurzau Raul
Kathy Brade
Brindusan Cristian
Narcis Beleuzu
Dão Gottwald
Margareta Eliza Balazs
Noemi Erli
Ed Lee
Oriol Brufau
Prathiksha
Brendan Dahl
Jonathan Kingston
ffxbld