I see a lot of SVG documents being created through the following path: #0 0x00007f2711b15374 in NS_NewSVGDocument(nsIDocument**) (aInstancePtrResult=0x7ffe76493210) at /home/billm/ws/gecko/dom/svg/SVGDocument.cpp:171 #1 0x00007f2712436642 in CreateSVGDocument(nsISupports*, nsID const&, void**) (aOuter=<optimized out>, aIID=..., aResult=0x7ffe764932b0) at /home/billm/ws/gecko/layout/build/nsLayoutModule.cpp:454 #2 0x00007f270fc2892c in nsComponentManagerImpl::CreateInstance(nsID const&, nsISupports*, nsID const&, void**) (this=<optimized out>, aClass=..., aDelegate=0x0, aIID=..., aResult=0x7ffe764932b0) at /home/billm/ws/gecko/xpcom/components/nsComponentManager.cpp:1021 #3 0x00007f270fc2a3f1 in nsCreateInstanceByCID::operator()(nsID const&, void**) const (this=0x7ffe764932e0, aIID=..., aInstancePtr=0x7ffe764932b0) at /home/billm/ws/gecko/xpcom/components/nsComponentManagerUtils.cpp:183 #4 0x00007f2710b385b9 in nsCOMPtr<nsIDocument>::assign_from_helper(nsCOMPtr_helper const&, nsID const&) (this=0x7ffe76493318, helper=..., aIID=...) at /home/billm/ws/gecko/objdir-ff-dbgopt/dist/include/nsCOMPtr.h:1185 #5 0x00007f2712434ec0 in nsContentDLF::CreateDocument(char const*, nsIChannel*, nsILoadGroup*, nsIDocShell*, nsID const&, nsIStreamListener**, nsIContentViewer**) (this=0x7ffe76493318, aHelper=...) at /home/billm/ws/gecko/objdir-ff-dbgopt/dist/include/nsCOMPtr.h:574 #6 0x00007f2712434ec0 in nsContentDLF::CreateDocument(char const*, nsIChannel*, nsILoadGroup*, nsIDocShell*, nsID const&, nsIStreamListener**, nsIContentViewer**) (this=<optimized out>, aCommand=0x7f27143c868b "external-resource", aChannel=0x7f26f4ed5080, aLoadGroup=0x7f26f05f3cd0, aContainer=0x0, aDocumentCID=..., aDocListener=0x7ffe76493324, aContentViewer=0x7ffe76493324) at /home/billm/ws/gecko/layout/build/nsContentDLF.cpp:363 #7 0x00007f2712434be7 in nsContentDLF::CreateInstance(char const*, nsIChannel*, nsILoadGroup*, nsACString const&, nsIDocShell*, nsISupports*, nsIStreamListener**, nsIContentViewer**) (this=<optimized out>, aCommand=0x7f27143c868b "external-resource", aChannel=0x7f26f4ed5080, aLoadGroup=0x7f26f05f3cd0, aContentType=..., aContainer=0x0, aExtraInfo=0x0, aDocListener=0x7ffe76493570, aDocViewer=0x7ffe76493580) at /home/billm/ws/gecko/layout/build/nsContentDLF.cpp:183 #8 0x00007f2710aa4ee2 in mozilla::image::SVGDocumentWrapper::SetupViewer(nsIRequest*, nsIContentViewer**, nsILoadGroup**) (this=<optimized out>, aRequest=<optimized out>, aViewer=<optimized out>, aLoadGroup=<optimized out>) at /home/billm/ws/gecko/image/SVGDocumentWrapper.cpp:344 #9 0x00007f2710aa4b5b in mozilla::image::SVGDocumentWrapper::OnStartRequest(nsIRequest*, nsISupports*) (this=0x7f26f35f6650, aRequest=0x7f26f4ed5080, ctxt=<optimized out>) at /home/billm/ws/gecko/image/SVGDocumentWrapper.cpp:239 #10 0x00007f2710aaa58d in mozilla::image::VectorImage::OnStartRequest(nsIRequest*, nsISupports*) (this=0x7f26f3be2080, aRequest=0x7f26f4ed5080, aCtxt=<optimized out>) at /home/billm/ws/gecko/image/VectorImage.cpp:1172 #11 0x00007f2710a93da3 in mozilla::image::ImageFactory::CreateVectorImage(nsIRequest*, mozilla::image::ProgressTracker*, nsCString const&, mozilla::image::ImageURL*, unsigned int, unsigned int) (aRequest=0x7f26f4ed5080, aProgressTracker=<optimized out>, aMimeType="image/svg+xml", aURI=0x7f26e5745400, aImageFlags=1, aInnerWindowId=2147483652) at /home/billm/ws/gecko/image/ImageFactory.cpp:260 #12 0x00007f2710a93c82 in mozilla::image::ImageFactory::CreateImage(nsIRequest*, mozilla::image::ProgressTracker*, nsCString const&, mozilla::image::ImageURL*, bool, unsigned int) (aRequest=0x7f26f4ed5080, aProgressTracker=0x7f26f1b3e280, aMimeType="image/svg+xml", aURI=<optimized out>, aIsMultiPart=false, aInnerWindowId=<optimized out>) at /home/billm/ws/gecko/image/ImageFactory.cpp:97 The problem is the the DocGroup is not being set, so any runnables dispatched to this document end up being unlabeled. In my testing, this can be a big source of unlabeled runnables (hundreds on nytimes.com). Olli, do you have any idea how we could make this work? I'm not familiar with this path at all.

These are SVG-as-images documents. IIRC those can be shared between documents, so there isn't necessarily any clear correct docgroup. dholbert might recall the sharing model. How will this all work with animated images (which can be shared between documents)? I think the issue here is similar.

Yeah, SVG Images can be used (& hence "belong") to many tabs (which I'll call "clients") simultaneously, or to no tabs. (if they're in the cache) These images also have scripting disabled. Not sure if that's relevant here RE these runnables. > How will this all work with animated images (which can be shared between documents)? I think the issue here is similar. We update & invalidate animated images based on their client documents' refresh driver ticks. Each time a client's refresh driver ticks, it calls requestRefresh() on each of its animated images [which might be shared with another client]. That image then updates its rendering accordingly & triggers invalidation of all its clients. (Side note: this may cause over-invalidation if an image is shared among many refresh drivers simultaneously, but in practice that doesn't happen, and it was a large improvement over each image having its own timer, which is what we used to do)

P1 as this is a blocker for qdom, according to Bill's comment "In my testing, this can be a big source of unlabeled runnables (hundreds on nytimes.com)."

Is this still a problem, Bill?

I think it's still an issue, but it doesn't need to be P1.

Thanks.

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information