Fix up the browser_tab_label_during_restore.js test to wait for the right number of tab title changes, since the timing of the tab title updating has now changed.
Differential Revision: https://phabricator.services.mozilla.com/D72562
Starting with Firefox 76 we're seeing this (seemingly benign) error being reported much more commonly, causing unnecessary load on our Sentry instance. Adding .noReport=true keeps this from being reported to Sentry.
Differential Revision: https://phabricator.services.mozilla.com/D74471
`Query.start` shouldn't `await provider.tryMethod("isActive")`. Instead it
should call all providers at once and then await all the promises. Also make
some other simplifications and changes to `Query.start` in preparation for later
patches.
Factor out `notifyResults` into `Query._notifyResultsFromProvider` because the
next patch will use it.
Differential Revision: https://phabricator.services.mozilla.com/D74191
In RFP mode, canvas image extraction leads to an all-white image, replace that
with a random (sample 32 bytes of randomness and fill the buffer with that)
'poison pill'. This helps defeat naive fingerprinters by producing a random
image on every try. This feature is toggled using a new, default on, pref
`privacy.resistFingerprinting.randomDataOnCanvasExtract`.
Updated `browser_canvas_fingerprinting_resistance.js` to test this new feature
as well.
Updates and replaces D66308.
Differential Revision: https://phabricator.services.mozilla.com/D72716
In RFP mode, we do not support `PerformanceNavigationTiming`, so don't expose
it. In particular, `window.PerformanceNavigationTiming` should return
`undefined`.
Added a new method `PerformanceNavigationTiming::Enabled` which when used with
the WebIDL `Func` attribute allows us to toggle whether
`window.PerformanceNavigationTiming` is exposed.
Created
`dom/tests/mochitest/general/test_toggling_performance_navigation_timing.html`
to test whether the toggling works. Updated
`browser/components/resistfingerprinting/test/browser/browser_performanceAPI.js`
to create a new window each time `privacy.resistFingerprinting` is flipped so
this behavior does not leak into other tests.
Differential Revision: https://phabricator.services.mozilla.com/D73528
This seems to come from bug 618907, which seems to be a hack-around code
that went away in bug 1595435.
If we open a window on mousedown such as it gains focus before this code
runs, we just steal the focus from it, which is undesired.
Also remove the test for bug 799299. It doesn't work anyways if the
browser is remote (this test only runs on non-e10s mode), and this
unifies the behavior with e10s and with content (see attached test-case,
which doesn't change behavior with and without my patch).
Differential Revision: https://phabricator.services.mozilla.com/D73901
This code was relying on SessionHistory update having completed when
GlobalHistory is update. Moving GlobalHistory update to the parent process with
DocumentChannel means that it's possible for the GlobalHistory event to fire
before the SessionHistory is updated in nsDocShell.
Switch to using tab loading complete to signal when it's OK to check
SessionHistory.
Differential Revision: https://phabricator.services.mozilla.com/D72280
Accesskey for XUL works from frame construction, so we need to do this
for the test to keep passing with LazyFC.
I don't think this has a user-visible impact in practice.
Differential Revision: https://phabricator.services.mozilla.com/D74280
Now that upstream winchecksec builds and works natively on Linux, use
that. That should solve the random crashes under Wine. If random crashes
still happen, it will be easier to debug anyways.
We bump to the last version that doesn't use vcpkg because vcpkg makes
things more difficult.
Differential Revision: https://phabricator.services.mozilla.com/D73405
This removes processing of HTTP Public Key Pinning headers, remotely modifying
pinning information, and using cached pinning information, all of which was
already disabled in bug 1412438. Static pins that ship with the browser are
still enforced.
Differential Revision: https://phabricator.services.mozilla.com/D73352
Prior to this patch, PDF.js tracks both its own 'disabled' pref (which is used
by enterprise policy) and whether it is the default handler per the handler
service - but it tracks both in one bool, which determines whether its
streamconverter registers.
Really, what we want is to never use PDF.js if it's preffed off.
However, if there is some other default, it should be acceptable to use PDF.js
in some circumstances, like for <embed> or <object>s where otherwise we
would show no content at all.
Even for toplevel PDFs, if the user has configured Firefox to open PDFs in
an external helper app which is Firefox (which is currently an easy mistake
to make in the unknownContentType dialog), or has it set to the OS default,
but has changed their OS default to Firefox, we really still want to open
those PDFs with PDF.js.
This patch fixes all of this by splitting out the pref tracking from the
handler state tracking. Only the pref will completely disable PDF.js.
Then, in the streamconverter code, we check whether PDF.js should be used for
PDFs, and if there's a misconfiguration that we can correct. This code is
invoked from the parent process when we load PDFs in frames or toplevel
documents, and will prevent us from invoking PDF.js in the child if the user
would prefer that not to happen.
As a driveby, this cleans up how we track the pref inside PDF.js, and how we
get notified of changes to the handler - we were missing changes made in the
unknown content type dialog, so it seemed worth making it generic.
Differential Revision: https://phabricator.services.mozilla.com/D73510
