1. Set the capacity to 1 when IsExclusive is true.
2. Set it to 3 because Try shows we never have more the 3 elements when IsExclusive is false.
MozReview-Commit-ID: dmIeE6ZTeh
--HG--
extra : rebase_source : fc6b173d3a389d11424238f76cbae1f496155ba5
extra : source : c6203c27b8020999ed39ff43ddf5173f5111ef6b
This seems like an existing bug. If the content specifies
attributeType="yer:opacity", we should not try to animate it as a CSS property.
This patch adds a namespace check before we try to animate as a CSS property.
MozReview-Commit-ID: 1LpBa23ddqX
--HG--
extra : rebase_source : c5a4edb4c48bfd6116e58d4ef3eb91384ee86bd5
In bug 1315874 we will create a method to check if we're likely to need to
resolve base styles or not, and for that we need to extract the check for
whether or not we're animating a CSS property.
MozReview-Commit-ID: 9Ybsi91fro8
--HG--
extra : rebase_source : e2f72a7d807bfbe026fbd1a603cd993c3d502584
nsSMILCompositor::mCachedBaseValue is an nsAutoPtr<nsSMILValue> that we allocate
on the heap. It looks like we did that back in bug 533291 presumably because it
makes transferring these cached values between nsSMILCompositor objects cheaper.
One drawback of this, however, is that mCachedBaseValue has two null states:
the mCachedBaseValue pointer can be null, and the pointed-to nsSMILValue can be
a null value (i.e. IsNull() returns true).
Now that we have move ctors and operators defined for nsSMILValue we can
transfer these objects between compositors cheaply without requiring the object
to be allocated as separate heap object. This patch makes mCachedBaseValue just
a regular nsSMILValue class member (i.e. drops the nsAutoPtr).
There's a subtle difference in behavior with regards to the first sample.
Previously we would compare the (initially) null mCachedBaseValue pointer with
the passed-in nsSMILValue and set mForceCompositing to true. With this patch,
however, we will only set mForceCompositing to true if the passed-in
mCachedBaseValue is not null.
I believe this is correct, however, since if we don't call GetBaseValue in
ComposeAttribute we should not be setting mForceCompositing to true (something
else should ensure that gets set to true), and if we do call GetBaseValue the
result should not be a null nsSMILValue (except in some OOM cases where we don't
really care if we miss a sample). This patch adds an assertion to check that
GetBaseValue does, in fact, return a non-null value. (I checked the code and
this appears to be the case. Even in error cases we typically return an empty
nsSMILValue of a non-null type. For example, the early return in
nsSMILCSSProperty::GetBaseValue() does this.)
MozReview-Commit-ID: BRJFa4xMdxz
--HG--
extra : rebase_source : f3e3ca1e01e73610523bde7583e2a002d2473184
We will add to these includes later in this patch series so we sort them now so
it's clear where to add to.
MozReview-Commit-ID: CgqlS3f62nu
--HG--
extra : rebase_source : 009e8de1961cfd3d0f9cd72061e2e8f254f03cad
A virtual canvas is basically a canvas that seems bigger than is actually is.
The technique consists in moving a fixed sized canvas during the scrolling, when
is needed, to give the illusion that it always covers the entire document.
MozReview-Commit-ID: Hp4cUZaBdm8
--HG--
extra : rebase_source : 536891732a6247103734d60f9d8720dc2131815f
Some interface tests into mochitest is failure on android beta and release.
test_serviceworker_interfaces.js has nonReleaseAndroid flag, so we should use it into test_interfaces.js and test_worker_interfaces.js
MozReview-Commit-ID: A1aHrTXwGil
--HG--
extra : rebase_source : 0990ec8a50b664ac711ee4977a104286f40ae07e
This is a PR of https://bugzilla.mozilla.org/show_bug.cgi?id=1326131
In Gecko, we resolve CSS variables when we generate keyframes for each
animations (i.e. when we create script animations, when we create/update CSS
animations). AnimationValue::from_declaration is only called in both cases.
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
<!-- Either: -->
- [X] These changes do not require tests because it's for stylo.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: a7e18560e52d2b29ee2a8cb96b8592aa9df5e1fe
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 82fe2b16dec7132db86d2f71b98defb349febb15
<!-- Please describe your changes on the following line: -->
r? @jdm
issue https://github.com/servo/servo/issues/15252
The primary goal of this PR is to add add a generic trait method that returns a void ptr.
In addition to that change, I made the casting explicit in `components/script/dom/bindings/callback.rs` and `components/script/dom/promise.rs`. I did not use the new trait method because `AddRawValueRoot` is not looking for a `c_void`. It's looking for `std::os::raw::c_char`.
```rust
pub fn AddRawValueRoot(cx: *mut JSContext, vp: *mut Value,
name: *const ::std::os::raw::c_char) -> bool;
```
So I replace the `as *const _ ` with a more specific cast.
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#15252
<!-- Either: -->
- [ ] There are tests for these changes OR
- [x] These changes do not require tests because
This seems like code cleanup. It shouldn't change behaviour.
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 8d8fea0b4bf323be42eff3ad5624ce33892fb6df
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : d5992625f30523ee372f54d0005b211d6c9a6b41
Confusion between storeDone() and storeDone(long end) resulted in certain sessions (bookmarks
and form history) not overriding the current method. As a result, their final "flush the queue"
methods weren't being called by the buffering middleware.
This patch removes the storeDone(long end) method, making such confusion a non-issue.
Given that a lot of sessions tend to build up buffers which they need to then flush after a storeDone()
call, passing in a timestamp into that method doesn't make sense. Instead, let's supply a default
implementation in RepositorySession which calls onStoreCompleted(endTimestamp) with current time,
and allow sessions to override this method and own the onStoreCompleted(endTimestamp) call.
MozReview-Commit-ID: 84o7aAL8RPC
--HG--
extra : rebase_source : 41767ad502bd5ad8a0a487235bfdca8cf0d0c927
Also move some related files and rules used for `make install`.
Also move the js directory up in the top-level directory, so that the
linking order for the js library stays the same (fdlibm and ffi going
after the js engine objects)
This has the side effect of moving js/src/target very early in the
compilation tier.
--HG--
rename : js/src/js-config.in => js/src/build/js-config.in
rename : js/src/js.pc.in => js/src/build/js.pc.in
rename : js/src/symverscript.in => js/src/build/symverscript.in
extra : rebase_source : 7f188ee11469c7d352d4d9c90c8ba72c97224652
The code doing that was already excluding OSX, so we obviously don't
need it on OSX. On FreeBSD, afaict, USDT (userspace dtrace) probes don't
require that extra ELF object. Solaris presumably does, but the 6 years
old bug 702179 says it's not been working for that long, and configure
doesn't support Solaris targets anyways.
Keeping this build system code working past the changes coming in bug
1262241 is not guaranteed and can't be tested, so I'd rather get rid of
effectively dead code rather than trying to maybe not break it while
moving it.
--HG--
extra : rebase_source : b41ab77804c17529e2580ced8e8b5fd302ff7831
This is split into a separate patch in an attempt to get a better
diff.
MozReview-Commit-ID: L9AI3VD2pbV
--HG--
extra : rebase_source : 6dc47abd27d8f66886af4cbb458b6d00e8d5c7ee
This retains the advantage of running only once per process, while
avoiding the per-process overhead of a jsm.
MozReview-Commit-ID: 1N53MvRwUpg
--HG--
rename : browser/modules/ContentObservers.jsm => browser/modules/ContentObservers.js
extra : rebase_source : 6a502cff26fcb55526f97385274bbae871f5cc6c
Preserve more information from transform function parsing.
Preserve angle unit while parsing.
Simplify SpecifiedMatrix.
Use the write! macro for formatting with a helper called Css.
Implement ToCss for &T if T implements ToCss.
Add some tests and update others.
closes#15194
<!-- Please describe your changes on the following line: -->
---
<!-- Thank you for contributing to Servo! Please replace each `[ ]` by `[X]` when the step is complete, and replace `__` with appropriate data: -->
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#15194 (github issue number if applicable).
<!-- Either: -->
- [X] There are tests for these changes OR
- [ ] These changes do not require tests because _____
<!-- Also, please make sure that "Allow edits from maintainers" checkbox is checked, so that we can help you if you get stuck somewhere along the way.-->
<!-- Pull requests that do not address these steps are welcome, but they will require additional verification as part of the review process. -->
Source-Repo: https://github.com/servo/servo
Source-Revision: 8747c4e04cdecf79ccf6a3279679f04ad07a6a42
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 3f4383631e4ad912c786e0f028139a8c326c3101
To observe the difference, use `javap -l`. For example, for
automationRelease and automationDebug built with `./mach gradle clean
app:assembleAutomationRelease app:assembleAutomationDebug`, I see
locally:
$ javap -l objdir-droid/gradle/build/mobile/android/app/intermediates/classes/automation/release/org/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu\$1.class
Compiled from "ActivityStreamContextMenu.java"
class org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1 extends org.mozilla.gecko.util.UIAsyncTask$WithoutParams<java.lang.Boolean> {
final android.view.MenuItem val$bookmarkItem;
final org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu this$0;
org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1(org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu, android.os.Handler, android.view.MenuItem);
LineNumberTable:
line 103: 0
<snip>
}
$ javap -l objdir-droid/gradle/build/mobile/android/app/intermediates/classes/automation/debug/org/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu\$1.class
Compiled from "ActivityStreamContextMenu.java"
class org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1 extends org.mozilla.gecko.util.UIAsyncTask$WithoutParams<java.lang.Boolean> {
final android.view.MenuItem val$bookmarkItem;
final org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu this$0;
org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu$1(org.mozilla.gecko.home.activitystream.menu.ActivityStreamContextMenu, android.os.Handler, android.view.MenuItem);
LineNumberTable:
line 103: 0
LocalVariableTable:
Start Length Slot Name Signature
0 16 0 this Lorg/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu$1;
0 16 1 this$0 Lorg/mozilla/gecko/home/activitystream/menu/ActivityStreamContextMenu;
0 16 2 x0 Landroid/os/Handler;
<snip>
}
MozReview-Commit-ID: 3HmiGkHhowQ
--HG--
extra : rebase_source : c84d8d4b8ac813e49db0c61a30c7098ff2eae3f4
Verify that there is no hang when we use pointer actions to
perform a click that results in navigation and document unload.
MozReview-Commit-ID: EO5FClnxML5
--HG--
extra : rebase_source : e4ea787bd7ad583d8141aef9ec2bf63df33ef912
This fixes the reported hang that occurs after a pointer click
action resulting in navigation.
MozReview-Commit-ID: A9SBhextVLH
--HG--
extra : rebase_source : 7de7f06a1c05e0e52a03f1850187926aa13a4b08
Since we're uploading records atomically, order in which they're processed by the uploader
only matters if we want to do sanity checks on certain types of records. Server might still
preserve some of the order, but for our purposes here it shouldn't matter.
We'd like to ensure that we process the "mobile root" bookmark record along with other folder
records first, so that we increase our chances of avoiding making a failing network request if
that those records' payload is too large.
Sorting by bookmark type achieves this.
MozReview-Commit-ID: KrAs3zepaOk
--HG--
extra : rebase_source : 24f1d3d6aa2ee3b6777dc38abdd1e01aba5213c2
If we try to upload a record whose payload BSO field is larger than the limit specified
by the server, fail that record during BatchingUploader's processing.
Consequently, Synchronizer will fail current sync stage and advance to the next.
Previous behaviour was to essentially rely on the server to fail our POST request,
at which point we'll fail current sync stage. So in a way, this is an optimization to
avoid making network requests which we know will fail.
MozReview-Commit-ID: 5aJRRNoUuXe
--HG--
extra : rebase_source : 18920cfe7b7599be1984c53ebc0c9897c98fb7d9