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
When we report errors generated by async API operations, they are currently
not tied to any relevant extension source location. Instead, the locations in
the error reports point to the location in the framework code which reported
the error, which makes things extremely difficult to diagnose.
This change saves the extension caller location at the beginning of async API
operations, and adds it to the error reports genearted by that operation. This
should give extension developers a useful starting point for debugging them.
MozReview-Commit-ID: AkknkKEosFt
--HG--
extra : rebase_source : 598a232430a36f15ffd1bd7fa8b8ee9733927c12
There's no standard way to create a JS error with full stack and location
information from a saved stack. Since we need this functionality in order to
reject promises with useful Error objects, this patch adds a simple helper to
make that possible.
MozReview-Commit-ID: FyGuo4UjfsQ
--HG--
extra : rebase_source : 65ef11c56f23e04ea5eeb87b972bfc8e4867fdd2
Building on top of part 1, we need a way to link a saved caller location to a
reported error message. This change allows us to pass a stack to `reportError`
when called with a string.
This part was written before part 3, and could probably be removed in favor of
using createError in every call. But this method also has the advantage of
being more consise and somewhate more efficient.
MozReview-Commit-ID: 39jfCg9AerY
--HG--
extra : rebase_source : cc5bf96e11e861a81e04167c2bfa4828e5224c3e
Combing the two clips as-is should always be correct, and since they're frequently identical, we can usually make IntersectClip a no-op.
MozReview-Commit-ID: 3xxMyZjwPvJ
--HG--
extra : rebase_source : 8ae4891b88d7229a685771c13a98d3578ffb8767
The display items are almost certainly gone from the cache at this point, so dereferencing them can take a while.
This moves the DisplayItemData lookup, and the IsReused/HasMergedFrames checks into the ProcessDisplayItems pass (where we already use the items), and then just uses the AssignedDisplayItem entry for everything.
MozReview-Commit-ID: 8udcE0bmyF3
--HG--
extra : rebase_source : 594513ef2c7d68b42e56b0536f8f6372fa9de90f
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