Use LayoutDevice units for most these things, since it's what they are:
ScreenIntSize(presContext->AppUnitsToDevPixels(size.width), ...
Is clearly a lie :)
Differential Revision: https://phabricator.services.mozilla.com/D228586
This also stops sharing browser.profiles.enabled and toolkit.profiles.storeID. In the first case
I want to minimise any risk of this preference getting set to false by accident because then a
user loses all of their profiles. In the latter case there is no point storing it in the database,
we already have a backup mechanism for it and if we have lost the storeID we can't load the database
anyway.
Differential Revision: https://phabricator.services.mozilla.com/D228174
- Add a new deep link for opening the share sheet that supports configuring the share text, subject, title, and URL via query parameters.
- Add an "OPEN_SHARE_SHEET" action for this deep link for remote message configuration via Nimbus and ensure the query parameters above can be remotely configured via action params.
______________
The follow examples were generated using the action params:
- url = "https://example.com"
- title = "TestTitle"
- subject = "TestSubject"
- text = "TestText"
Text message
{F9006160}
Email message
{F9006161}
Share screen with custom title
{F9006162}
Differential Revision: https://phabricator.services.mozilla.com/D227959
Based on the ubuntu1804 test image, with the following changes:
- update packages list
- avoid failing gnome session start due to missing gsd-power, which
requires logind
- remove /run/systemd/seats (created at systemd package install), to
avoid gnome-shell thinking it needs to talk to logind
- stop installing node via tooltool, it should be grabbed from the
toolchain task when/if necessary
- stop installing psutil via pip, we can use the ubuntu package instead
- remove setcap of gnome-keyring-daemon binary; it's no longer installed
with the IPC_LOCK capability in newer distro versions
- remove /etc/xdg/autostart/gnome-software-service.desktop (unused)
Differential Revision: https://phabricator.services.mozilla.com/D226477
This patch includes 4 main changes
1. Created a guard in `removeLaunchOnLogin` with `getLaunchOnLoginApproved` to make sure the setting is not already disabled before removing the registry key made by Firefox.
2. Change the method doc for `removeLaunchOnLogin` to better describe why we need to guard the function and provide necessary context.
3. Prefixed the functions called within `removeLaunchOnLogin` with "_", to signify that they should not be used as a public API. We should only call those functions after we've checked the return value of `getLaunchOnLoginApproved`.
4. Modified existing unit test, and added a new unit test to make sure `removeLaunchOnLogin` is non-op when Windows has disabled such feature.
Differential Revision: https://phabricator.services.mozilla.com/D227399
To reuse the code of RemoteWorker::State and RemoteWorker::Op in RemoteWorkerNonLifeCycleOpControllerChild, this patch isolates these reused codes into a new file RemoteWorkerOp.h. And also extract RemoteWorker::SharedWorkerOp into SharedWorkerOp.h.cpp
Depends on D197563
Differential Revision: https://phabricator.services.mozilla.com/D198005
In this patch, IPC PRemoteWorkerNonLifeCycleOpController is created for non-life cycle operations of SharedWorker/ServiceWorker.
PRemoteWorkerNonLifeCycleOpController is the IPC between the content process worker thread and the parent process background thread.
This IPC helps to build a direct communication instead of go through worker launcher thread and the main thread.
Endpoint<PRemoteWorkerNonLifeCycleOpControllerParent/Child> pairs are created when RemoteWorkerManager::LaunchInternal().
The parent Endpoint is binded a RemoteWorkerNonLifeCycleOpControllerParent immediately and connect to the corresponding RemoteWorkerController.
And the child Endpoint is passed through IPC PRemoteWorkerService::SendPRemoteWorkerConstructor() to the content process, and then binds to a PRemoteWorkerNonLifeCycleOpControllerChild when the Worker gets into "Running" state.
After connection is built, RemoteWorkerController can send non-life cycle related operations by PRemoteWorkerNonLifeCycleOpController and send life cycle related operations by PRemoteWorker.
Depends on D196946
Differential Revision: https://phabricator.services.mozilla.com/D197563
Currently, PRemoteWorker is managed by PBackground, which should be the same as the manager of the corresponding PRemoteWorkerService. Since the PBackground is gotten from PRemoteWorkerService.
This patch makes PRemoteWorkerService directly manage the PRemoteWorker.
PRemoteWorker will handle the life-cycle-related operations of RemoteWorkers, it might be renamed in the following patches.
Differential Revision: https://phabricator.services.mozilla.com/D196946
Use `serif`, `sans-serif` and `monospace` instead of, respectively,
```
Georgia, "Times New Roman", serif
Helvetica, Arial, sans-serif
"Courier New", Courier, monospace
```
This allows browser to actually use fonts set in the font settings.
Differential Revision: https://phabricator.services.mozilla.com/D226989
This patch introduces 4K image encoding tests to evaluate the encoder's
behavior, specifically frame dropping, under different scenarios. By
incorporating 4K images into our test suite, we can thoroughly assess
how the encoder handles frame dropping policies in both `Realtime` and
`Record` usages.
In the `Realtime` usage scenario, it allows frames to be dropped if
necessary, preventing delays when the encoder cannot keep up with the
desired frame rate. In contrast, the `Record` usage scenario demands
that all frames be preserved to maintain the highest possible quality.
By adding these 4K tests, we can verify that the encoder correctly
handles frame dropping policies in each usage mode. In addition, it's
easier to assess the performance by adding some timestamps if needed.
Differential Revision: https://phabricator.services.mozilla.com/D224437
Previously, the `AppleVTEncoder` did not adequately handle situations
where encoding errors occured, frames were dropped, or the encoder
produced empty outputs. In such cases, the output processing callback
was not invoked. This issue is particularly problematic in real-time
encoding modification introduced in the prior patch, where the encode
promse is managed within the output processing callback, causing the
encode promise to remain pending indefinitely.
This patch introduces an enum that encompasses the following cases:
encode error, frame dropped, empty output, and success. When the system
callback is invoked, the encode result is labeled with one of these enum
valus. This result is then passed to the output processing callback,
allowing it to appropriately resolve or reject the encode promise based
on the specific usage.
By explicitly handling these scenarios, the encoder ensures that encode
promises are properly resolved or rejected in all the cases. This
improvement prevent promises from remaining unresolved and avoiding
potential application hangs.
Differential Revision: https://phabricator.services.mozilla.com/D224054
This patch enhances the `AppleVTEncoder` to reduce latency in real-time
encoding scenarios, such as video conferencing, where the delay between
encoding a sample and receiving the encoded output is critical.
Previously, the `AppleVTEncoder` introduced at least one iteration of
delay because encoded outputs were only retrieved during the next
`Encode` call, not at the moment encoder produced them. Additionally,
there might be other time-consuming tasks running before the next
`Encode`, causing further delays. This behavior resulted in increased
latency, which is undesirable for real-time applications.
To address this issue, the patch modifies the encoder to return encoded
results directly within the callback function that is executed when
outputs are produced. This change ensures that encoded frames are
delivered immediately as they become available, significantly reducing
overall latency.
However, there are cases where the encoder produces encoded results only
after processing multiple input frames. For example, on TryServer's
machine running macOS 10.15, the first output may only be produced after
receiving multiple inputs. This behavior can cause the encode promise to
remain pending indefinitely if no outputs are produced.
To mitigate this, the patch introduces a timer mechanisam that forces
resolving the pending promise if no results have been yielded within a
reasonable timeframe. This ensures that pending encode promises are
resolved promptly, maintaining responsiveness in real-time applications.
Differential Revision: https://phabricator.services.mozilla.com/D222559
Originally we used node id from PipeWire as an unique device name and
while this works, it will change everytime PipeWire is restarted. This
has an impact on default camera selection, where for example Firefox can
automatically request a camera device that was used before, but this can
break with the next PipeWire restart.
This is a simple backport of an WebRTC upstream change.
Upstream commit: a5d71009ac1dce7da23813dc9413c03073cfa8ca
Differential Revision: https://phabricator.services.mozilla.com/D228635
This is just a band-aid to avoid the undefined behavior of std::clamp;
our CSSMinMax handles the case in a predictable way.
The real issue here must be that the frame has reported a "negative"
block-size, presumably due to integer overflow during nscoord arithmetic.
If we get a pernosco trace of the assertion, perhaps we can identify the
source of the overflow and correct/clamp it earlier to avoid this.
Differential Revision: https://phabricator.services.mozilla.com/D228595
Mac OS Sequoia added a Local Network permission. It's very easy for users
to accidentally dismiss this vague prompt and then be confused when trying
to load a local web page.
This patch adds a warning message to the error page on OSX instructing
users to check the permissions.
Differential Revision: https://phabricator.services.mozilla.com/D228576
Add a Glean metric counting the number of QUIC frames, labeled by frame type.
This is e.g. helpful to measure the impact of [stream receive window
auto-tuning](https://github.com/mozilla/neqo/issues/733), looking at the number
of max_stream_data frames sent and stream_data_blocked frames received.
Differential Revision: https://phabricator.services.mozilla.com/D228295
