This patch modifies the test case 'test_video_stats_resistfingerprinting.html'
to check media statistics report spoofed values when fingerprinting resistance
is enabled.
This test will play a video and test the media statistics when the video is finished.
It will make sure all media statistics report correct spoofed values corresponding
to the play time of the video.
MozReview-Commit-ID: GpYewu7cIbY
--HG--
extra : rebase_source : 0eb771c4a9472436f990d53a042656a60bab22f6
This patch makes the media statistics report values with a fixed frames per second
and a dynamic dropped ratio when resistance fingerprinting is enabled. The dropped
rate is decided by the video resolution that it will report a fixed dropped rate
when the video resolution is greater than 480p. And It will report a zero dropped
rate if the video is below or equal to 480p. In addition, it adds three new prefs
that allow us to change the value of frames per second, the dropped ratio and the
threshold of target video resolution. The three prefs are
'privacy.resistFingerprinting.video_frames_per_sec', 'privacy.resistFingerprinting.video_dropped_ratio'
and 'privacy.resistFingerprinting.target_video_res'. The default values of them
are 30, 5 and 480, which means 30 frames per second, 5 percent dropped ratio and
480p.
This also adds a new helper function 'nsContentUtils::ShouldResistFingerprinting(nsIDocument* aDoc)'
for checking whether fingerprinting resistance is enabled for a given docuemnt.
If it is a chrome document, this function will indicate that fingerprinting
resistance is not enabled regardless of the pref 'privacy.resistFingerprinting'.
If it is a content document, the result will depend on the pref.
MozReview-Commit-ID: FbSuRq6Zdnn
--HG--
extra : rebase_source : a62a1be19d9b38520f9eed7164fb258e3354d228
WebAuthn operations that are in-flight with authenticators must be cancelled
when switching tabs.
There's an Issue [1] opened with the WebAuthn spec for this already, but the
language is _not_ in spec. Still, it's necessary for security, spec or not.
This also matches how Chromium handles U2F operations during a tab switch.
[1] https://github.com/w3c/webauthn/issues/316
MozReview-Commit-ID: 6Qh9oC4pqys
--HG--
extra : rebase_source : ad1665b8140f74b1291f17994285e6146c4ec468
This patch skip the test_user_select.html test since windows build of
pgo/opt will fail this test sometimes on try.
This is temporaly solution until clarifying the reason of it.
(We track it on same bug).
MozReview-Commit-ID: BlwdoYxNTxP
--HG--
extra : rebase_source : 7201de141da43a3fd395a7f8ba4fdfb9fad1e6bf
Show the ping selector popup next to its toggle button in
about:telemetry.
Underline the fact that no archived pings are available.
MozReview-Commit-ID: CwSLOvuhXFn
--HG--
extra : rebase_source : 200b81af3abfea98beffa2c8c0460027a9c58f73
From the crash report and code logic, it is possible that the KillClearOnShutdown comes and the NS_XPCOM_SHUTDOWN_OBSERVER_ID never comes when getting obsercerService fail.
So add null check for the sParserWrapper and combine mShutdown to a new function.
MozReview-Commit-ID: Cj5ph2JrO7v
--HG--
extra : rebase_source : 4f9982a3e44e6f1a4db48739af92dc04cb0112d6
This patch intends to obtain a 1) rough sense of the percentage of telemetry
population using Web Authentication over time, and 2) whether or not the
Authentication request was successful or errored out as a scalar. It also tracks
3) how long it takes for requests to complete as a histogram.
It counts Register (enrollment) and Sign (login) separately as we would
anticipate there being far, far more Sign uses than Register.
MozReview-Commit-ID: 8DFyKAG8XJw
--HG--
extra : rebase_source : 0c168b32b995ffffda804538d2b92009d4dc38c5
Per spec, Range.prototype.extractNodes() should copy the nodes in tree
order:
https://dom.spec.whatwg.org/#dom-range-extractcontents
Gecko instead copies them in reverse order. This causes us to fail a
wpt MutationObserver test.
MozReview-Commit-ID: 8MYXGhDsJCd
--HG--
extra : rebase_source : 94fb2e96370e575906ba9927d904561744a1d7bb
This passes an openLink callback to the Reps which handles the output.
MozReview-Commit-ID: L6q9wAWmwrp
--HG--
rename : devtools/client/webconsole/test/browser_webconsole_clickable_urls.js => devtools/client/webconsole/new-console-output/test/mochitest/browser_webconsole_clickable_urls.js
extra : rebase_source : d439fe0596f0fdc2b3c529814bcd07c0c08c7200
This required some changes in the ConsoleTable component. Since
it uses GripMessageBody, we need to pass it props that it might
need.
MozReview-Commit-ID: DNeBsmJqCFI
--HG--
extra : rebase_source : 34f4b6acc34fdd79b4111f07162ede46b96ae363
This was spot-tested by taking the
layout/reftests/border-radius-clipping-1.html testcase, removing the
border, and fiddling with the border-radius values. Without this patch,
the div always appears with rectangular corners but with this patch the
border-radius value is respected correctly.
MozReview-Commit-ID: 1wBFnJnYCwC
--HG--
extra : rebase_source : 542f814af9369fe712af76fc2a8c78de26c6227f
There's no real reason to restrict this to LayerSize, since we use
use Layer and LayoutDevice coordinate spaces interchangeably for
webrender. With the templating of the function the compiler doesn't know
what type to use for {0, 0} so I added a new function to deal with that.
MozReview-Commit-ID: BA83Sy9UjYH
--HG--
extra : rebase_source : 15e5b31d0275628713c5eb584d622d22485dfda9
Since I am already poking around in ffvpxcommon.mozbuild's CFLAGS, also suppress these clang -Wvisibility and -Wstring-conversion warnings:
media/ffvpx/libavutil/dummy_funcs.c:83:34 [-Wvisibility] declaration of 'struct AVBufferRef' will not be visible outside of this function
media/ffvpx/libavutil/dummy_funcs.c:83:67 [-Wvisibility] declaration of 'struct AVFrame' will not be visible outside of this function
media/ffvpx/libavutil/utils.c:119:26 [-Wstring-conversion] implicit conversion turns string literal into bool: 'char [19]' to '_Bool'
And remove -Wno-logical-op-parentheses because clang does not currently report any -Wlogical-op-parentheses warnings for ffvpx.
MozReview-Commit-ID: 1kEwEHeD1PC
--HG--
extra : rebase_source : 133fa139f5389467919b88b96b8cbbf632bf002d
clang doesn't support gcc warning options -Wdiscarded-qualifiers or -Wmaybe-uninitialized in media/ffvpxcommon.mozbuild (added in bug 1369791), so only suppress those warnings for real gcc.
warning: unknown warning option '-Wno-discarded-qualifiers'; did you mean '-Wno-ignored-qualifiers'? [-Wunknown-warning-option]
warning: unknown warning option '-Wno-maybe-uninitialized'; did you mean '-Wno-uninitialized'? [-Wunknown-warning-option]
MozReview-Commit-ID: JUEqa6AN59x
--HG--
extra : rebase_source : 45e3c43d57e58119170700f7a339d1f2dfacff2c
extra : source : ee4a75aeb3585719700e1700746ce55984eba6fa
* Correct blue used as attention/accent color in the toolbar to #0a84ff (#45a1ff for brighttext) as specified.
* Use context-fill and context-stroke consistently in the animation svgs to pick up the current value of the attention color.
* Use --toolbarbutton-icon-fill-attention consistently to pick up the current value of the attention color.
MozReview-Commit-ID: 4NvzkQs66Nj
--HG--
extra : rebase_source : d519674faf0f4dd8a068a3ff3d4ef672bd03e7d8
While --fix previously worked with eslint, it is now more official (will show
up in the |mach lint --help|). ESlint is still the only thing that implements
it, but we can implement it for flake8 using the `autopep8` module.
--edit is a new concept that will open an editor for each failing file to let
you fix the errors manually. For now it is very naive (just opens the file),
and is only really useful if you have an editor integration for the linter(s).
But in the future I'd like to have editor-specific implementations for this.
For example, with vim, we can use -q to pass in an error file that will start
the editor pre-populated with a list of all errors that can then be easily
jumped to. Other editors may just open up to the line containing the error.
--fix and --edit can be used in conjunction with one another. Doing that means
only errors that can't be fixed automatically will show up in your editor.
MozReview-Commit-ID: 5JJJhMIrMIB
--HG--
extra : rebase_source : 2f78a77a91133d7fcc5620ecd5caa500decbce1b
This is the only approach that I managed to make work.
MozReview-Commit-ID: CUnkDoYN3di
--HG--
extra : rebase_source : 469912d015a403ef481685c617010613ea36b0b3
This was spot-tested by taking the
layout/reftests/border-radius-clipping-1.html testcase, removing the
border, and fiddling with the border-radius values. Without this patch,
the div always appears with rectangular corners but with this patch the
border-radius value is respected correctly.
MozReview-Commit-ID: Cu1K3rLjm0V
--HG--
extra : rebase_source : b5994faceb9dd7e52222714bdbc5b06886d26415
There's no real reason to restrict this to LayerSize, since we use
use Layer and LayoutDevice coordinate spaces interchangeably for
webrender. With the templating of the function the compiler doesn't know
what type to use for {0, 0} so I added a new function to deal with that.
MozReview-Commit-ID: KyabB6P6LiA
--HG--
extra : rebase_source : d5fff8f21a17c433d3c8c580fdd3153140d61545
Because we generate IDs for special nodes, we should update the inDefaultState getter to actually consider
these nodes to match even when the ids differ. This wasn't an issue before because specials weren't in the
default set for any nodes.
MozReview-Commit-ID: AI85yt2LuJD
--HG--
extra : rebase_source : 819e27885148deb588c057c4e811371a87f1d2fc
Also bump the xpi database schema version to force compatibility
recomputation (since we're not changing the application version number)
MozReview-Commit-ID: vVFIWmtN5v
--HG--
extra : rebase_source : 6e3e9a534aa390887573e538fa0bf14dd05dca50
