760135 - about:addons zombie compartments after enabling or disabling an add-on

Status: RESOLVED WORKSFORME

(Core :: XUL, defect)

Description

[Nicholas Nethercote [inactive]]

Steps to reproduce:

- Start Firefox

- Open about:addons

- Enable and/or disable an extension or plug-in

- Close about:addons and open about:compartments.  There's a zombie about:addons compartment present:

  [System Principal], about:addons


This doesn't manifest if you just open about:addons and then close it -- the enabling/disabling is necessary.  The zombie compartment is tiny -- 60KB on my machine -- but still shouldn't be present.

Comment 1

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Well, I'm confused. Based on my (admittedly late night) testing, the following from extensions.xul causes a zombie compartment:

<xul:button anonid="disable-btn" class="addon-control disable"
            label="&cmd.disableAddon.label;"
            oncommand="document.getBindingParent(this).userDisabled = true;"/>


As does this:

<xul:button anonid="disable-btn" class="addon-control disable"
            label="&cmd.disableAddon.label;"
            oncommand=""/>



But this does not:

<xul:button anonid="disable-btn" class="addon-control disable"
            label="&cmd.disableAddon.label;"/>

Comment 2

[Blair McBride [:Unfocused] (UNAVAILABLE)]

(In reply to Blair McBride (:Unfocused) from comment #1)
> the following from extensions.xul

Er, from extensions.xml

Comment 3

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

The "leaked" compartment here is the compartment of the prototype doc's global.  The prototype doc is in the cache so its global object (and hence its compartment) sticks around.  It's not clear to me that this is actually a bug.  Is the event handler caching still useful in the post-CPG world?  If so, can we distinguish the prototype compartments in about:memory/about:compartments?

Comment 4

[Kyle Huey (Exited; not receiving bugmail, old account, do not use)]

Btw, note that when you open about:addons about:compartments shows *two* about:addons compartments.  That's one for the actual page and one for the prototype doc, and the first does go away here.

Comment 5

[Bobby Holley (:bholley)]

I don't understand XBL well enough to answer. Hopefully bz or blake can.

Comment 6

[Boris Zbarsky [:bzbarsky]]

OK, so there's no XBL going on here.

The thing Kyle is seeing is nsScriptEventHandlerOwnerTearoff::CompileEventHandler which is what handles on* attributes in XUL afaict.  By default, this compiles them in the proto doc and then stores the compiled value in the nsXULPrototypeAttribute.

I don't think CPG changes much here: we always JS_CloneFunctionObject() to get the actual event handler to use for any particular element.  The question is whether it's worth having the sharing of the JSFunction across XUL documents here.

My personal suspicion is that it's not.  Slightly helped along by all the event listener manager we could remove if we nixed this special XUL behavior.  ;)

Comment 7

[Nicholas Nethercote [inactive]]

No action in 9 years, seem unimportant, closing.