This field used to match "LocalTZA" from the ECMAScript specification when "LocalTZA"
was still a constant value. But in the current specification "LocalTZA" was changed to
a function to compute the local time zone adjustment at a given time. To avoid
confusion between `localTZA_` and "LocalTZA" from the specification, remove `localTZA_`
and instead only expose the `DateTimeInfo::localTZA()` function in contexts where the
old "LocalTZA" definition is still used (non-Intl or system ICU builds).
`localTZA_` was also used as a cache key for `DateObject` slots, replace the usage there
with `DateTimeInfo::utcToLocalStandardOffsetSeconds()` to make clear that the cache key
isn't tied to any spec calls to "LocalTZA".
Differential Revision: https://phabricator.services.mozilla.com/D41375
--HG--
extra : moz-landing-system : lando
Give these functions and fields a more general name to make clear they aren't tied
to the `localTZA_` field.
Differential Revision: https://phabricator.services.mozilla.com/D41373
--HG--
extra : moz-landing-system : lando
Part 1 ensures `DateTimeInfo::updateTimeZoneAdjustment()` is no longer called during
start-up, which enables us to resync ICU's time zone status right away. Furthermore
this change won't lead to a performance regression, because all callers to
`DateTimeInfo::updateTimeZoneAdjustment()` either also require an up-to-date ICU time
zone state (`DTI::{getDSTOffsetMilliseconds,getOffsetMilliseconds,timeZoneDisplayName}`)
or trigger an ICU time zone update anyway (`DTI::localTZA()` when called in
`DateObject::fillLocalTimeSlots()`).
Differential Revision: https://phabricator.services.mozilla.com/D41372
--HG--
extra : moz-landing-system : lando
That way `js::ResetTimeZoneInternal` is calling `js::DateTimeInfo::resetTimeZoneAdjustment`,
which aligns the use of 'reset' in the function names. And the method which actually checks
for updates is then called `js::DateTimeInfo::updateTimeZoneAdjustment`.
Differential Revision: https://phabricator.services.mozilla.com/D37250
--HG--
extra : moz-landing-system : lando
This ensures the ICU time zone state is only resync'ed when an actual time zone
change was detected. Without this change the following script will resync the
ICU time zone state in each call to Intl.DateTimeFormat:
```
// js::DateTimeInfo is here in its initial state where no time zone info has
// been retrieved yet.
for (var i = 0; i < 10; ++i) {
// Creating a new Realm triggers a time zone check. Because no time zone
// info is yet available, a forced reset of the ICU time zone state is
// requested.
newGlobal();
// The ICU time zone state was just resetted above, so this call will again
// fetch the current system time zone.
new Intl.DateTimeFormat();
}
```
Differential Revision: https://phabricator.services.mozilla.com/D37248
--HG--
extra : moz-landing-system : lando
- Changes `DateTimeInfo::internalUpdateTimeZoneAdjustment` to set a flag to
request an update instead of directly calling the system time functions.
- DateTimeInfo functions which require a valid time zone have been modified to
call the new `acquireLockWithValidTimeZone` helper.
Differential Revision: https://phabricator.services.mozilla.com/D37247
--HG--
extra : moz-landing-system : lando
webextensions now uses "browser_specific_settings" instead of "applications" in
the manifest file. This patch make mozprofile look for both places.
Differential Revision: https://phabricator.services.mozilla.com/D42457
--HG--
extra : moz-landing-system : lando
Depends on D40995
I get a 10% failure rate on try for those two tests, but I haven't managed to get
a single failure locally so I couldn't identify the root cause yet. I would like
to fix them in a follow up.
Differential Revision: https://phabricator.services.mozilla.com/D40997
--HG--
extra : moz-landing-system : lando
Depends on D40994
Switching hosts (especially going from docked to window) seems more async than before.
I would like to work on fixing those in a follow up.
Differential Revision: https://phabricator.services.mozilla.com/D40995
--HG--
extra : moz-landing-system : lando
Depends on D40993
I don't fully understand the failures in this test on Linux.
The only way I could get it to pass for now was to force a window focus when the test runs in a window host.
Other OSes are fine, but without this, Linux is permafailing this.
I don't have a good linux env right now, so I would like to proceed with this and
fix it in a follow up.
Differential Revision: https://phabricator.services.mozilla.com/D40994
--HG--
extra : moz-landing-system : lando
Depends on D40992
In general, using `click()` seems less reliable when using a frame with type=content. I am not entirely sure why since the context menu is supposed to be created in the top window anyway
Differential Revision: https://phabricator.services.mozilla.com/D40993
--HG--
extra : moz-landing-system : lando
Depends on D40991
This test had some suspicious calls to async methods without await. Properly waiting on them avoids frequent intermittents when running in a content frame.
Differential Revision: https://phabricator.services.mozilla.com/D40992
--HG--
extra : moz-landing-system : lando
Depends on D40989
I though I fixed this a few months ago, but there are still timing issues with the current test when using a frame with type=content.
Differential Revision: https://phabricator.services.mozilla.com/D40990
--HG--
extra : moz-landing-system : lando
Depends on D40988
This is not explicitly needed in this queue but I noticed this issue
while working on eyedropper test issues.
The top window might change when switching from docked to window hosts
so we should rather attach shortcut events to the regular window.
Differential Revision: https://phabricator.services.mozilla.com/D40989
--HG--
extra : moz-landing-system : lando
This introduces a preference to load the DevTools toolbox
in a frame with type=content instead of type=chrome.
Having a preference will allow to keep the previous behavior in a
few intermittent tests, while we collect feedback on Nightly.
Differential Revision: https://phabricator.services.mozilla.com/D40988
--HG--
extra : moz-landing-system : lando
When the console parent actor is a ContentProcessTargetActor, we don't have
a reference to a `nsIDOMWindow`, but only to a Sandbox.
The code in `hasNativeConsoleAPI` would then silently fail when trying to
access `window.wrappedJSObject`, and keep `isNative` as `false`.
For now, we work around this by always returning true if we don't have
access to a `nsIDOMWindow`.
Differential Revision: https://phabricator.services.mozilla.com/D42506
--HG--
extra : moz-landing-system : lando
Sadly the badge title wasn't localized at all, so we add a new
l10n string and use it in the component.
Differential Revision: https://phabricator.services.mozilla.com/D42517
--HG--
extra : moz-landing-system : lando
Corroborator.jsm no longer causes file I/O on early startup before user input is possible.
Depends on D41693
Differential Revision: https://phabricator.services.mozilla.com/D42585
--HG--
extra : moz-landing-system : lando
