We have a range that starts at the end of a cell, and ends somewhere else.
We were bailing out recursively from the beginning, causing the serialization to
be the empty string rather than the actually selected text.
Differential Revision: https://phabricator.services.mozilla.com/D42495
--HG--
extra : moz-landing-system : lando
The test starts to fail more often with Fission session history (which is still using sync IPC).
The change should guarantee that there is time to send and receive options-loaded message.
Differential Revision: https://phabricator.services.mozilla.com/D42574
--HG--
extra : moz-landing-system : lando
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
Now that the private slot accessors already handle `undefined`, we might as
well keep the initial value instead of manually setting the slots to nullptr.
Differential Revision: https://phabricator.services.mozilla.com//D41946
--HG--
extra : histedit_source : 3b9c630abdb7ef2fdb0188f6f715606be8f82984
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
ScreenPixels would be a more appropriate unit. But inside BasicCompositor everything
is in the same coordinate space anyway so we're not getting much benefit from the
units. This patch eliminates a lot of .ToUnknown*() calls.
Differential Revision: https://phabricator.services.mozilla.com/D41680
--HG--
extra : moz-landing-system : lando
The null is unnecessary because mDrawTarget is already null-checked above:
If mTarget is non-null, then mDrawTarget = mTarget so mDrawTarget is non-null.
If mTarget is null, then we would enter a branch that had another null check
for mDrawTarget.
As for the assertion: When rendering to an external target (reftests),
LayerManagerComposite always sets the invalid region to the entire window, so it
should never be empty here.
Differential Revision: https://phabricator.services.mozilla.com/D41677
--HG--
extra : moz-landing-system : lando
There was an interesting "ExpandToEnclose(IntPoint(0, 0))" call in
CreateRenderTargetForWindow that snuck in some surprising behavior that this
change makes a bit more visible.
Differential Revision: https://phabricator.services.mozilla.com/D41676
--HG--
extra : moz-landing-system : lando
In the past, BeginFrame would clip mDrawTarget to the invalid region and then have
CreateRenderTargetForWindow clear a rectangle. So it was effectively clearing a
region, but only if BeginFrame's region clip happened to be set on the correct
DrawTarget. In the case where a back buffer was used, this was not the case:
The clip would be on mDrawTarget but the clear would happen on the back buffer
draw target. So we were clearing more than necessary.
Now we limit clearing to the invalid region even if a back buffer is used.
Differential Revision: https://phabricator.services.mozilla.com/D41675
--HG--
extra : moz-landing-system : lando
On Windows, where the DrawTarget is rewrapped in a Cairo/pixman DrawTarget,
this will now cause Cairo/pixman to be used for the clear.
Differential Revision: https://phabricator.services.mozilla.com/D41673
--HG--
extra : moz-landing-system : lando
This should be equivalent to what we had before but clearer.
Before this patch, we would reallocate the back buffer if
- the back buffer was larger than the client size (meaning the window had shrunk) or
- the invalid region didn't fit in the back buffer.
Whenever the window is resized, we have a frame where the invalid region covers
the entire window, and thus size would be equal clientSize in that frame.
So effectively, the back buffer size was always kept in sync with the client size.
Differential Revision: https://phabricator.services.mozilla.com/D41671
--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
