We might want to look into this further and see if it can be supported, but for now at least
the safest option is to disable any attempt by Gecko to render such glyphs.
(Actually, in some cases they may work anyhow, if they're natively supported by the system font
rasterizer we're using; I'm seeing this on current macOS thanks to Core Text. Maybe at some point
we can switch off our SVG-glyph code altogether and just rely on the platform.)
Differential Revision: https://phabricator.services.mozilla.com/D146052
Persist dictionary preference in document content language field for mail editors so multiple dictionary selection can persist.
Differential Revision: https://phabricator.services.mozilla.com/D144935
The scroll snap spec defines the concepts [1]. There are three type of scroll
operations. 1) intended end position, 2) intended direction and end position
and 3) intended direction.
Basically our existing ScrollUnits types correspond;
1) DEVICE_PIXELS, WHOLE => intended end position
2) PAGES => intended direction and end position
3) LINES => intended direction
There are two exceptions in the `intended direction and end position` case,
scrollBy() and fling gestures (on Linux). They were defined as scroll operations
with DEVICE_PIXELS unit, but the spec cleary says they are `intended direction
and end position` operations.
Note that we will also use this information for scroll-snap-stop property since
the properly will only have effects on both 2) and 3) cases.
[1] https://drafts.csswg.org/css-scroll-snap/#scroll-types
Depends on D145190
Differential Revision: https://phabricator.services.mozilla.com/D145191
This will still prevent them from accessing stuff (.length will be
undefined, etc), but seems better than unexpectedly throwing. This fixes
the issue at hand at least.
With this patch, we reject length accesses here:
https://searchfox.org/mozilla-central/rev/86c98c486f03b598d0f80356b69163fd400ec8aa/js/xpconnect/wrappers/XrayWrapper.cpp#229-233
Your call on whether this patch is enough as-is, or more work is needed.
Also your call on whether if more work is needed that needs to happen on
this bug or somewhere else.
I'm not sure what we'd need to do to support this more "properly",
presumably we'd need to add special XRay support to
ObservableArrayProxyHandler or so? Pointers (or patches of course ;))
welcome.
Also unsure about the setter situation, I _think_ it's fine not to throw
given the code I read, but please sanity-check.
Differential Revision: https://phabricator.services.mozilla.com/D145045
Since Bug 1732739, "session change handling of window occlusion on Windows" is enabled until early beta. And no regression was reported. Then it seems OK to enable it until release.
Differential Revision: https://phabricator.services.mozilla.com/D145193
Using static preferences in PSM will eventually allow NSS to be initialized on
a background thread instead of blocking the main thread.
Depends on D145152
Differential Revision: https://phabricator.services.mozilla.com/D145390
Using static preferences in PSM will eventually allow NSS to be initialized on
a background thread instead of blocking the main thread.
Depends on D145151
Differential Revision: https://phabricator.services.mozilla.com/D145152
Using static preferences in PSM will eventually allow NSS to be initialized on
a background thread instead of blocking the main thread.
Depends on D145150
Differential Revision: https://phabricator.services.mozilla.com/D145151
Using static preferences in PSM will eventually allow NSS to be initialized on
a background thread instead of blocking the main thread.
Differential Revision: https://phabricator.services.mozilla.com/D145150
Bug 1333990 added the ability to have multiple parser blockers at the same
time, so we no longer need to guard against recursively blocking. What's more,
if we do, and skip calling `BlockParser` while it's blocked for another reason,
we still call `UnblockParser` when we receive script data, at which point we
crash.
This patch moves the XHTML parser's behavior closer in line with the HTML
parser's.
The only way I've seen this manifest as a bug is when we have an XHTML
document with a top-level <script> element, and an extension with content
scripts that cause us to block parsing when we see that top-level element and
need to wait for them to compile.
Differential Revision: https://phabricator.services.mozilla.com/D145513
In bug 1762424 we introduced a compositing path using SurfaceControl
to work around an issue on Android 12 where the app would freeze when
attempting to recover from a GPU process crash. However, this caused
bug 1767128. Until we have a proper solution to that, we should
disable the SurfaceControl functionality.
This means on Android 12 the browser will be once again be unable to
recover from a GPU process crash. However, as part of bug 1762424 we
made it so the parent process crashes in this situation rather than
freezing, meaning Android 12 users will be no worse off than having
the GPU process disabled.
Differential Revision: https://phabricator.services.mozilla.com/D146114
In the previous implementation, FetchEvent.preloadResponse is resolved when the response fetching finishes.
However, ServiceWorker responding letency could be increased since waiting for preloadResponse finishes.
The patch resolves FetchEvent.preloadResponse earlier when the response is available.
The basic idea is to resolve the preload response when FetchInstance::OnResponseAvailableInternal() is called.
Then propagating the response from the parent process main thread to the content process worker thread. This is achieved by IPC PFetchEventOp::Send/RecvPreloadResponse -> PFetchEventOpProxy::Send/RecvPreloadResponse.
Since we can only get the response's ResourceTiming when FetchInstance::OnResponseEnd() is called. This patch introduces a new IPC method to propagate the ResourceTiming information from the parent process main thread to the content process worker thread.
PFetchEventOp::Send/RecvPreloadResponseEnd -> PFetchEventOpProxy->Send/RecvPreloadResponseEnd.
The tricky of this patch is we must extend the life cycle of FetchEventOp object if preloadResponse is set into FetchEvent.
That because ServiceWorker could resolve FetchEvent.respondWith() by using FetchEvent.preloadResponse.
In that case, FetchEventOp will get into a finish state and try to call FetchEventOpProxyChild::Senddelete with the operation result.
However, the ResponseEnd could not be called at the moment, and we need to wait for the corresponding timing information and its end reason.
To extend the life cycle of FetchEventOp, this patch cached the operation result while we get FetchEventOp::Callback is called. Then call FetchEventOpProxyChile::Senddelete() in FetchEventOpProxyChild::RecvPreloadResponseEnd() to close IPC. Or Senddelete() will be called while ActorDestroy() caused by shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D145338
The test failing intermittently on test-verify jobs seems to be only the one that covers the newly added
Glean timespan metric named "extensions.startupCacheLoadTime".
Given that it seems to be only failing in test-verify jobs, and with the Glean metric set to a numeric value as expected
just not always a non-zero value as the test expectes, I suspect it may be because the startupCache is technically
empty or only including a pretty small amount data and so it may be able to be loaded so fast that the resulting
value is 0 milliseconds.
I'm unable to reproduce the same locally even when running the test locally using --verify, and so this patch
is actually relaxing the failing assertion to only check that the Glean metric value is numeric and the
mirror scalar is set to the exact same value, and in addition to that the test is not reseting the FOG data
and assert that the Glean metric is initially undefined until we expect it to be collected and set to a numeric value.
Differential Revision: https://phabricator.services.mozilla.com/D145904
This means as of this patch
- All mp4 specific audio codecs are handled. There's some more we could
theoretically get, stuff like ALAC, but it's not clear to me we handle them
following demuxing. I've left a catch all in the mp4 demuxing code just in
case.
- We no longer pack the codec-delay/preskip at the head of the opus binary blob.
This means that the binary blob is just the opus header data and the container
specific preskip has its own member. My hope is this is clearer and easier to
understand. It also means we can drop some of the code we had for packing the
delay/preskip into a binary blob.
Differential Revision: https://phabricator.services.mozilla.com/D145521
This should be the last change needed for a number of our platform specific
decoders to be switched entirely over to the new variant types. As such, we can
move them from the lenient `ForceGetAudioCodecSpecificBlob` and to
`GetAudioCodecSpecificBlob` to enforce handling of codecs that don't use
trivially blob like codec specific data.
Differential Revision: https://phabricator.services.mozilla.com/D145520
We don't store Wave specific info, but this means that we have a struct in place
if we ever want to add such data + gives us more typing info for codec specific
data.
Differential Revision: https://phabricator.services.mozilla.com/D145519
This switches the mp3 codec specific handling from using a binary blob to
instead use a typed structure.
Depends on D134729
Differential Revision: https://phabricator.services.mozilla.com/D134730
Jonathan Watt
Jonathan Kew
Norisz Fay
Joel Maher
Nicolas Silva
Bogdan Szekely
Dão Gottwald
ui.sayuree
Martin Giger
Henrik Skupin
Jan de Mooij
Hiroyuki Ikezoe
Emilio Cobos Álvarez
Alex Finder
Mozilla Releng Treescript
sotaro
Kelsey Gilbert
criss
Alexandre Lissy
Eitan Isaacson
Dana Keeler
Kris Maglione
Morgan Reschenberg
Razvan Cojocaru
Jamie Nicol
Eden Chuang
Luca Greco
Bryce Seager van Dyk