The flag of force update is only for fallback items. Fallback items can't share the images with other items.
So I replace 'aForceUpdate' with 'aFallback' and remove some unnecessary checks.
MozReview-Commit-ID: Dcu95FZXlUz
--HG--
extra : rebase_source : 1ec96e0b5d39cc5760b4b5490c5ca9ccbc1933c6
We hit assertion which were added by bug 1414713. That tells us an ancient bug.
There is comment which claims that we should move all list items in the right
list node to left list node if the list nodes should be merged. However, this
has never been done actually since 2002. The code tried to move *some* list
items in the right list node to the list list node. However, retrieving first
list item at an offset almost always failed because the offset variable has
never been initialized.
If we believe the comment, we should move all children of the right list node
to the left list node. However, until we get a testcase to reach this case,
we should keep current behavior, i.e., do nothing, for unexpected regression.
MozReview-Commit-ID: 1r81q1m44oW
--HG--
extra : rebase_source : fc02520f76440d5900fec0517aa6bcd188e1a14f
This brings bitflags 0.9.1 to clap, which removes bitflags 0.7.0.
Source-Repo: https://github.com/servo/servo
Source-Revision: 4d5ff42751ed25ebdc3f298d89acb7eaf58572e5
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 36bb86929c90eadca1f49981d472a96bbf2d9c1a
Remove GeckoLayerClient.java since it's no longer used, and update
auto-generated JNI bindings. r=me for trivial patch.
MozReview-Commit-ID: CiNPLLkh3VJ
--HG--
extra : rebase_source : 0cddae4f8914dd6f6a0631a7e69701828476f2b8
Use LayerSession::Compositor or NativePanZoomController to call back
into Java from nsWindow.
MozReview-Commit-ID: 9JUKAE5XQK1
--HG--
extra : rebase_source : 9d6861b9d641e6abb6b6f94f5f9c4b3661ff071c
Move the GeckoLayerClient JNI callbacks to LayerSession.Compositor. Move
the rest of the viewport code to LayerView. Finally, move the input
event synthesis code to NativePanZoomController.
MozReview-Commit-ID: 1FEAM43KcwL
--HG--
extra : rebase_source : af2ded170a79f13afbb1f690ae466e77c7145ff6
Instead of sending an event through the global EventDispatcher in
GeckoLayerClient, switch to using the per-GeckoView EventDispatcher in
GeckoInputConnection, to handle scroll-to-focused-input-on-resize. This
lets us implement the same functionality for standalone GeckoView.
The patch also fixes some small bugs including unregistering
not-registered events, not scrolling when switching input focus, and
inadvertent scrolling when not showing the keyboard.
MozReview-Commit-ID: 20OZP9dMXtI
--HG--
extra : rebase_source : d9dee0fd8b3d01147b8b2eda5154c380d0f167dd
Patch gets rid of `LayerView.getMatrixForLayerRectToViewRect`, and just
uses `LayerView.getZoomFactor` directly when calculating the matrix in
GeckoInputConnection. This also lets us avoid the `isCompositorReady`
call on a non-UI thread. To get the correct offset, we need the screen
bounds from Gecko, so it's passed to Java as the first element in the
rect array. Using bounds from Gecko lets us avoid having to deal with
things like the dynamic toolbar animator ourselves.
MozReview-Commit-ID: 6I61SZGyQyO
--HG--
extra : rebase_source : d576fb7ef9a42de10b14db662e5c4833f16f6312
- This makes all of them return an enum, quite similar to rust.
- This makes all of them derive from a single implementation of an
integer comparison.
- This implements that integer comparison in terms of simple operations,
rather than "smart" computation, which turns out to allow compilers
to do better optimizations.
See https://blogs.msdn.microsoft.com/oldnewthing/20171117-00/?p=97416
--HG--
extra : rebase_source : 89710d7954f445d43e6da55aaf171b1f57dce5fc
This PR implements cancellation for fetch, and uses it for XHR. This means that fetch clients can now send a message to the fetch task asking for the network request to be aborted.
Previously, clients like XHR had abort functionality but would implement it by simply ignoring future messages from the network task; and would not actually cancel the network fetch.
Source-Repo: https://github.com/servo/servo
Source-Revision: 00b3612fe9045f1cb6ba6c89ba7801642a6fa2c9
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 4ab32f3b8477c9f2157490eeeb76683e5a5d98f7
This version of the patch hopefully causes fewer performance regressions.
It might be good to apply this and catch some more assertions.
--HG--
extra : rebase_source : b8674308d581bed4baf6f64a9dd23f2cf995028b
Previously we used the MozPromise interface for calling an async-message over
IPC with a reply. Unfortunately, MozPromise processes the reply asynchronously,
potentially allowing other IPC messages to be processed before the `->Then`
callback is processed.
In the original CreateWindow patch I tried to work around this by setting the
target of the `->Then` callback to be StableStateEventTarget. This worked,
however as it isn't safe to run scripts etc. in the stable state, we instead
tried to exit the nested event loop immediately after the runnable ran, and then
performed processing of the reply.
Unfortunately, this bug exposed a problem with that design. If we have multiple
nested event loops then we cannot guarantee that we'll exit the nested event
loop immediately after recieving the `->Then` callback, which meant that we
could still process other IPC messages before we processed the CreateWindow
reply.
The fix to this was to add a new API to allow passing callbacks directly into
IPC send methods, ensure that those callbacks are called in IPC order, and
fully process the CreateWindow reply in the callback, rather than waiting for
the nested event loop to exit.
MozReview-Commit-ID: D6zaMJRxhXd
Currently if you write an async IPDL method which has a return value, we expose
a SendXXX method which returns a MozPromise. This MozPromise can then be
->Then-ed to run code when it is resolved or rejected.
Unfortunately, using this API loses ordering guarantees which IPDL provides.
MozPromise::Then takes an event target, which the resolve runnable is dispatched
to. This means that the resolve callback's code doesn't have any ordering
guarantees relative to the processing of other IPC messages coming over the same
protocol.
This adds a new overload to SendXXX with two additional arguments, a lambda
callback which is called if the call succeeds, and a lambda callback which is
called if the call fails. These will be called in order with other IPC messages
sent over the same protocol.
MozReview-Commit-ID: FZHJJaSDoZy
The only time menucaptions are created are for optgroups, and they
always get instantiated as menucaption-inmenulist. Flatten the
inheritance here to get rid of a binding.
MozReview-Commit-ID: KWzor0QDdma
--HG--
extra : rebase_source : a87ea48a4c6815ec6bdb53925283a9c1ed89f5a2
Pass in the flag names for Tab:OpenUri so we don't have to worry about
synchronizing the flags in Java with ones in C++. r=me for trivial
patch.
MozReview-Commit-ID: BowjLV1s7nT
This restriction was put in place back when we automatically added
QueryInterface to all rootmost non-abstract interfaces. At the time, we needed
to make sure it did NOT end up on EventTarget, because then webidl quickstubs
would replace the QI impl on non-webidl EventTargets with the WebIDL one, which
would not work for them.
Since then, we have removed WebIDL quickstubs and we now explicitly list which
interfaces get QueryInterface, so this check is no longer needed.
MozReview-Commit-ID: 5B13ymdyLp3
The difference between nsDocument::IsWebAnimationsEnabled and
nsContentUtils::AnimationsAPICoreEnabled is that the former checks the caller
type and treats the preference as set for system callers which is particularly
needed for enabling things like the getProperties() API for DevTools etc.
Generally in API-facing call sites we have a JS context / CallerType and so we
want to distinguish between system callers and non-system callers. However, for
a few internal uses--specifically filling-in missing keyframes--we don't care
about the caller type and always follow the pref setting.
That may or not be quite what we want, but this patch doesn't change that except
for one call site: KeyframeUtils::GetKeyframesFromObject. This patch changes
GetKeyframesFromObject from *not* checking the caller type to checking the
caller type. That seems to be the correct behavior here since this is called
from KeyframeEffectReadOnly::SetKeyframes(JSContext*, JS::Handle<JSObject*>,
ErrorResult&) (i.e. a JS API-facing call site) where we *should* enable the full
API when the caller is chrome code.
MozReview-Commit-ID: FQJBk3zytwd
--HG--
extra : rebase_source : 577bca1e551e39fecfab309f64c993eba110337f
As I discussed in #19277, I'd like to change the implementation for `From` of font variant to use macro, `impl_gecko_keyword_conversions`.
r? @emilio
---
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
- [x] These changes update `From` impl for font variant to use macro `impl_gecko_keyword_conversions`.
- [x] These changes do not require tests
Source-Repo: https://github.com/servo/servo
Source-Revision: 63bd783c55ab0c0f9abb1a8fa07f20932c77b764
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 3b84f9e94c75f791a42835a47e0beb989f628bcf
