1486455 - Custom element registry should do memory reporting

Status: NEW

(Core :: DOM: Core & HTML, enhancement, P2)

Description

[Boris Zbarsky [:bzbarsky]]

Some testcases coming up that show the need for it.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase for registerElement

This testcase ends up with a bunch of heap-unclassified with stacks like:

    #01: replace_malloc(unsigned long) (DMD.cpp:1267, in libmozglue.dylib)
    #02: mozilla::detail::HashTable::changeTableSize (Utility.h:387, in XUL)
    #03: bool mozilla::detail::HashTable::add<JS::Rooted<JSObject*>&, RefPtr<nsAtom>&> (HashTable.h:2188, in XUL)
    #04: bool mozilla::HashMap::put<JS::Rooted<JSObject*>&, RefPtr<nsAtom>&> (HashTable.h:352, in XUL)
    #05: mozilla::dom::CustomElementRegistry::Define(JSContext*, nsTSubstring<char16_t> const&, mozilla::dom::Function&, mozilla::dom::ElementDefinitionOptions const&, mozilla::ErrorResult&) (CustomElementRegistry.cpp:961, in XUL)

and

    #01: replace_calloc(unsigned long, unsigned long) (DMD.cpp:1282, in libmozglue.dylib)
    #02: PLDHashTable::ChangeTable(int) (PLDHashTable.cpp:0, in XUL)
    #03: PLDHashTable::Add(void const*, std::nothrow_t const&) (PLDHashTable.cpp:0, in XUL)
    #04: mozilla::dom::CustomElementRegistry::Define(JSContext*, nsTSubstring<char16_t> const&, mozilla::dom::Function&, mozilla::dom::ElementDefinitionOptions const&, mozilla::ErrorResult&) (nsRefPtrHashtable.h:179, in XUL)

and

    #01: replace_malloc(unsigned long) (DMD.cpp:1267, in libmozglue.dylib)
    #02: moz_xmalloc (mozalloc.cpp:71, in libmozglue.dylib)
    #03: mozilla::dom::CustomElementRegistry::Define(JSContext*, nsTSubstring<char16_t> const&, mozilla::dom::Function&, mozilla::dom::ElementDefinitionOptions const&, mozilla::ErrorResult&) (mozalloc.h:136, in XUL)

and

    #01: replace_malloc(unsigned long) (DMD.cpp:1267, in libmozglue.dylib)
    #02: moz_xmalloc (mozalloc.cpp:71, in libmozglue.dylib)
    #03: mozilla::dom::CustomElementDefinition::CustomElementDefinition(nsAtom*, nsAtom*, int, mozilla::dom::Function*, nsTArray<RefPtr<nsAtom> >&&, mozilla::UniquePtr<mozilla::dom::LifecycleCallbacks, mozilla::DefaultDelete<mozilla::dom::LifecycleCallbacks> >&&) (mozalloc.h:136, in XUL)
    #04: mozilla::dom::CustomElementRegistry::Define(JSContext*, nsTSubstring<char16_t> const&, mozilla::dom::Function&, mozilla::dom::ElementDefinitionOptions const&, mozilla::ErrorResult&) (RefPtr.h:112, in XUL)

Comment 2

[Boris Zbarsky [:bzbarsky]]

I haven't figured out a testcase for the second situation I saw yet, but in a Firefox chrome process I see ~4MB of unreported memory allocated with this stack:

    #01: replace_calloc(unsigned long, unsigned long) (DMD.cpp:1282, in libmozglue.dylib)
    #02: PLDHashTable::ChangeTable(int) (PLDHashTable.cpp:0, in XUL)
    #03: PLDHashTable::Add(void const*, std::nothrow_t const&) (PLDHashTable.cpp:0, in XUL)
    #04: PLDHashTable::Add(void const*) (PLDHashTable.cpp:619, in XUL)
    #05: mozilla::dom::CustomElementRegistry::RegisterUnresolvedElement(mozilla::dom::Element*, nsAtom*) (nsCOMPtr.h:312, in XUL)
    #06: nsContentUtils::TryToUpgradeElement(mozilla::dom::Element*) (RefPtr.h:112, in XUL)
    #07: mozilla::dom::Element::BindToTree(nsIDocument*, nsIContent*, nsIContent*) (Element.cpp:0, in XUL)
    #08: nsXULElement::BindToTree(nsIDocument*, nsIContent*, nsIContent*) (nsXULElement.cpp:687, in XUL)

Comment 3

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase for unresolved elements

Just need to not remove them from the DOM...

Comment 4

[Boris Zbarsky [:bzbarsky]]

I ran into that upgrade candidate thing because we add every single XUL element to that hashtable, due to nsContentUtils::IsCustomElementName always returning true for XUL.