We can use this telemetry to track the statistics of using
RemoteSettings to serve Safe Browsing data.
The can help us understand if we can roll out this feature to more users.
Depends on D135990
Differential Revision: https://phabricator.services.mozilla.com/D136107
This patch implements UrlClassifierRemoteSettingsService to get SafeBrowsing data (protocol v2)
from RemoteSettings instead of from the Shavar server. This is only used
by data provided by Mozilla.
To distinguish if the data should be coming from RemoteSettings or
Shavar, We added a custom scheme "moz-sbrs" to denote that the data should be
retrieved from Remote Setting. This is done by changing the value of pref
"browser.safebrowsing.provider.mozilla.updateURL" to something like
"moz-sbrf://tracking-protection-list". (Note that the hostname is not
used at this point).
The goal of this patch is to make the new architecture compatible with
the original Safe Browsing design. So we don't notify Safe Browsing
there is new data available (via "sync" event of RemoteSettings). We still follow
how Safe Browsing periodically checks whether there is a newer version of list.
Note.
This patch changes the flow comparing with how we usualy receive SafeBrowsing response from Shavar.
In Shavar case, the list data response usually comes with
"n:21600\ni:listname1\nu:redirectURL1\ni:listname2\nu:redirectURL2 ..." first.
And then we fetch the data again from the redirectURL for each list.
But in the current implementation, responses don't contain
redirectURL anymore (since we already have the data). So the mocked response
will contain all the data needed in one response.
For example:
"n:21600\ni:listname1\n:chunkdata1\ni:listname2\n:chunkdata2...".
Differential Revision: https://phabricator.services.mozilla.com/D135989
Previously, if we got a test failure and an error during teardown, we'd end up with
multiple results for the same test. This just picks the final result for the test.
Differential Revision: https://phabricator.services.mozilla.com/D151007
Inspired by emilio's suggestion in the shader module API patch. This tries to be the most straightforward way to go from the strings coming from IPC to the ones consumed by wgpu.
Differential Revision: https://phabricator.services.mozilla.com/D151024
This patch is a lot of plumbing for not that much functionality. The goal is to align CreateShaderModule's error reporting with the spec.
Creating a shader module is now a dedicated async IPDL message returning the compilation info so that it can be exposed as a promise by the WebGPU API.
Differential Revision: https://phabricator.services.mozilla.com/D146817
After Bug 1247260, the allow-list code was fixed to handle n_buckets == 100
which means the allowlist entries are no longer needed for a number of GC
metrics.
Depends on D150652
Differential Revision: https://phabricator.services.mozilla.com/D150653
Many SpiderMonkey GC telemetry metrics are old enough that the bug_numbers
metadata was not recorded in tree, so fix that finally.
Depends on D150651
Differential Revision: https://phabricator.services.mozilla.com/D150652
In the browser toolbox window, we include common.css, but we don't
apply the theme-dark/theme-light classes, so we end up overriding the
color-scheme to light.
Instead, only override color-scheme for theme-light/theme-dark, so that
context menus and so have the right appearance.
Differential Revision: https://phabricator.services.mozilla.com/D151131
When Surfaces/SurfaceTextures are allocated they are given a handle,
which is a monotonically increasing 32-bit integer. To render
Surfaces, we typically pass the Surface handle to the compositor,
which then looks it up in a map to find the corresponding
SurfaceTexture.
Following a GPU process restart, content may be left with stale
handles referencing SurfaceTextures which no longer exist. Once new
SurfaceTextures are allocated, these stale handles may reference new
SurfaceTextures with no relation to the old handle. This can lead to
rendering the wrong texture. Additionally, we may crash when
allocating "sync" SurfaceTextures, as the previous sync texture for a
certain handle may not have been released yet.
To fix this, this patch combines the existing handle with a new ID
uniquely identifying the process in which the SurfaceTexture was
allocated (or 0 for the parent process). We use a monotonically
increasing value rather than the pid to guard against the new GPU
process possibly having the same pid as the previous instance. We
combine these two 32-bit integers and use the resulting 64-bit integer
as the Surface handle.
Differential Revision: https://phabricator.services.mozilla.com/D150963
The Wasm-specific fields are moved from `SharedArrayRawBuffer` into a new derived class,
`WasmSharedArrayRawBuffer`. This is similar to how non-shared buffers use `WasmArrayRawBuffer`.
The non-Wasm allocation code now uses `calloc` instead of `mmap`. This is also more like
how non-shared buffers work.
These changes make the non-Wasm SABs a lot more lightweight. This will help fix bug 1777231
and similar issues.
Differential Revision: https://phabricator.services.mozilla.com/D151010
Browsers shouldn't insert `<div>` and `<p>` elements into inline elements such
as `<span>` even when it's `display` value creates a block format context since
it's invalid structure from point of view of HTML. However, some browsers do
it. Therefore, this test should make them fail.
The reason why this patch touches `editor-test-utils.js` is, it scans the
following `<script>` element's text with a bug. So the change makes it does
not scan outside the editing host.
Differential Revision: https://phabricator.services.mozilla.com/D150991
The associated PresShell of the root doc can be used for retrieving the
SessionAccessibility. If the PresShell is about to go away, we should
unregister all the accessibles.
Differential Revision: https://phabricator.services.mozilla.com/D150661
