unlink("") will always return -ENOENT if passed to the kernel, so just
do the same thing here. We need this as empty paths can't be whitelisted.
Differential Revision: https://phabricator.services.mozilla.com/D132174
This modifies the opt-in modal so that opting in or out affects only the
data-collection pref and not suggestions like it currently does.
Depends on D131751
Differential Revision: https://phabricator.services.mozilla.com/D131752
This enables suggestions by default in the online scenario. Data collection is
still disabled by default. With this revision, there's now no difference between
online and offline in terms of defaults.
Part 2 of this bug will modify the opt-in modal so that opting in or out affects
only the data-collection pref and not suggestions like it currently does.
For users who were already enrolled in online, saw the modal, and did not opt in
or otherwise enable suggestions, suggestions will remain disabled when they
upgrade. Users in online who did enable suggestions will continue to see them
when they upgrade. Users in online who did *not* see the modal will also have
suggestions enabled when they upgrade. That's unfortunate since they currently
have suggestions disabled, but based on telemetry data, the number of these
users is small, and it's a little risky to handle that case specifically because
if we're not careful we could end up disabling suggestions for all users coming
from 94.0.1 and earlier who enroll in online in the future. The code comment in
`UrlbarPrefs._migrateFirefoxSuggestPrefsUnversionedTo2Online()` and discussion
in D131751 talk about this.
For all other users, suggestions will default to enabled when/if they are
enrolled in online.
I added another prefs migration to implement all this.
I wrote a [test plan doc](https://docs.google.com/document/d/1tcbrBZmIaL_cQhvycoVL602kQqFtQvOBRhKV9zKqghE/edit?usp=sharing) to make sure all relevant upgrade paths work correctly
and I've verified it myself. I also added new automated tests of course.
Differential Revision: https://phabricator.services.mozilla.com/D131751
Tasks that set this key to false *will not* run under the standard no variant
configuration.
This is needed to replace the 'e10s=false' case (i.e tasks that *only* run with
1proc like mochitest-chrome or mochitest-a11y.
Depends on D133224
Differential Revision: https://phabricator.services.mozilla.com/D133225
Previously we we're validating the entire 'test_description_schema' again, even
though the vast majority of those keys were in fact no longer needed. This was
preventing us from ever removing keys from the 'task' object. Which I believe
is a good practice to keep things simple.
Differential Revision: https://phabricator.services.mozilla.com/D133222
Using hyphenation patterns from https://github.com/santhoshtr/hyphenation.
The tests here are implemented as Mozilla reftests rather than added to WPT because I don't think
we can reasonably have such tests in WPT. The specific set of languages for which the UA supports
auto-hyphenation is not a normative requirement, and nor is the particular dictionary or algorithm
that will be used for any specific language. As such, the exact results are not defined by the
spec. (They may also change over time, if the hyphenation rules we use are updated, in which case
the tests will have to change accordingly.)
Differential Revision: https://phabricator.services.mozilla.com/D133558
EH_TIME_TO_FINAL_RESPONSE - This will collect time duration between receiving a 103 response and the final response. This is only collected for 2xx response and only if at least one 103 has been received.
EH_NUM_OF_HINTS_PER_PAGE - number of 103 responses received for a page load. 0 will mean that a page has not received a 103 response. This is only collected for 2xx response.
EH_FINAL_RESPONSE - whether the final response was 2xx or any other code. This is only collected if at least one 103 has been received.
The change also introduced the class EarlyHintsPreloader that will be extended to perform all EarlyHints tasks.
Differential Revision: https://phabricator.services.mozilla.com/D132556
This change parallelizes the loading of those few tests which assume
the same permissions and prefs, which should speed it up to some degree
To err on the side of caution, we'll also double the time this
test may take to until we time out.
Differential Revision: https://phabricator.services.mozilla.com/D133622
Also updates the docs on how to update the glean_parser in-tree.
Also adds a `no_lint` exception to test pings to avoid breaking the
build.
Differential Revision: https://phabricator.services.mozilla.com/D133077
With the old layers backend we had low precision buffer code controlled via the pref layers.low-precision-buffer that was used on android. We would expand the displayport by 4x and then paint it as 1/4 the resolution, and then we would have a critical displayport without the 4x multipler that we would paint at the real resolution. The code to do the painting at the lower resolution was in the layers backend and has since been removed. (This is okay because webrender doesn't rasterize all of the content in the displayport.) So the critical displayport or displayport are no longer treated differently anywhere. Except a few pieces of code that should be fixed/changed/removed. This patch being one of them.
Using the critical display port here is incorrect: the display port and critical display port have the same status with regards to rasterized content as well as the same status with regards to webrender having the displaylist of the content to be able to rasterize.
AboutToCheckerboard is only used in AsyncPanZoomController::OnScale to potentially schedule a RequestContentRepaint sooner, so this should have a small effect in practice.
Differential Revision: https://phabricator.services.mozilla.com/D127349
Remove an incorrect assertion in WasmMemory.cpp -- we don't need to depend on
the max buffer byte length being a multiple of page sizes, as we always round.
Rewrite two uses of maxBufferByteLength to instead use MaxMemoryPages, since
it's the latter quality we care about.
Differential Revision: https://phabricator.services.mozilla.com/D133480
In order to make sure these APIs work properly, we have to flush style before
building the path to make sure the d property is up-to-date.
1. isPointInFill()
2. isPointInStroke()
3. getTotalLength()
4. getPointAtLength()
5. getPathSegAtLength() (note: Legacy API, only Gecko and WebKit support.)
Differential Revision: https://phabricator.services.mozilla.com/D133434
This only records whether Firefox is the default PDF handler for now.
But it will accommodate additional file types and protocols in the
future, should they be desired.
This is Windows 10+ only, since we really only care about PDF handling
defaults where Edgium is the OS default.
Differential Revision: https://phabricator.services.mozilla.com/D132659
