It was complaining about
"unrooted '<returnvalue>' of type 'JSObject*' live across GC call at dom/base/Element.cpp:588"
Where the GC call is:
Function '_ZN7mozilla3dom7Element10WrapObjectEP9JSContextN2JS6HandleIP8JSObjectEE$JSObject* mozilla::dom::Element::WrapObject(JSContext*, JS::Handle<JSObject*>)' has unrooted '<returnvalue>' of type 'JSObject*' live across GC call '_ZN6RefPtrI12nsXBLBindingED1Ev$RefPtr<T>::~RefPtr() [with T = nsXBLBinding]' at dom/base/Element.cpp:588
Element.cpp:588: Assign(64,65, return := __temp_29**)
Element.cpp:588: Call(65,66, binding.~__dt_comp ()) [[GC call]]
Element.cpp:588: Call(66,67, principal.~__dt_comp ())
Element.cpp:588: Call(67,68, uri.~__dt_comp ())
Element.cpp:588: Call(68,69, style.~__dt_comp ())
Element.cpp:588: Call(69,70, obj.~__dt_comp ())
Element.cpp:589: [[end of function]]
GC Function: _ZN6RefPtrI12nsXBLBindingED1Ev$RefPtr<T>::~RefPtr() [with T = nsXBLBinding]
RefPtr<T>::~RefPtr() [with T = nsXBLBinding] [[base_dtor]]
static void RefPtr<T>::ConstRemovingRefPtrTraits<U>::Release(U*) [with U = nsXBLBinding; T = nsXBLBinding]
static void mozilla::RefPtrTraits<U>::Release(U*) [with U = nsXBLBinding]
uint32 nsXBLBinding::Release()
uint64 nsCycleCollectingAutoRefCnt::decr(void*, nsCycleCollectionParticipant*, uint8*) [with void (* suspect)(void*, nsCycleCollectionParticipant*, nsCycleCollectingAutoRefCnt*, bool*) = NS_CycleCollectorSuspect3; uintptr_t = long unsigned int]
NS_CycleCollectorSuspect3
nsCycleCollector.cpp:void SuspectAfterShutdown(void*, nsCycleCollectionParticipant*, nsCycleCollectingAutoRefCnt*, uint8*)
nsCycleCollectionParticipant.DeleteCycleCollectable
void nsIContent::cycleCollection::DeleteCycleCollectable(void*)
nsIContent.DeleteCycleCollectable
unresolved nsIContent.DeleteCycleCollectable
I don't think the analysis is right since the Rooted<> thing will go out of the
scope after the RefPtr.
MANUAL PUSH: Bustage fix for broken (I think) analysis
People keep shooting themselves in the feet because of this codepath and writing
slow code.
There are just a few elements with bindings left, so just check those.
Also simplify a bit the code. The XUL element + tagname check should be pretty
fast now, and ComputedStyle objects no longer keep weak pointers to pres
contexts and such, so can be safely kept on a RefPtr across an style flush.
Differential Revision: https://phabricator.services.mozilla.com/D47995
--HG--
extra : moz-landing-system : lando
I'm not sure what if there's a preference either way, but all the other globals in nsJSEnvironement.cpp are static so I made the CycleCollectorStats global static too.
Differential Revision: https://phabricator.services.mozilla.com/D47919
--HG--
extra : moz-landing-system : lando
This needs to be defined before FireForgetSkippable for the subsequnt patches.
Differential Revision: https://phabricator.services.mozilla.com/D47918
--HG--
extra : moz-landing-system : lando
This mostly updates the bindings to the current state.
No actual logic backing them yet.
*Note*: the IDL does *not* need to be checked for matching the upstream spec precisely at this stage. The upstream is evolving, we just need to update in order to start integrating the implementation. What needs to be checked is - how C++ represents the IDL, esp with regards to derived classes, events, and hierarchies.
The trickiest points, arguably, are:
- WebGPU -> GPU prefix change
- the goop for interfaces that are not final
Differential Revision: https://phabricator.services.mozilla.com/D46166
--HG--
rename : dom/webgpu/InputState.cpp => dom/webgpu/DeviceLostInfo.cpp
rename : dom/webgpu/Fence.h => dom/webgpu/DeviceLostInfo.h
rename : dom/webgpu/BlendState.cpp => dom/webgpu/OutOfMemoryError.cpp
rename : dom/webgpu/LogEntry.h => dom/webgpu/OutOfMemoryError.h
rename : dom/webgpu/BindGroup.h => dom/webgpu/ProgrammablePassEncoder.cpp
rename : dom/webgpu/BlendState.cpp => dom/webgpu/RenderBundle.cpp
rename : dom/webgpu/BlendState.h => dom/webgpu/RenderBundle.h
rename : dom/webgpu/AttachmentState.cpp => dom/webgpu/ValidationError.cpp
rename : dom/webgpu/AttachmentState.h => dom/webgpu/ValidationError.h
extra : moz-landing-system : lando
Since unions can now end up a in binding header, it's only a problem when the
two dictionaries are in one header and the union is in a different one. If all
three are in the same header, for example, there is no issue.
Differential Revision: https://phabricator.services.mozilla.com/D47195
--HG--
extra : moz-landing-system : lando
Since unions can now end up a in binding header, it's only a problem when the
two dictionaries are in one header and the union is in a different one. If all
three are in the same header, for example, there is no issue.
Differential Revision: https://phabricator.services.mozilla.com/D47195
--HG--
extra : moz-landing-system : lando
AudioNodeStream is a subclass of MediaStream, which now exposes a
public const mSampleRate member.
Differential Revision: https://phabricator.services.mozilla.com/D47688
--HG--
extra : moz-landing-system : lando
This change mainly removes the `mTracks` member from MediaStream and moves all
associated members up a level, so that a MediaStream in practice represents a
single track.
Classes will be renamed in a future patch to reflect this.
Other changes include:
The new `mEnded` member of MediaStream changes meaning to only become true when
all data in the stream has been processed. It stems from
StreamTracks::Track::mEnded which used to become true as soon as the last bit of
data had been added to a track, and there could still be data in the track that
would get processed in future iterations. We are moving towards not having any
future data in tracks, which is why this change is ok to make -- keeping the old
behavior will soon not make sense.
TrackUnionStream is changed to no longer take a list of streams as input and
forward the union of their tracks to itself. Instead it's limited to having one
track as input at a time.
The autofinishing functionality that TrackUnionStream had before has been
transformed into an autoending functionality to allow it to defer ending until
its been told that it's ok to end through the control API. This lets a single
TrackUnionStream span the lifetime of multiple inputs, which will be useful for
making DecodedStream spec compliant with HTMLMediaElement::CaptureStream(), and
for implementing the currently discussed MediaRecorder::ReplaceTrack(), to name
a few potential use cases.
AudioNodeStreams used to only have a track (and thus an AudioSegment) if the
EXTERNAL_OUTPUT flag was enabled on them. With all MediaStreams now representing
a track, AudioNodeStreams inherently have an AudioSegment as a member. It is
however only used with data if the EXTERNAL_OUTPUT flag is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D45821
--HG--
extra : moz-landing-system : lando
The stream order does not depend on streams' finished state, so these calls are
unnecessary.
Differential Revision: https://phabricator.services.mozilla.com/D47687
--HG--
extra : moz-landing-system : lando
This functionality is not used since we moved to only having a single track per
MediaStream (bug 1493613).
Differential Revision: https://phabricator.services.mozilla.com/D47686
--HG--
extra : moz-landing-system : lando
TrackID has been used to denote tracks that are part of MediaStreams in the
MediaStreamGraph. The TrackInfo::mTrackId IDs are no longer used in the
MediaStream APIs and as such it's not necessary that they have the type TrackID.
This patch changes TrackInfo::mTrackId to be of type uint32_t instead, as that
is the type of Mp4parseTrackInfo::track_id, which is assigned to
TrackInfo::mTrackId as the sole remaining non-static user.
Other users set a static trackId of `1` or `2`, and as such remain supported by
this change.
Differential Revision: https://phabricator.services.mozilla.com/D46763
--HG--
extra : moz-landing-system : lando
This patch introduces the concept of a "future ClientSource" to the
ClientManagerService. A "future ClientSource" is registered/removed
from the ClientManagerService by
ClientManager::{Register,Forget}FutureClientSource and is required
when a ClientInfo is initially created without a backing ClientSource.
As a result, the ClientManagerService can distinguish between a
ClientSourceParent* that has yet to register itself with the
ClientManagerService and a ClientSourceParent* that has already
both registered and removed itself from the ClientManagerService.
Differential Revision: https://phabricator.services.mozilla.com/D47592
--HG--
extra : moz-landing-system : lando
