1003362 - Telemetry experiments: "TypeError: can't access dead object" when experiment is disabled

Status: RESOLVED WORKSFORME

(Firefox Health Report Graveyard :: Client: Desktop, defect)

Description

[Kamil Jozwiak [:kjozwiak]]

Attachment: "TypeError: can't access dead object" under Browser Console

When you initially remove an experiment and then refresh the add-ons manager, you'll receive the following error message in the browser console:

"TypeError: can't access dead object"

Once you close the about:addons and re-open it, you won't receive the error message anymore. Looks like it only happens initially when you manually disable the experiment. Possibly related to Bug # 1001529 ??

- Attached a screenshot to illustrate the issue

Steps to reproduce the issue: (ensure that you have an experiment installed)

1) Open Firefox
2) Enable "chrome and addon debugging" via the Developer Tools (Developer -> Toggle Tools -> Settings)
3) Open the Browser Console (Developer -> Browser Console)
4) Once opened, type in about:addons in the UR
5) Disable the current experiment and refresh the add-ons manager (you'll notice the error message appearing)
6) Keep refreshing the add-ons manager a few times and you'll notice the errors appearing in the browser console
7) Close and re-open about:addons and then refresh (the error message won't appear anymore)

Current Behaviour:

- When you have a disabled experiment listed under the "Experiments" container in the add-ons manager, you'll receive a "TypeError: can't access dead object" message under the browser console

Expected Behaviour:

- We should either remove this error being displayed, or changing it to something more appropriate: "Couldn't load experiment: <name of experiment> because it has been disabled"

Comment 1

[Benjamin Smedberg]

This error is coming from the JS engine because we've cleared the scope of the object. This means we're touching an object either from a dead window or from a dead XBL binding. I'll try to get a stack from my debugger.

Comment 2

[Benjamin Smedberg]

I can reproduce the problem here but in a debugger it doesn't make much sense: here's one stack where it happens:

    #0  js::DeadObjectProxy::call (
        this=0x7ffff6a6b6d0 <js::DeadObjectProxy::singleton>, cx=0x7ffff7dea300,
        wrapper=..., args=...)
        at /home/bsmedberg/hg-mozilla-central/js/src/jswrapper.cpp:805
    #1  0x00007ffff3a8a94b in js::Proxy::call (cx=0x7ffff7dea300, proxy=...,
        args=...) at /home/bsmedberg/hg-mozilla-central/js/src/jsproxy.cpp:2659
    #2  0x00007ffff3a8c6f0 in js::proxy_Call (cx=0x7ffff7dea300, argc=1,
        vp=0x7fffffffb128)
        at /home/bsmedberg/hg-mozilla-central/js/src/jsproxy.cpp:3062
    #3  0x00007ffff3bde7ba in js::CallJSNative (cx=0x7ffff7dea300,
        native=0x7ffff3a8c603 <js::proxy_Call(JSContext*, unsigned int, JS::Value*)>, args=...) at /home/bsmedberg/hg-mozilla-central/js/src/jscntxtinlines.h:239
    #4  0x00007ffff3bad5b8 in js::Invoke (cx=0x7ffff7dea300, args=...,
        construct=js::NO_CONSTRUCT)
        at /home/bsmedberg/hg-mozilla-central/js/src/vm/Interpreter.cpp:468
    #5  0x00007ffff3badae5 in js::Invoke (cx=0x7ffff7dea300, thisv=..., fval=...,
        argc=1, argv=0x7fffffffb360, rval=...)
        at /home/bsmedberg/hg-mozilla-central/js/src/vm/Interpreter.cpp:531
    #6  0x00007ffff39dc97d in JS::Call (cx=0x7ffff7dea300, thisv=..., fval=...,
        args=..., rval=...)
        at /home/bsmedberg/hg-mozilla-central/js/src/jsapi.cpp:5196
    #7  0x00007ffff0b710de in mozilla::dom::EventListener::HandleEvent (
        this=0x7fffcba83700, cx=0x7ffff7dea300, aThisVal=..., event=..., aRv=...)
        at /home/bsmedberg/hg-mozilla-central/obj-ff-debug/dom/bindings/EventListenerBinding.cpp:44
    #8  0x00007ffff14a9a71 in mozilla::dom::EventListener::HandleEvent<mozilla::dom::EventTarget*> (this=0x7fffcba83700, 

And DumpJSStack() says there's nothing else on the JS stack, so it really looks like there's a dead function which is directly an event listener. This happens when loading the addon manager or about:support; the stack here is DOMContentLoaded being fired at about:support. What's really weird is that there isn't anybody who adds a DOMContentLoaded listener on about:support.

rr debugging would tell us what this object was before, but I very much doubt that this has other user-visible effects so I'm going to let it go for now.

If somebody wants to learn RR to solve an interesting bug, I can provide more details about how to set up a test environment.

Comment 3

[Thomas Huelbert]

could qa please see if this is valid?

Comment 4

[Kamil Jozwiak [:kjozwiak]]

Ryan, does your team want to take this or are they pretty busy right now? It would be a good exercise to get more familiar with experiments. This shouldn't be too difficult to test using the steps from comment #0. Install a few past experiments and make sure there's no dead object error codes once the experiment is disabled.

If your team doesn't have the bandwidth, I could go through this pretty quickly. I figured I would ask as it's a good bug to get more familiar with telemetry experiments.

Comment 5

[Ryan VanderMeulen [:RyanVM]]

Yeah, I think this is something Michelle's group could do.

Comment 6

[Michelle Funches - QA]

I set the experiments.enabled to false and refreshed addon - also restarted FF
1452904452526	Services.Metrics.Provider.org.mozilla.addons	WARN	Add-on type without field: experiment
Test case will be added to test case worksheet

Comment 7

[Kamil Jozwiak [:kjozwiak]]

>> I set the experiments.enabled to false and refreshed addon

Michelle, did you install an experiment and then remove/disable it from about:addons once it was installed? To verify that this isn't happening anymore, you'll need to: (STR are also listed under comment #0)

* go into about:addons and then click on the "Experiment" category
* install any experiment that has been deployed in the past (should probably check with 2-3 experiments)
* once you see the experiment entry appear under about:addons (meaning it's been installed), remove the experiment and refresh about:addons
* ensure that you don't receive the "TypeError: can't access dead object"

Comment 8

[Michelle Funches - QA]

Correct, that is what I did. 
I changed the manifest dates for the Unififed URLbar to activate it. 
a) Check about:addons and see Unified Urlbar Experiment is Active with xx days Remaining and a Remove button. 
b) Ensure Enable browser chrome and add-in debugging toolboxes; [Ctrl Shift J & Clear]
c) Open about:addons and "Remove" the experiment [Unified URLbar Experiment has been removed. Refresh the page several times
d) Check Browser Console.
Verified - TypeError messaging stated here in is not displayed in the browser console.
   "When you have a disabled experiment listed under the "Experiments" container in the add-ons manager, you'll receive
    a "TypeError: can't access dead object" message under the browser console"

Expected... "We should either remove this error being displayed, or changing it to something more appropriate: "Couldn't
    load experiment: <name of experiment> because it has been disabled"
What I can confirm is message " WARN Ad-on type without field: experiment" Is that expected/the fix or should I see a message that are not being displayed at this time?

Comment 9

[Kamil Jozwiak [:kjozwiak]]

I quickly went through this as well and I couldn't reproduce the original issue. I installed and disabled two different experiments and didn't get the "TypeError: can't access dead object" error in the browser console. Michelle couldn't reproduce the issue either via comment #8.

This is the only message that was disabled once you refresh the about:addons page after you've disabled the experiment.

* Could not read chrome manifest 'file:///Applications/FirefoxNightly.app/Contents/Resources/chrome.manifest'.

Michelle, if you run into any error messages when you're testing experiments, just note it in your testing notes and let the developer know.