This patch also contains a few additional minor changes:
- Clears the user value set to the pref app.update.auto after the value is migrated.
- Fixes the app.update.auto pref migration test
- Makes a number of functions asynchronous to allow them to wait for app.update.auto setting changes
- TestAUSHelper's create-update-dir command no longer tries to set the permissions on all files in the update directory. Fixes a potential race condition when creating the update directory.
Depends on D4594
Differential Revision: https://phabricator.services.mozilla.com/D10315
--HG--
extra : moz-landing-system : lando
This change makes TelemetryEnvironment.settings.update.autoDownload load asynchronously. Now, a file needs to be read before that value can be written. This has the potential to delay the initialization of TelemetryEnvironment, but since it should be pretty quick and it runs in parallel with the other asynchronously loading values of TelemetryEnvironment, it should not delay initialization significantly.
MozReview-Commit-ID: 1UUAi4sDopX
Depends on D4591
Differential Revision: https://phabricator.services.mozilla.com/D4593
--HG--
extra : moz-landing-system : lando
This patch additionally includes support for automatic migration of the pref from its old location to its new location.
This patch does not fix telemetry reporting of app.update.auto - that will be addressed in another patch in the same series.
MozReview-Commit-ID: KjX1mmGVB8M
Differential Revision: https://phabricator.services.mozilla.com/D4590
--HG--
extra : moz-landing-system : lando
This got added in bug 1429508 and then removed in bug 1451845. Tiled blobs adds tests for this, so it shouldn't break again.
MozReview-Commit-ID: 3azL7SoWlr2
Depends on D10038
Differential Revision: https://phabricator.services.mozilla.com/D10041
--HG--
extra : moz-landing-system : lando
This just makes the existing hack available to all DataSourceSurface implementations by default, since we use different ones with WR.
MozReview-Commit-ID: GVR0rIx8wtD
Depends on D10036
Differential Revision: https://phabricator.services.mozilla.com/D10038
--HG--
extra : moz-landing-system : lando
If mIsRunningOnCompositor is true, the property is effective state because
CanThrottle() is called in advance of a restyle for the effect so that we can
drop the check and drop skipping in the case of non-effective properties.
Depends on D10694
Differential Revision: https://phabricator.services.mozilla.com/D10695
--HG--
extra : moz-landing-system : lando
The comment there was wrong. We just bail out from there only if
mIsRunningCompositor is false, so it doesn't matter whatever the layer
generation check results. (i.e., we don't bail out in the case where
mIsRunningCompositor is true).
Also, we iterate over mProperties in the LayerAnimationInfo::sRecords loop
through HasEffectiveAnimationOfProperty, so it doesn't matter that we iterate
mProperties before the loop either. We will avoid the iteration in the sRecords
loop in a subsequent patch in this series.
Depends on D10692
Differential Revision: https://phabricator.services.mozilla.com/D10693
--HG--
extra : moz-landing-system : lando
In the case of WebRender there is no layers, but actually we'd been using it for
WebRender too, that's confusing.
Depends on D10689
Differential Revision: https://phabricator.services.mozilla.com/D10690
--HG--
extra : moz-landing-system : lando
Also add a script to generate the CSS properties set by looking at
CanAnimateOnCompositor flag in servo's property definitions.
Differential Revision: https://phabricator.services.mozilla.com/D10687
--HG--
extra : moz-landing-system : lando
In windows and linux, ensure that the text color inside the content blocking button is visible. Add 5px of margin beside the icon to separate it from the text.
Differential Revision: https://phabricator.services.mozilla.com/D11099
--HG--
extra : moz-landing-system : lando
For channel mapping 0 (which is always mono or sterero), the mapping is identical to the SMPTE one, so can copy the mapping as-is.
Differential Revision: https://phabricator.services.mozilla.com/D11000
--HG--
extra : moz-landing-system : lando
https://tools.ietf.org/html/rfc8441
This uses our existing http/2 CONNECT infrastructure (modified) to
enable the new extended CONNECT form defined by 8441, and pretend for
the websocket's sake that an http/2 stream is actually a socket. From
the websocket's point of view, this is relatively non-invasive - a few
things have changed (http response code, absence of some headers) versus
http/1.1 websockets, but for the most part, the websocket code doesn't
care.
Differential Revision: https://phabricator.services.mozilla.com/D8016
--HG--
extra : moz-landing-system : lando
If switching from a view that didn't load the extension list
binding to the themes view the screenshot wouldn't be found
on Windows. Force a layout if the screenshot isn't found
to load the binding.
Differential Revision: https://phabricator.services.mozilla.com/D10814
--HG--
extra : moz-landing-system : lando
Make CityHash64, CityHash64WithSeed, and CityHash64WithSeeds usable from C code
Remove unnecessary includes from mar_read.c as well
Add DisableStlWrapping to mar tool's moz.build to fix linkage break when
building in Windows with MSVC
Differential Revision: https://phabricator.services.mozilla.com/D10774
* If a search is performed in a private window and the new pref `browser.engagement.search_counts.pbm` is true, then do not record `SEARCH_COUNTS` telemetry. Note that the the pref must be true. If it's false or doesn't exist, then we record telemetry even in pbm like we normally do currently. (We record `SEARCH_COUNTS` telemetry in two places: (1) In BrowserUsageTelemetry.jsm, and (2) "in-content" telemetry directly in the search service. So skip both of those places.)
* Also skip the other ancillary telemetry recorded by `BrowserUsageTelemetry._recordSearch`: a keyed scalar and a telemetry event.
* I made some modifications to the search service to let me test the "in-content" telemetry keys
Differential Revision: https://phabricator.services.mozilla.com/D10851
--HG--
extra : moz-landing-system : lando
In case fuzzers or somebody can catch this in a reproducible way...
I'd be interested in knowing what the hell is going on.
Differential Revision: https://phabricator.services.mozilla.com/D11053
--HG--
extra : moz-landing-system : lando
Defaults now to 'true', when caching is good enough I'll switch it off.
Generally, this would be used for apps/cases when full accessible tree
is needed like UIAutomator.
Depends on D9864
Differential Revision: https://phabricator.services.mozilla.com/D9865
--HG--
extra : moz-landing-system : lando
This protocol is meant to be used by platform wrappers to push bulk data
to the chrome process.
Depends on D9689
Differential Revision: https://phabricator.services.mozilla.com/D9864
--HG--
extra : moz-landing-system : lando
Implemented the manual linting fixes for docshell/test/navigation, docshell/test/unit and docshell/test/unit_ipc
Depends on D9430
Differential Revision: https://phabricator.services.mozilla.com/D10080
--HG--
extra : moz-landing-system : lando
Enabled ESLint for:
* docshell/test/navigation/**
* docshell/test/unit/**
* docshell/test/unit_ipc/**
Changed .eslintignore to allow for this and ran ./mach eslint --fix on the above directories and checked automatic fixes
Differential Revision: https://phabricator.services.mozilla.com/D9430
--HG--
extra : moz-landing-system : lando
The fetch spec treats null bodies specially. Their Body cannot become
disturbed or locked and a fresh empty ReadableStream is returned whenever an
attempt is made to consume the body. We currently fail a number of WPT tests
in this area because we do mark the body consumed as exposed via bodyUsed.
