Implement the changes from <https://github.com/tc39/ecma402/pull/877> to reduce
differences in time zone canonicalisation when compared to V8 and JSC (which
both use CLDR time zone data instead of IANA time zone data).
Implementing the `AvailableNamedTimeZoneIdentifiers` spec operation requires to
link time zone identifiers to region codes. When the time zone is listed in the
"zone.tab" file, we can get the region code from "zone.tab". In all other cases
we need to manually map the time zone to a matching region, because CLDR doesn't
have "public" data for this [1]. This is implemented using the new file
"intl/TimeZoneMapping.yaml".
ICU 74 added `ucal_getIanaTimeZoneID` to get the canonical IANA time zone id.
Internally `ucal_getIanaTimeZoneID` first calls `ucal_getCanonicalTimeZoneID`
and then loads a resource bundle to check if there are any time zone ids which
need to be replaced with other ids for compatibility with IANA data. Unfortunately
the resource bundle is not cached, so calling `ucal_getIanaTimeZoneID` instead
of `ucal_getIanaTimeZoneID` adds a considerable performance overhead. To avoid
any performance regressions, we keep our own time zone rewriting code for the
time being.
Using our own code also means we don't have to add a workaround for this CLDR
bug: <https://unicode-org.atlassian.net/browse/CLDR-16439>.
Also remove "Factory" from the list of supported time zone identifiers, because
supporting it was always a bit questionable and latest V8 also doesn't support
it anymore, so we shouldn't run into web-compat issues.
Remove the old generated tests and add "timeZone_links.js" to ensure time zone
links are correctly resolved.
[1] Neither of these two files look like "public" data to me:
- https://github.com/unicode-org/cldr/blob/main/tools/cldr-code/src/main/resources/org/unicode/cldr/util/data/TZID.txt
- https://github.com/unicode-org/cldr/blob/main/tools/cldr-code/src/main/resources/org/unicode/cldr/icu/idList.txt
Differential Revision: https://phabricator.services.mozilla.com/D228584
Implement the changes from <https://github.com/tc39/ecma402/pull/877> to reduce
differences in time zone canonicalisation when compared to V8 and JSC (which
both use CLDR time zone data instead of IANA time zone data).
Implementing the `AvailableNamedTimeZoneIdentifiers` spec operation requires to
link time zone identifiers to region codes. When the time zone is listed in the
"zone.tab" file, we can get the region code from "zone.tab". In all other cases
we need to manually map the time zone to a matching region, because CLDR doesn't
have "public" data for this [1]. This is implemented using the new file
"intl/TimeZoneMapping.yaml".
ICU 74 added `ucal_getIanaTimeZoneID` to get the canonical IANA time zone id.
Internally `ucal_getIanaTimeZoneID` first calls `ucal_getCanonicalTimeZoneID`
and then loads a resource bundle to check if there are any time zone ids which
need to be replaced with other ids for compatibility with IANA data. Unfortunately
the resource bundle is not cached, so calling `ucal_getIanaTimeZoneID` instead
of `ucal_getIanaTimeZoneID` adds a considerable performance overhead. To avoid
any performance regressions, we keep our own time zone rewriting code for the
time being.
Using our own code also means we don't have to add a workaround for this CLDR
bug: <https://unicode-org.atlassian.net/browse/CLDR-16439>.
Also remove "Factory" from the list of supported time zone identifiers, because
supporting it was always a bit questionable and latest V8 also doesn't support
it anymore, so we shouldn't run into web-compat issues.
Remove the old generated tests and add "timeZone_links.js" to ensure time zone
links are correctly resolved.
[1] Neither of these two files look like "public" data to me:
- https://github.com/unicode-org/cldr/blob/main/tools/cldr-code/src/main/resources/org/unicode/cldr/util/data/TZID.txt
- https://github.com/unicode-org/cldr/blob/main/tools/cldr-code/src/main/resources/org/unicode/cldr/icu/idList.txt
Differential Revision: https://phabricator.services.mozilla.com/D228584
The spoofed value of the HTTP user-agent header is not consistent with
the value of navigator.userAgent on Windows, and this can lead to
compatibility issues.
Differential Revision: https://phabricator.services.mozilla.com/D223745
- This patch separates RFPTarget::PointerEvents into PointerEvents and PointerId.
- PointerId protection is disabled for Android.
- WidgetEvents emit non-primary mouse events on Android because any touch other than 1nd touch is considered non-primary
- Sets maximum touch points to 5 on Android
Differential Revision: https://phabricator.services.mozilla.com/D221241
Now that navigator.platform has been frozen on the Android and Linux/etc, SPOOFED_PLATFORM can be removed because the old spoofed values match the new frozen values for all platforms: Windows, macOS, Android, and Linux/etc.
Even though navigator.platform's default and spoofed values are always the same, this change keeps RFPTarget::NavigatorPlatform enum value so we know whether to honor the "general.platform.override" pref: the pref should override the default platform, but the spoofed platform should override the pref.
Depends on D220360
Differential Revision: https://phabricator.services.mozilla.com/D220361
This pref was added in Firefox 123 (by bug 1861847) to:
1. Reduce fingerprintable entropy exposed to web content.
2. Reduce risk of webcompat problems from unexpected CPU architectures (such as ARM64 Linux YouTube bug 1869521).
Now that this pref has baked in the Release channel for seven months without known regressions, we can remove the pref and simplify some UA string code.
Differential Revision: https://phabricator.services.mozilla.com/D220360
This patch removes test_iframe.html. We remove it because the newly introduced test covers the tests done in that test. The reason for removing it in the first place is now that screen properties are inherited/spoofed xorigin, we get a 4px difference. The reasosn for 4px difference is the test runner runs tests in an iframe with a 2px border on each side.
Differential Revision: https://phabricator.services.mozilla.com/D215509
As H264/yuv444p is supported now on Linux we need a different video format which fails to decode.
VP9/gbrp12le seems to be exotic enough.
Depends on D217089
Differential Revision: https://phabricator.services.mozilla.com/D217090
As H264/yuv444p is supported now on Linux we need a different video format which fails to decode.
VP9/gbrp12le seems to be exotic enough.
Depends on D217089
Differential Revision: https://phabricator.services.mozilla.com/D217090
These did nothing at the OS level on most OSes (see previous patch), and
were only used on tests, so just remove them.
Note that these were different from the alwaysontop feature, which
remains and is used for stuff like picture-in-picture.
Differential Revision: https://phabricator.services.mozilla.com/D214091
For the first test, the parent is a page and the child is an iframe, but
eventually we will have tests for lots of different children types.
We test that the number of pixels we expect to be randomized are, and
we also compare the differences between the parent and child.
This allows us to ensure that the FPP key is being propagated correctly.
Differential Revision: https://phabricator.services.mozilla.com/D205917
This test is a little odd because (a) its name is super long and unhelpful
(b) it's testing a very important sitation we've regressed on before
(c) it _disables_ the protections, so you actually don't expect anything
to be enabled.
We're going to need a very similar version of this test where the
protections are _enabled_, so let's pre-emptively rename this one to
prepare for that.
Differential Revision: https://phabricator.services.mozilla.com/D206018
It turns out that we had the override string wrong, but we
didn't notice because we happened to be only testing things
where it was supposed to be disabled anyway.
There was a test where this would have not been the case
(simplePBMFPPTest) - but this was only be tested when we were
_exempting_ it with ETP.
I added this scenario to a place where it would be tested
positively, and confirmed that it failed, then when I fixed
the override, started working again.
Differential Revision: https://phabricator.services.mozilla.com/D205913
Chrome's Android UA string lists "Linux; Android", while Firefox's lists only "Android". This has caused webcompat problems for at least one website (samsung.com) because it assumes every browser UA string will include one of "Windows", "Mac", or "Linux". Let's add "Linux; Android" to Firefox's UA string, like Chrome's, to satisfy that website assumption.
Firefox's current Android UA string:
`Mozilla/5.0 (Android 10; Mobile; rv:125.0) Gecko/125.0 Firefox/125.0`
Firefox's new Android UA string:
`Mozilla/5.0 (Linux; Android 10; Mobile; rv:125.0) Gecko/125.0 Firefox/125.0`
For comparison, an example of Chrome's Android UA string:
`Mozilla/5.0 (Linux; Android 10; K) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Mobile Safari/537.36`
Differential Revision: https://phabricator.services.mozilla.com/D202653
