This patch adds a test case in the same file of part 3 that to check that does
fingerprinting resistance work correctly for workers when 'privacy.resistFingerprinting'
is true.
MozReview-Commit-ID: FoceQTGg127
--HG--
extra : rebase_source : ead0979a5b7d2f34804ceecf004155a0100fa064
This test case will open a content tab and access performance API in that
tab to check whether or not performance APIs are correctly spoofed.
MozReview-Commit-ID: KdG6xzQFmv6
--HG--
extra : rebase_source : d064d5a90d525190402107c22bac9ed2dfd4c085
This patch is going to neutralize the threat of fingerprinting of performance API
by spoofing the value of performance timing into 0, making getEntries* functions
always returns an empty list and making mark() and measure() into NOP methods.
In addition, this patch changes nsContentUtils::ShouldResistFingerprinting() to
allow it can be called in both main thread and worker threads.
MozReview-Commit-ID: C8Jt7KEMe5e
--HG--
extra : rebase_source : 85cbf66881c868ca5109022ffd4af81e3ab0a049
This is a rebase of #17325 with `[replace]` entries removed, a bunch more dependencies updated, and some more compile fixes. Original work by @Eijebong, thanks a lot!
Source-Repo: https://github.com/servo/servo
Source-Revision: 66c130d55aa0d7af1104c00e93a5bf950f23a383
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 323361580a540d8b296f6f7d77f20d46cbdc5c73
We need to delay the response from the setWindowRect command until the
window has had time to properly resize. But because the DOM resize
event is not synchronous, we cannot rely on it alone to tell us when the
widget toolkit has actually completed the resizing.
To overcome this problem we throttle the event using
ChromeWindow.requestAnimationFrame to force the event loop to flush
before resolving the promise.
The setWindowRect command previously relied on a 15 FPS setTimeout delay
because requestAnimationFrame did not work with ChromeWindow, but this
seems to have since been fixed. Local tests show that this approach is
more stable and produces less intermittent results.
MozReview-Commit-ID: D1ICb3F6vX3
--HG--
extra : rebase_source : ef5ef15db80ce78284672551581ce5d9cdde9189
Bug 1370576 disabled staging of application updates, which is not yet
supported in our firefox-ui update tests. As result there is a hang and
the restart button is never clicked on.
This is just a wallpaper fix and full support might still have to
be integrated if wanted.
MozReview-Commit-ID: 8LF1RKxnMEb
--HG--
extra : rebase_source : 5a268cd891a6577eda163c86fe6ef94fe767fbff
macOS doesn't really have a maximized mode; it has a "zoomed" mode which we treat as "maximized" sizemode, and it has a fullscreen mode. When you zoom a window, it's supposed to resize to its "natural" or "best" size, which is for most apps the smallest size that does not require scrolling. In Firefox we just say that filling the whole screen is our "best" size. But if a window is zoomed, you can still move it by dragging its title bar. For example, you may want to do that if you want to move it to a different screen.
Mac apps usually don't change their appearance at all if they enter the "zoomed" size. They only do that if you make the window fullscreen. The native full screen mode on Mac is much closer to the maximized mode on Windows than the zoomed mode is.
Recent versions of macOS have changed the default action of the green window button to be fullscreen instead of zoom. You can now only zoom windows by double clicking the title bar or clicking the green button while holding Alt.
MozReview-Commit-ID: IBu2fBNeuil
--HG--
extra : rebase_source : 1e2fa2af658edaf19a8cb6e6da39a1187c09b833
Gathering this data point takes up to 100ms on reference hardware and might impact
startup performance.
MozReview-Commit-ID: 32sd5uUF08N
--HG--
extra : rebase_source : a80da25b384b47995cc25db9a711ef02ca5842cd
This is the Servo side change for [bug 1372488](https://bugzilla.mozilla.org/show_bug.cgi?id=1372488).
Source-Repo: https://github.com/servo/servo
Source-Revision: 32f82959f89ccd0d6f92058f22f11f2cc7d21d52
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 64ef1f0cba8d44b9451874cd5aec2a851fb1fdfd
We test the expected behavior base on the pref,
"security.data_uri.unique_opaque_origin".
We run the legacy test when the pref is off, however if the pref is on,
we run the new behavior, loading an iframe with X-FRAME-OPTIONS in a
data: URI should be blocked.
Move the data URI in 'if_no_scripts' and 'if_scripts' to seperate files.
Also remove the test 'if_19', as it seems redundant, it tests the same
thing with the iframe 'if_scripts', and it also lacks of 'allow-scripts'
in its sandbox flag.
A mochitest browser test for image blocking.
We query the blocking status by reading imageBlockingStatus.
See nsImageLoadingContent.cpp for the logic of blocking image.
In this test we verified the following behavior:
1. image is loaded.
2. image is blocked.
3. mCurrentRequest doesn't have size yet, so it should be replaced.
4. mCurrentRequest already got size, the following request should be a
pendingRequest.
Use a boolean to prevent calling SetBlockedRequest asynchronously.
Also use the same boolean to prevent some evil code reenters LoadImage.
Then we should redesign the correct bahavior in those follow-up bugs,
Bug 1353685 - Should ServiceWorker call SetBlockedRequest
Bug 1353683 - consider calling SetBlockedRequest in nsCORSListenerProxy::UpdateChannel
Bug 1371237 - consider calling SetBlockedRequest in nsContentSecurityManager::CheckChannel
The problem is if we found a cache hit, then we could go through
ValidateRequestWithNewChannel to validate the cache.
Then if the CSP check fail(asyncOpen2() will fail), then the
imgRequestProxy will remain there, and cause the timeout.
I run into problem when running mochitest
browser/base/content/test/general/browser_aboutHome.js in non-e10s mode.
In the beginning, browser.xul will load defaultFavicon.png, will create
an image cache there.
Next time when the test starts to run, when it loads about:home, then it
will try to load defaultFavicon.png, it will found an image cache hit
(loaded previously by browser.xul), and call
ValidateRequestWithNewChannel there, however the asyncOpen2 call failed,
and the imgRequestProxy is added to the loadGroup of about:home, and
never be notified until timeout.
As a follow-up from bug 1206961, we will remove calling CanLoadImage in
this bug. Also in the case of CSP check failed, we will call
SetBlockedRequest in those cases.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1267075#c30 for the
analysis between the old and new setup.
Tim Huang
Rex Lee
Servo VCS Sync
Simon Sapin
Mark Banner
James Graham
Sebastian Hengst
Liang-Heng Chen
Andreas Tolfsen
Henrik Skupin
Glenn Watson
Dão Gottwald
Cameron McCormack
Alessio Placitelli
Xidorn Quan
Phil Ringnalda
Bill McCloskey
Yoshi Huang