By cleaning up the register set APIs very slightly we can simplify the wrappers and
make space for meaningful assertions.
Differential Revision: https://phabricator.services.mozilla.com/D59673
--HG--
extra : moz-landing-system : lando
Create a clearer distinction between the register's Encoding, which is
its hardware name, and its Code, which is a dense encoding of
bitwidth+Encoding along with a distinguished Invalid value. These
concepts exist already but it gets out of hand when the FloatRegister
uses a Code to encode the Encoding.
Make FloatRegister contain separate fields for bitwidth, encoding, and
validity, as it does on other platforms.
Add assertions on validity of inputs and on the validity of the
FloatRegister for some operations. And tidy up some, and rearrange
the file to mirror the x86 file as much as possible.
Expand the register name table so that it covers the possible range of
Code and so that we won't reference the table OOB.
Differential Revision: https://phabricator.services.mozilla.com/D59912
--HG--
extra : moz-landing-system : lando
There's no need for bilinear interpolation of DC surfaces. This
fixes a lot of the fuzziness issues when using virtual surfaces,
so it makes sense to land it now while continuing to investigate
the remaining issues.
Differential Revision: https://phabricator.services.mozilla.com/D60383
--HG--
extra : moz-landing-system : lando
Also logs JSWindowActor{Child,Parent}::Init and JSWindowActor::{Start,After}Destroy.
Differential Revision: https://phabricator.services.mozilla.com/D45346
--HG--
extra : moz-landing-system : lando
Adds GetManager on JSWindowActor (returns the associated WindowGlobalActor),
and IsInProcess on WindowGlobalActor (returns whether the actor is in process
or not).
Differential Revision: https://phabricator.services.mozilla.com/D57358
--HG--
extra : moz-landing-system : lando
Avoid frequent intermittent test failures for exceeding max-run-time by increasing
mochitest-webgl1-ext max-run-time from 30 minutes to 45 minutes. This is immediately
an issue on Windows 7 MinGW debug, but other platforms are close to the 30 minute
limit, so we may as well increase it across the board.
Differential Revision: https://phabricator.services.mozilla.com/D60420
--HG--
extra : moz-landing-system : lando
In C++ code, `DataTransfer::GetTypes()` are used for checking whether the
`DataTransfer` instance has specific type `DataTransferItem` or not. Therefore,
it does not make sense to retrieve all item types nor compare some types
looking for with the retrieved item types.
This patch adds `DataTransfer::HasType()` and `DataTransfer::HasFile()` for
the current C++ users. They don't take `CallerType` since all C++ users use
`GetTypes()` as `CallertType::System`. And they just call a corresponding
method of `DataTransferItemList`.
Then, `DataTransferItemList` methods compares given type with every items
simply.
Note that this patch moves `DataTransfer::GetTypes()` to `DataTransferItemList`
too because new methods and `GetTypes()` should be maintained at every logic
changes.
The reason why there is no `DataTransfer::HasAnyOfTypes()` method is,
`DataTransfer.h` cannot include `DataTransferItemList.h` due to their
dependency but parameter pack requires inline methods.
Differential Revision: https://phabricator.services.mozilla.com/D60387
--HG--
extra : moz-landing-system : lando
Since we don't build use exceptions nor we use STL containers that rely on this when choosing copy
from move ctors, if these are not marked with noexcept, we should disable this checker since
it brings only noise to our analysis.
Differential Revision: https://phabricator.services.mozilla.com/D60218
--HG--
extra : moz-landing-system : lando
We need to propagate `ContentParent::MarkAsDead` up to the Android java layer
so that it has a view of the state of content processes that is consistent
with the view of Gecko's content process management.
Differential Revision: https://phabricator.services.mozilla.com/D58564
--HG--
extra : moz-landing-system : lando
Now that everything in `GeckoProcessManager` runs on the XPCOM launcher thread,
`GeckoThread` should just call `GeckoProcessManager.preload()` directly.
Differential Revision: https://phabricator.services.mozilla.com/D57840
--HG--
extra : moz-landing-system : lando
The primary purpose of this patch is to convert the internal sequence of
service binding and invoking of `start` to asynchronously run on the XPCOM
launcher thread via `GeckoResult`. Because more of the code now runs on the same
thread, many of these methods no longer need to be `synchronized`.
Disconnecting via `unbind` is also modified to use the launcher thread and
`GeckoResult`.
Note that no changes have been made yet to enable multiple processes of the
same type; those changes will be made in bug 1595834.
Differential Revision: https://phabricator.services.mozilla.com/D57839
--HG--
extra : moz-landing-system : lando
This patch adds a `Dispatcher` implementation that allows us to create
`GeckoResult`s that will dispatch to the XPCOM launcher thread.
Differential Revision: https://phabricator.services.mozilla.com/D57838
--HG--
extra : moz-landing-system : lando
Since `XPCOMEventTarget` uses JNI, this patch makes it possible for consumers to
retrieve and invoke methods on one without needing to worry about whether JNI
is actually up yet.
To achieve this, we create the `IXPCOMEventTarget` interface, and observe that
both of its methods can be handled by a proxy if JNI is not ready:
* Calls to `dispatch` may be enqueued until JNI is up;
* Observe that, when JNI is not up yet, the result of `isOnCurrentThread`
can never be `true`.
Once JNI is up and the event targets have been resolved, the proxies are
replaced with the real, concrete `XPCOMEventTarget`s and are no longer used for
the remainder of the Gecko instance's lifetime.
Differential Revision: https://phabricator.services.mozilla.com/D57837
--HG--
extra : moz-landing-system : lando
By cleaning up the register set APIs very slightly we can simplify the wrappers and
make space for meaningful assertions.
Differential Revision: https://phabricator.services.mozilla.com/D59673
--HG--
extra : moz-landing-system : lando
Create a clearer distinction between the register's Encoding, which is
its hardware name, and its Code, which is a dense encoding of
bitwidth+Encoding along with a distinguished Invalid value. These
concepts exist already but it gets out of hand when the FloatRegister
uses a Code to encode the Encoding.
Make FloatRegister contain separate fields for bitwidth, encoding, and
validity, as it does on other platforms.
Add assertions on validity of inputs and on the validity of the
FloatRegister for some operations. And tidy up some, and rearrange
the file to mirror the x86 file as much as possible.
Expand the register name table so that it covers the possible range of
Code and so that we won't reference the table OOB.
Differential Revision: https://phabricator.services.mozilla.com/D59912
--HG--
extra : moz-landing-system : lando
If a script is trying to disable a compiler and that is the last compiler enabled, then throw.
Differential Revision: https://phabricator.services.mozilla.com/D60165
--HG--
extra : moz-landing-system : lando
I was poking at the missing images bug by dropping cache sizes and such and
found that we always ended up repainting some SVGs over and over. This seems to
be the cause. When we fail to insert into the cache we still end up notifying
over and over (because we forget to say aWillCache=false), so we'd end up
repainting, and failing again, etc.
This is easy to see adding some logging to
nsDisplayBackgroundImage::PaintInternal.
Any ideas as to how to add a test for it?
Differential Revision: https://phabricator.services.mozilla.com/D60372
--HG--
extra : moz-landing-system : lando
When file is dropped on `contenteditable` element, the data is `BlobImpl`
instance in e10s mode. Then, editor tries to insert asynchronously with its
`BlobReader`. However, currently, `BlobReader` does not have a reference of
`DataTransfer` object for setting `beforeinput` event and `input` event.
Therefore, when you drop file into `contenteditable` element on debug build,
you see hitting `MOZ_ASSERT` because of unexpected null `DataTransfer` object.
This patch makes it store `DataTransfer` object for both `beforeinput` event
and `input` event, and dispatch `beforeinput` event only when it hasn't been
dispatched yet (i.e., not dispatched before it's created). The case shouldn't
occur, but let's have the fallback path in release builds for avoiding
inconvenience of our users.
Differential Revision: https://phabricator.services.mozilla.com/D60238
--HG--
extra : moz-landing-system : lando
This patch introduces a new reftest (syntax ** or !* in reftest files).
This type of test renders a single input file multiple times, at a range
of different picture cache tile sizes. It then verifies that each of the
images matches (or doesn't).
This can be used to verify rasterizer accuracy when drawing primitives
with different tile sizes and/or dirty rect update strategies.
One of the included tests in this patch fails the accuracy test - the
intent is to fix this inaccuracy in a follow up patch and then be able to
mark it pixel exact.
Differential Revision: https://phabricator.services.mozilla.com/D60185
--HG--
extra : moz-landing-system : lando
Fetch, configure, and run node for Android on the test host, just like Linux tests do.
Make the node/HTTP/2 environment variables available to the tests on the device, and
use adb port forwarding to connect sockets. Finally, enable tests skipped for node.
Differential Revision: https://phabricator.services.mozilla.com/D60204
--HG--
extra : moz-landing-system : lando
It turns into a DOMException named 'TypeError' in the bindings, not into an actual TypeError.
Differential Revision: https://phabricator.services.mozilla.com/D60215
--HG--
extra : moz-landing-system : lando