Previously, as seen, I wrote some horrible code. This patch intends to fix the thread safety issue in the permission prompt code for OffscreenCanvas.
For context, with privacy.fingerprintingProtection=True and privacy.fingerprintingProtection.overrides="+CanvasImageExtractionPrompt", when a canvas is read, we randomize the data, and return the randomized data. At the same time, we show a permission prompt asking the user if they want to allow the website to read the canvas data without randomization. It is a non-blocking prompt (i.e. we allow further canvas reads, it just keeps adding the randomization).
We have two types of canvases. HTMLCanvasElement and OffscreenCanvas. The former is used in the main thread, the latter can be used in both the main thread and worker threads.
To ask for permission, we need to communicate with the parent process with the correct window. However, accessing window from a worker thread is not thread safe. We need to dispatch to the main thread to access the window.
Original Revision: https://phabricator.services.mozilla.com/D262475
Differential Revision: https://phabricator.services.mozilla.com/D263138
We should not have a null mScrollContainerFrame in an asr that is in use, but we are getting crashes in bug 1764863 that show that this is happening at volume. We have not been successful over a long period of time of finding a testcase or some way to reproduce. We have a landed patch in bug 1984898 (based on a pernosco of one instance of this from a few years back) that we hope fixes some or most of these. The patch in bug 1984898 is a little bit big, and we have no evidence that it fixes the problem. So I am proposing this patch as something we can uplift that should work around the problem. We still want to fix any instances of that this we come across so the MOZ_DIAGNOSTIC_ASSERT will fire in nightly and early beta builds. The gfxCriticalNoteOnce will alert us if this is having negative consequences later on.
By returning false we will abort the partial display list update and delete the retained display list that contains an asr that has a null mScrollContainerFrame and we will do a full rebuild. This should avoid the problem and be much better than crashing.
Original Revision: https://phabricator.services.mozilla.com/D263224
Differential Revision: https://phabricator.services.mozilla.com/D263820
This allows extensions to access their own content from scripts that they
injected into web pages, without that requested content being automatically
blocked due to failing CORS checks (since the Origin of the request is
the web page).
We have an existing pref 'extensions.content_web_accessible.enabled' whose
'false' value is meant to allow MV2 extensions to access their own resources
from their content-scripts (even if those resources aren't web-exposed). A
recent CORS strictness patch broke this use-case; so this patch relaxes the
strictness, specifically for extensions and specifically when that pref has
the permissive 'false' value.
While we're at it, this patch extends the related xpcshell test cover the case
where the pref is in its default/permissive 'false' configuration (to test the
regression being addressed by this patch), and to test that MV3 is strict under
that configuration. This patch also clarifies the other relevant pref for CORS
principal-selection to avoid implying that it's relevant to WebExtensions
(since it's not anymore).
Original Revision: https://phabricator.services.mozilla.com/D262863
Differential Revision: https://phabricator.services.mozilla.com/D263613
This prevents windowDidResignMain from altering the menubar when Firefox
is not the active app. This avoids menubar changes on multiple monitors
when switching from one window to another. When Firefox becomes active
again, it will update its menubar, which is typically the same menubar
as it had before.
Differential Revision: https://phabricator.services.mozilla.com/D255243
nsHttpResponseHead::ParseHeaderLine_locked parses each header as it comes in.
It then updates its own member variables based on that header.
For cache-control, it's important to reparse the merged version of the header
instead of the most recent one, otherwise we'll miss directives present in
previous headers.
Original Revision: https://phabricator.services.mozilla.com/D260461
Differential Revision: https://phabricator.services.mozilla.com/D263269
without -fvisibility=hidden, linking libxul fails with undefined hidden symbol
references to std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char>>
Differential Revision: https://phabricator.services.mozilla.com/D262230
This patch relaxes the restriction on BitSet so that it can take
mozilla::Atomic as its storage type.
The Reference assignment operator is changed so that it results in a single
update rather than a separate read and update that would not be atomic when
used with atomic storage.
Tests are added for atomic storage and to exercise the assignment operator.
Differential Revision: https://phabricator.services.mozilla.com/D259230
|aborted| is reset to false at the end of a slice but
GCRuntime::waitBackgroundSweepEnd can be called outside of a slice.
Differential Revision: https://phabricator.services.mozilla.com/D260685
Before this patch, we would unconditionally block in window.print() if the user
had the system print dialog enabled. That was problematic because it prevents
mozPrintCallback from doing asynchronous work, as described in the nearby
code-comment, and this resulted in PDFs printing blank for such users if they
used the "print" button (which triggered window.print()).
This patch makes the print.prefer_system_dialog codepath share the same logic
flow as the regular-print-preview codepath -- now we will *not* block if
there's a registered print callback (which allows the callback's microtasks to
proceed while the print dialog is still up).
Original Revision: https://phabricator.services.mozilla.com/D261296
Differential Revision: https://phabricator.services.mozilla.com/D262703
Sometimes we submit rectangles for drawing without a transform to bypass the transform.
However, for OP_SOURCE, we expected there to always be a transform to check when to clear
the background. This fixes the OP_SOURCE check to account for untransformed rects.
Differential Revision: https://phabricator.services.mozilla.com/D261805
With content analysis active, if a DLP agent pops up a dialog but allows
the print to happen (for example, when responding REPORT_ONLY), this can
cause ::StartDocW() to fail for "printer"s that pop open a dialog for the
user to choose where to save the file. (i.e. Microsoft Print to PDF)
After trying some various hacks, the one that worked was calling
SetForegroundWindow() on a Firefox window before calling ::StartDocW().
It even works if the Firefox window that we call SetForegroundWindow()
isn't the one that the print is happening in. (which I verified by starting
a print and then quickly clicking on another window)
I put this behind a pref just in case this causes problems in the future,
but I doubt it will.
I also reverted the previous attempt to fix this by calling
::LockSetForegroundWindow(), which does not work.
Original Revision: https://phabricator.services.mozilla.com/D261572
Differential Revision: https://phabricator.services.mozilla.com/D262385
Before this patch if we failed to launch the crash helper client then we
would either freeze or crash Firefox, which is not what we want. This
makes sure that errors when launching the crash helper are not
catastrophic. Additionally, this problem was triggered on a machine that
launched more than 64 child processes at startup during session restore.
That was a hard limit on Windows because of the limitations of
WaitForMultipleObjects(). I adjusted the code to also handle that
gracefully even though we don't support more than 64 child processes at
the moment. That's not a big deal because we're not yet using that
particular IPC channel, so ignoring every child process above the 63rd
doesn't change anything at the moment. Last but not least there was a
small race in the crash helper rendez-vous that might cause Linux to
attempt to generate a minidump before we had allowed a child process to
allow the crash helper to ptrace() it. This was also fixed.
Original Revision: https://phabricator.services.mozilla.com/D256299
Differential Revision: https://phabricator.services.mozilla.com/D262076
This channel is currently only used on Linux to rendez-vous with the
crash helper, obtain its PID and use it to enable the process to be
dumped when the Yama LSM is enabled. It will be used to actually request
a dump in the future, when the breakpad exception handler is removed.
Original Revision: https://phabricator.services.mozilla.com/D254047
Differential Revision: https://phabricator.services.mozilla.com/D262074
This is the second step towards daemonizing the crash helper process. The code
used to listen to incoming connections and messages is moved directly into the
server for better coupling. New and existing connections are now categorized
as belonging to Firefox parent process, a child process or an external process
(typically the WER service on Windows). The permission checks on the various
messages are now based on these categories, instead of the PIDs of the
crash helper clients.
Original Revision: https://phabricator.services.mozilla.com/D251559
Differential Revision: https://phabricator.services.mozilla.com/D262070
