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
The main goal of these bugs is to move markers to a new storage, so I'm adding
lots of markers to TestBaseProfiler.
Also adding labels, easier to read unsymbolicated profiles, and gives a bit more
coverage too.
And adding a separate "fibonacci canceller" thread, which is needed on some
slower platforms (e.g., Linux 64 ASAN times out otherwise); as a bonus, this
tests AUTO_BASE_PROFILER_REGISTER_THREAD.
Differential Revision: https://phabricator.services.mozilla.com/D42448
--HG--
extra : moz-landing-system : lando
Updating parking_lot would allow us to avoid dependency duplication when WebGPU tree is vendored.
Differential Revision: https://phabricator.services.mozilla.com/D42557
--HG--
rename : third_party/rust/parking_lot_core/src/thread_parker/wasm.rs => third_party/rust/parking_lot_core/src/thread_parker/wasm_atomic.rs
extra : moz-landing-system : lando
`HTMLEditRules::mReturnInEmptyLIKillsList` stores value of
`editor.html.typing.returnInEmptyListItemClosesList` at construction, and it's
set to true unless the pref value is `"false"`. However, this pref isn't
registered in anywhere (all.js, firefox.js, etc) nor used in comm-central
and BlueGriffon.
Even if I search the pref in the web, I don't see any information so that
this hidden pref must not be used anybody. Therefore, this patch just removes
this member.
Differential Revision: https://phabricator.services.mozilla.com/D42262
--HG--
extra : moz-landing-system : lando
This patch includes a logic change. `HTMLEditRules::mListenerEnabled` is used
for storing 2 state. One is that whether `HTMLEditRules` can handle the legacy
listener methods (they came from `nsIEditActionListener`) with `mHTMLEditor` or
not. The other is that whether current edit sub-action handler temporarily
disables the listeners for performance or not.
For the former, we can check same result with `HTMLEditRules::mInitialized`
and `HTMLEditRules::mHTMLEditor`.
However, the latter, current design is obviously wrong. Currently,
`HTMLEditRules::mListenerEnabled` is set only to `false` temporarily from
`WillInsertText()`, but the state will be affected to other edit sub-actions
which are nested by mutation event listeners. So, currently,
`HTMLEditRules::mDocChangeRange` may not contain modified range caused by
nested edit sub-actions.
For solving this bug, this patch moves it into `EditSubActionData` rather
than `HTMLEditor` and `TopLevelEditSubActionData`.
Differential Revision: https://phabricator.services.mozilla.com/D42107
--HG--
extra : moz-landing-system : lando
The members of `HTMLEditRules` which are used only while `WillDoAction()` and
`DidDoAction()` are called should be moved to specific stack only struct
`EditorBase::EditSubActionData`.
Differential Revision: https://phabricator.services.mozilla.com/D42106
--HG--
extra : moz-landing-system : lando
`HTMLEditRules::mUtilRange` is used only for the argument of
`HTMLEditRules::UpdateDocChangeRange()`. However, it does not need to be
a range instance since it compares its start and
`TopLevelEditSubAction::mChangedRange->StartRef()`, and its end and
`TopLevelEditSubAction::mChangedRange->EndRef()`. Therefore, with rewriting
it as taking 2 `EditorRawDOMPoint`s, we don't need `mUtilRange`.
Differential Revision: https://phabricator.services.mozilla.com/D42105
--HG--
extra : moz-landing-system : lando
This patch makes `StyleCache` not inherit `ItemProp` because `MOZ_COUNT_CTOR`
and `MOZ_COUNT_DTOR` do not work well with `AutoTArray` and there is no reason
to do that since nobody treat `StyleCache` instance with `ItemProp` pointer.
Differential Revision: https://phabricator.services.mozilla.com/D42103
--HG--
extra : moz-landing-system : lando
For avoiding allocation cost of `RangeItem`, it should be stored by `HTMLEditor`
and reused by all `TopLevelEditSubActionData` instances for the editor instance.
Differential Revision: https://phabricator.services.mozilla.com/D42102
--HG--
extra : moz-landing-system : lando
