The only test that still needs it is browser_tab_manager_visibility.js.
The rest look like proton leftovers.
After bug 1729477 those sheets are stored in the shared style sheet
cache, not in the XUL prototype cache, so remove that.
Differential Revision: https://phabricator.services.mozilla.com/D124983
With a very simple tweak to SheetLoadDataHashKey::KeyEquals we should
get the same kind of caching but in a much simpler way.
Depends on D125450
Differential Revision: https://phabricator.services.mozilla.com/D124807
This fixes a leak that my previous patch uncovers. See comment 9 for the
diagnostic, I had missed mRequestingNode in comment 10.
The observer change is not technically necessary but since observers can
theoretically keep alive random stuff as well, clean them up as well.
In particular, clear mOwningNode after we've fired load / error events
(which is what we need it for), and mRequestingNode once we call
LoadComplete, where it is no longer useful.
Differential Revision: https://phabricator.services.mozilla.com/D125450
Also make some other context-menu code a lot more straight-forward, and
remove some enabledness checks now that shadow dom can't be disabled.
Differential Revision: https://phabricator.services.mozilla.com/D125487
It turns out this assertion (added as part of bug 1725555) is not necessarily valid.
When we're updating the frame tree in response to DOM modifications (in the testcase
here, we're under nsCSSFrameConstructor::ContentRemoved), we may call DeleteFrom on
the primary textFrame first, which results in calling SetPrevInFlow(nullptr) on its
nextContinuation; this in turn clears the mFirstContinuation back-pointers in all
the successors. But if we then call DeleteFrom on one of the continuations later
in the chain, those nulled-out pointers trigger this assertion. In fact, it's OK
for them to be null in this case, so the assertion is over-zealous and we should
drop it.
I believe the only time it's OK for this to happen is if the chain of nsContinuingTextFrames
has been "detached" from the primary frame during frame-tree updating, as has happened in
this example.
We can still sanity-check the mFirstContinuation pointer here by asserting that it
matches the FirstContinuation() reported by our prev-continuation, or is null if there
is no prev-continuation. This is a bit expensive, though, so it's a only a debug-mode
assertion (for the fuzzers to try and hit).
Differential Revision: https://phabricator.services.mozilla.com/D125444
Rewrite `mozIntl.getDisplayNames` to use `mozIntl.DisplayNames`, so we can use
it for `intlUtils.getDisplayNames`, which doesn't have direct access to
`mozIntl.DisplayNames`.
This change will allow to remove `getDisplayNames` from SpiderMonkey in a later
patch in this stack.
Differential Revision: https://phabricator.services.mozilla.com/D76117
Expose `Intl.DisplayNames` to `mozIntl`. The exposed `Intl.DisplayNames` version
supports date-time types, which have been removed from the spec proposal, but
may be re-enabled at some point in the future.
The existing `getDisplayNames` WebIDL function had to be renamed, because WebIDL
doesn't allow specify an attribute named `DisplayNames` and a separate function
called `getDisplayNames`.
Drive-by change:
- Removed an out-dated comment in "mozIMozIntlHelper.idl" which mentioned calling
`addDateTimeFormatConstructor` twice throws an error.
Differential Revision: https://phabricator.services.mozilla.com/D76114
As a non-standard extension, add the "abbreviated" style to be able to select
CLDR's abbreviated format. This style is used by the DateTimePicker component
for weekdays.
Differential Revision: https://phabricator.services.mozilla.com/D125174
Previously we did this calculation after marking all the roots that doesn't
work any more. This handles setting the maybeAlive flag based on gray root
marking after that happens for each sweep group, and moves the calculation of
the compartments expected to die to the end of sweeping.
Depends on D125188
Differential Revision: https://phabricator.services.mozilla.com/D125380
This removes gray root buffering from the first marking slice and traces the
gray roots directly in a later slice. This relies on Heap<T> read barriers
being sufficient to ensure correctness.
This is conservative in that it makes no effort to skip tracing roots added
after the start of GC. It also doesn't trace roots removed after the start of
GC, but this is OK because barriers ensure marking of any observed values.
The gray root tracing callback will be called once per sweep group, which means
we will trace all zone holders and xpconnect gray roots for every group rather
than just once. This should not be a problem in practice as we expect the
number of zones and hence zone groups to decrease with fission.
On the plus side we no longer have to do a virtual dispatch per root traced
(for the buffering tracer), allocate memory for the buffer, or trace each root
twice.
Note that this doesn't make the gray root marking itself incremental yet.
Differential Revision: https://phabricator.services.mozilla.com/D125188
Rewrite `mozIntl.getDisplayNames` to use `mozIntl.DisplayNames`, so we can use
it for `intlUtils.getDisplayNames`, which doesn't have direct access to
`mozIntl.DisplayNames`.
This change will allow to remove `getDisplayNames` from SpiderMonkey in a later
patch in this stack.
Differential Revision: https://phabricator.services.mozilla.com/D76117
Expose `Intl.DisplayNames` to `mozIntl`. The exposed `Intl.DisplayNames` version
supports date-time types, which have been removed from the spec proposal, but
may be re-enabled at some point in the future.
The existing `getDisplayNames` WebIDL function had to be renamed, because WebIDL
doesn't allow specify an attribute named `DisplayNames` and a separate function
called `getDisplayNames`.
Drive-by change:
- Removed an out-dated comment in "mozIMozIntlHelper.idl" which mentioned calling
`addDateTimeFormatConstructor` twice throws an error.
Differential Revision: https://phabricator.services.mozilla.com/D76114
As a non-standard extension, add the "abbreviated" style to be able to select
CLDR's abbreviated format. This style is used by the DateTimePicker component
for weekdays.
Differential Revision: https://phabricator.services.mozilla.com/D125174
The motivation of this patch is to remove rarely used API in
WordBreaker. WordBreaker::BreakInBetween() is used only in
nsFind::BreakInBetween() in production, and it can be replaced by
Next().
If the user wants to know whether there is a word break between two
strings such as the use cases in gtest, joining the two strings and
passing the result to Next() is the preferred way.
Note: I delete the buggy forward word search algorithm in
TestFindWordBreakFromPosition() because from the test expectations, it
doesn't expect to continue the search in previous fragments. Also, the
buggy part comes from the following code, which had undefined behavior
before Part 4, and does nothing after Part 4.
```
wbk->FindWord(prevFragText.get(), prevFragText.Length(), prevFragText.Length());
```
Differential Revision: https://phabricator.services.mozilla.com/D125151
* Rename arguments so that their names are consistent with Next().
* Make the function not assert on an empty string, i.e. aLen == 0, like
Next().
* Fix an undefined behavior when the user passes aTextLen == aOffset.
The methods used to access `aText[aOffset]` that is clearly out of range
because the string may not be null-terminated. After this patch, it
returns a sentinel WordRange when aLen == aPos.
* Add document and gtest TestFindWordWithEmptyString().
* Change the sentinel return value to {aLen,aLen} for FindWord(), and
adapt one caller.
Differential Revision: https://phabricator.services.mozilla.com/D125434
nextChar gets its value from DecodeChar() and PeekNextChar(), and both
functions return char32_t. It also passes as a char32_t argument to
BreakInBetween(). Therefore it really should have 32 bits to avoid
potential truncation.
Differential Revision: https://phabricator.services.mozilla.com/D125149
The function is added in Bug 1728708 Part 4, but it never get called, so
this patch transforms it into a test in WordBreak test suite to make it
run.
While I'm here, other individual functions are also transformed into
tests so that we can have more granular results if some of them failed.
Differential Revision: https://phabricator.services.mozilla.com/D125148
This should ensure the correct behavior when system colors are
semi-transparent, like on macOS on dark mode.
Testing this without hard-coding the system color seems hard (and I
think macOS on automation might not even hard native dark mode support
anyways).
In fact, if it did I think backplat-bg-image-006 would've caught it.
Differential Revision: https://phabricator.services.mozilla.com/D125475
colin_czb
Narcis Beleuzu
Emilio Cobos Álvarez
Jonathan Kew
André Bargull
criss
Henrik Skupin
Mirko Brodesser
Jon Coppeard
Valentin Gosu
Mark Banner
Sylvestre Ledru
Timothy Nikkel
Nika Layzell
Byron Campen
Ting-Yu Lin
Daniel Holbert
Morgan Reschenberg
Steve Fink