Given that we have a SegmentedVector of nsCOMPtrs, it's probably worth
avoiding copying it.
MozReview-Commit-ID: GHyfVLrdnlQ
--HG--
extra : rebase_source : 75df805d8b2df32b76ee77b95ced625f20331744
Gecko only ever had de-zippering for DelayNode.delayTime. It has been decided in
[0] to remove all de-zippering, for consistency.
[0]: https://github.com/WebAudio/web-audio-api/issues/76#issuecomment-107679878
MozReview-Commit-ID: FK9Erwxth05
--HG--
extra : rebase_source : caccac28456191e68c980b12159ed310ce18e149
GetStyleContext can flush. As such, that flush can kill the pres shell, and the
return value could be null. I have no idea why that code was asserting it didn't
happen, but that assert is completely bogus.
Throw instead, just like GetFontParentStyleContext used to do for Gecko.
MozReview-Commit-ID: 5RxDratKumZ
--HG--
extra : rebase_source : 9ffb1f58888504d92915ecd4254847ae2e3f053b
The key here is that we only filter longhands if the shorthand is accessible to
content and vice-versa. This prevents the bug that prevented me to land this
patch before, which was us not expanding properly chrome-only shorthands.
Source-Repo: https://github.com/servo/servo
Source-Revision: a0be3a7fae2730bfef52db94db7f3af14b60be67
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 2afb50b62cab334fcec0cdcccd793abca8fdb3ec
This is its only use.
Source-Repo: https://github.com/servo/servo
Source-Revision: 8471011e6b6bd72db68ec9ae21df58ab09f2f6d8
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 4407223da1f18648537ad75a602434999ce3ee2f
Because of the storage::Service's connection list, it's possible for the
refcount for a non-main-thread Connection to experience transient increases
and decreases at any time, dooming logic in Release() that assumes the
refcount isn't changing.
This patch adopts use of an Atomic<bool> so that we execute cleanup logic
exactly once when the refcount falls to 1 at some point. Care is taken to
ensure that the failsafe Close() occurs on the correct thread.
SpinningSynchronousClose() is still dangerous and can still potentially
nest deeply on the stack. If we see instances of that in the future, we
may want to adopt use of PushEventQueue so that we can avoid re-entrancy
in our event loop spinning.
MozReview-Commit-ID: A835HBec50H
--HG--
extra : rebase_source : af2f63e8f050b7a0275e39f73e59133958e29f19
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes fix#19901
Source-Repo: https://github.com/servo/servo
Source-Revision: 23e95906347c4b6d0d1ccd1ce12ff5206c349a9a
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 806d322a34be21e05a94e6a7cadbfb78cb0e8b9d
To match the WebDriver specification error code names, this patch
renames the NoAlertOpenError type to NoSuchAlertError.
Its string error code (the status property) is still correct.
MozReview-Commit-ID: DhWz1tn6DsT
--HG--
extra : rebase_source : dd45387a5869a8df53f20baafe1c683c3af32b25
We currently reduce the precision of timestamps emitted by console.time
in the main context, but not in a Worker. Because web page content cannot
read the content of messages emitted to the console (right?), we don't
actually need to reduce the precision of this data.
MozReview-Commit-ID: EfpIEICy0tX
--HG--
extra : rebase_source : 9516943b11dd7d4ccbcf38a80a981a6fb4662c40
This drops the tests for Marionette protocol level 2. Protocol levels
below 2 were removed some time ago:
https://bugzilla.mozilla.org/show_bug.cgi?id=1409030
MozReview-Commit-ID: GsrdeldnoNH
--HG--
extra : rebase_source : 522d7a9c71545693ca2b662d0a6c715df0f2cd24
To match the WebDriver specification error code names, this patch
renames the NoAlertOpenError type to NoSuchAlertError.
Its string error code (the status property) is still correct.
MozReview-Commit-ID: DhWz1tn6DsT
--HG--
extra : rebase_source : b3da69e566f190c1a016dad7fccf655966779ab1
If Marionette throws inside try...catch block that spawns the TCP
listener, we fail to reset the altered recommended preferences to
their original state, leaving a possibility of tainting the profile.
By calling the uninitialisation code when an error is thrown we
ensure all relevant state gets reset.
MozReview-Commit-ID: XiiIEFMZQY
--HG--
extra : rebase_source : 1a38e446931c916af7f37ffc928683df47f0bba4
Marionette was previously uninitialised when xpcom-shutdown fired.
This may be too late to reset preferences and other state related
to the browser.
This patch moves Marionette to run uninitialisation code on
xpcom-will-shutdown.
MozReview-Commit-ID: 3ytX2k2rrOp
--HG--
extra : rebase_source : 6b9918515b48b2d1166cc985c5d5aeeb82937db0
Setting the MOZ_MARIONETTE environment variable is not a task that
naturally belongs to the TCP listener. This patch moves it to the
Marionette XPCOM component.
MozReview-Commit-ID: 7896Sv91wFy
--HG--
extra : rebase_source : a43335d289c2568f60be3ecc5a9491b2bee27fe9
Setting the recommended preferences is not a task specific to the
TCP listener. It makes more sense to set these in the Marionette
XPCOM component where we manage the Marionette lifetime.
MozReview-Commit-ID: G2RuLhKnX9X
--HG--
extra : rebase_source : 7b3651a682bf86ffe6435dfc35bfce980601aedb
