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
This was needed before, since we used to optimize empty style rules away
(and thus we could get confused between the important and non-important
block for two different elements).
But now we always keep them, and thus there's no way for the same
declaration block to appear in two similar paths of the rule tree
without different cascade levels.
I found this because if we want to implement the revert-layer CSS-wide
keyword, we need to put the layer order in the rule tree. However the
same thing applies: The same style source will always have the same
layer for a given cascade-data rebuild, so I believe this should be
fine.
Differential Revision: https://phabricator.services.mozilla.com/D124740
Without this, server side target were breaking stack record in the memory panel.
We have to ensure toggling stack record ON before the page starts loading.
Differential Revision: https://phabricator.services.mozilla.com/D124823
We were correctly tracking the top toolbox document, while ignoring any of its children document,
which are all having about:blank location when processed by the allocation tracker.
While I can't easily add coverage for this particular code,
I'm adding some more coverage around the leak scripts.
Differential Revision: https://phabricator.services.mozilla.com/D125413
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
criss
Jonathan Kew
Harry Twyford
Niklas Goegge
Micah Tigley
Katherine Patenio
Alexandre Poirot
Manuel Bucher
Tooru Fujisawa
Emilio Cobos Álvarez
hxu
Drew Willcoxon
colin_czb
Narcis Beleuzu
André Bargull
Henrik Skupin
Mirko Brodesser
Jon Coppeard
Valentin Gosu
Mark Banner
Sylvestre Ledru
Timothy Nikkel