* The extension content drives the sizing of the browser and popup that contains it via the Extension:BrowserResized message. The ignoreResizes property throttles/debounces this initially, stashing the dimensions received rather than triggering resize of the popup for every message. When the popup is a subview and fixedWidth, we ignore width but *do* want to use the stashed height value.
* Until the panel is given visibility, it has 0 height, so after setting visibility, wait until the next refresh-driver tick before measuring any header which should get added to the overall view height
MozReview-Commit-ID: AgcruVb9QPA
--HG--
extra : rebase_source : 429503a7d38559cc8670a3205b3290b8e0bbbfa2
This test has been disabled because it was failing intermittently with a pretty high
frequency on the Windows platform, the reasons behind the failures have been fixed
in Bug 1435100.
MozReview-Commit-ID: FNJqocBcxnf
--HG--
extra : rebase_source : f5fd1392bc53f137c8e48e433fddd103af74eaad
We need a static disable event so we can handle shutdown
of extensions using hidden tabs. This allows us to handle
shutdown when the extension has not yet used the API (thus
the ext-tabs api has not loaded).
MozReview-Commit-ID: BxV5PmbHJ8o
--HG--
extra : rebase_source : 78dd8b6e6b6ee1b09d446545dc8b38e32d7e9969
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
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.
The titles for the root bookmark folders in the database will now never get updated. This
avoids doing maintenance and changing them if the locale changes.
The UI is now responsible for displaying the correct title.
WebExtensions API will get the UI visible names.
MozReview-Commit-ID: ErPPJXxy2d3
--HG--
extra : rebase_source : f08caa5b0d00ae81ffabf4a1076bd56b66414418
See the comment on "Address test failures caused by bumping timer precision to 2 ms"
for more details.
MozReview-Commit-ID: LrsucEPdZIo
--HG--
extra : rebase_source : 8147c034f7dc93f678eebc80b0afabf55729d804
There are a few different reasons why tests needed updating (not an exhaustive list):
- Tests assume that successive operations take place at different times.
- Tests assume that an operation took a minimum amount of time.
- Tests hardcodes a specific delay.
In most cases we hardcode the preference off. In some cases this is the best approach,
in others, we would like to improve. The bug for tracking those improvements is Bug 1429648
An improvement that is present in some tests is to hardcode a specific precision reduction
that is acceptable based on the confides of the test. (Obviously this needs to be a fix for
the test framework and not a requirement on the feature being tested.)
In a few places, the test itself can be fixed, for example to no longer require the end
time of an operation to be strictly greater than the start time, and allows it to be equal
to it.
MozReview-Commit-ID: J59c7xQtZZJ
--HG--
extra : rebase_source : df8a03e76eaf9cdc9524dbb3eb9035af237e534b
