This is a short term fix. Long term fix needs to be done by Bug 1860958.
Presenting WebGPU without readback needs a way to destroy Texture. Then Texture::ForceDestroy() is added for it.
Differential Revision: https://phabricator.services.mozilla.com/D191829
There are two equals signs when there should be just one. This was made more obvious after applying Prettier v3's auto formatting.
Differential Revision: https://phabricator.services.mozilla.com/D190411
As this is based on DebuggerNotificationObserver, this would only work
for events currently supported by this interface.
For example, we would miss network events which aren't suppported yet.
I kept this as an option for the base tracer class in order to be able to have a fine control
on its output, but kept things simple in the Debugger UI and made this be enabled by default.
Differential Revision: https://phabricator.services.mozilla.com/D185934
This is simpler and closer to how a regular image would behave.
Move dropmarker styles to xul.css, and remove the dropmarker custom
element that just wraps an <image>.
Also remove the button[type="disclosure"] rules since they're unused
while at it (and macOS has no styles for that).
Depends on D191736
Differential Revision: https://phabricator.services.mozilla.com/D191739
Before bug 1860385, we used the 16px image (because the list-style-image
was set on the icon, and in-content/common-shared.css rule didn't
override it). But the dropmarker was still 12px wide, and the 4px
margin-inline-end of common-shared.css did fix it.
That's pretty messy. Remove the dropmarker sizes so that the dropmarker
takes the right size based on the dropmarker icon. That means that if
somebody wants a 16px icon they can just override list-style-image on
the dropmarker.
Use the 12px dropmarker arrow since that's what we also do for <select>,
and seems to be the general intention.
This also avoids the need of manually positioning it on windows to be
centered-ish vertically.
Differential Revision: https://phabricator.services.mozilla.com/D191736
`unit` is not supported on `string`. This was previously allowed
erroneously, but will soon break the build (and is breaking downstream
tools at the moment)
Differential Revision: https://phabricator.services.mozilla.com/D191720
This test is a test case where a scroll anchor adjustment happens while an
async scroll animation is running. Without the dumped metrics it's hard to tell
what's wrong. In fact the test fails if we did use `ScrollUpdateType::Absolute`
for scroll anchoring
Differential Revision: https://phabricator.services.mozilla.com/D190887
By selecting an adapter with the same LUID as the compositor device, the same adapter is selected as the compositor device used by WebRender.
Differential Revision: https://phabricator.services.mozilla.com/D190905
Wikipedia suggestions from Rust don't have an `advertiser` property, unlike
suggestions from the JS backend [1]. That causes an exception to be thrown when
`UrlbarProviderQuickSuggest` tries to convert the advertister to lower case for
telemetry. The result is that telemetry isn't properly recorded for Rust
Wikipedia suggestions, and anything that happens after telemetry is supposed to
be recorded doesn't actually happen, which means dismissals aren't handled.
I fixed this by adding `advertiser` to Rust Wikipedia suggestions, and I
modified the telemetry tests for sponsored and nonsponsored suggestions so they
also run with Rust enabled. This tests the code path where the error was thrown.
Running the telemetry tests with Rust enabled revealed some more problems that I
also fixed:
* Rust Wikipedia suggestions also don't have `iab_category`, so I added that to
them too.
* `_assertGleanPing()` in head.js wasn't checking a few properties, so I added
them. Now it checks them all.
* URLs in the Glean ping are declared with type `url`, which means our tests
need to use valid URLs in their dummy data. The mock Merino server and some
related tests are using invalid URL values like `"url"`, so I fixed that.
[1] The suggestions data in remote settings does include an `advertiser`, so
it's possible to consider this a bug in the Rust implementation, but IMO it
makes sense for nonsponsored suggestions to lack an advertiser, and it's always
set to `"Wikipedia"` anyway.
Differential Revision: https://phabricator.services.mozilla.com/D191795
This allows for disabling WebGL's use of GL_KHR_no_error, rather than the default of enabled.
Use snake_case so that searching for KHR_no_error finds this more
easily.
Differential Revision: https://phabricator.services.mozilla.com/D188781
- Pass analysis status as data to display not enough reviews and page not supported messages.
- Throws errors when we get an response that there was an issue from the Shopping Status and Analyze APIs.
- Add integration tests for setting sidebar status based on analysis status.
Differential Revision: https://phabricator.services.mozilla.com/D190366
Our EME system works like this,
First, the content process stores some cached capabilities for different
key systems, which tells what codecs they support, and whether hw
decryption works or not.
Then in the content process, we would compare those capabilies to the
one that website requests by using EME API, to see if that is any
matching.
What this patch is going to do is, if website uses `com.widevine.alpha`
with hardware decryption request, then we would check those experiment
key system to see if they support (because they are used for hardware
decryption only).
Therefore, we would be able to support two cases for hardware
decryption, (1) use experiment key system explicitly (2) use normal key
system but requests an explicit robustness for hardware decryption [1].
[1] Example test page (you can add robustness on setting)
https://integration.widevine.com/player
Differential Revision: https://phabricator.services.mozilla.com/D190639
This allows EME API to recognize those new Widevine key system in order
to start checking whether they are supported or not.
Differential Revision: https://phabricator.services.mozilla.com/D190635
Our EME system works like this,
First, the content process stores some cached capabilities for different
key systems, which tells what codecs they support, and whether hw
decryption works or not.
Then in the content process, we would compare those capabilies to the
one that website requests by using EME API, to see if that is any
matching.
What this patch is going to do is, if website uses `com.widevine.alpha`
with hardware decryption request, then we would check those experiment
key system to see if they support (because they are used for hardware
decryption only).
Therefore, we would be able to support two cases for hardware
decryption, (1) use experiment key system explicitly (2) use normal key
system but requests an explicit robustness for hardware decryption [1].
[1] Example test page (you can add robustness on setting)
https://integration.widevine.com/player
Differential Revision: https://phabricator.services.mozilla.com/D190639
This allows EME API to recognize those new Widevine key system in order
to start checking whether they are supported or not.
Differential Revision: https://phabricator.services.mozilla.com/D190635
This change lets NativeLayerRootCA::Representation::Commit be the only
point where sublayers are added and removed from the root CALayer.
Differential Revision: https://phabricator.services.mozilla.com/D191673
Also, avoid calling SendFindImageText() on unsupported platforms, so that
test_image_recognition_unsupported.html will pass.
Differential Revision: https://phabricator.services.mozilla.com/D191678