Issue 1566 Advice on bugging "can't access dead object" errors

[rebloor]

Add a section to the deep bugging page that provides guidance on resolving "can't access dead object" errors.

Fixes #1566, which in turn addresses issues originally raised in mdn/content#24191.

[rebloor]

@dotproto can you offer any suggestions on how a developer would go about resolving this error? (e.g., something more specific than identify and prevent access to the DOM objects.)

[dotproto]

A couple of options leap to mind. (I kinda fell into the rabbit hole on this one.)

1. Replace the original element/object with a clone

   // OLD CODE
   //// element
   console.log(myElement);
   
   //// object
   console.log(myObject);
   
   // NEW CODE
   //// element
   // Shallow copy
   console.log(myElement.cloneNode());
   // Includes all descendants
   console.log(myElement.cloneNode(true));
   
   //// object
   // Shallow copy
   console.log({ ...myObject });
   // Supports cyclic references, does not preserve prototype chain
   console.log(structuredClone(myObject));
   // Throws on recursive references, does not preserve prototype chain
   console.log(JSON.parse(JSON.stringify(myObject)));

2. Stringify the object you want to log

   // OLD CODE
   console.debug('Current state', myObject);
   
   // NEW CODE
   console.log('Current state', JSON.stringify(myObject));          // no formatting
   console.log('Current state', JSON.stringify(myObject, null, 2)); // pretty print
   
   // Pretty print the object, but hide in a closed group of log messages
   console.groupCollapsed('Current state');
   console.log(JSON.stringify(myObject, null, 2));
   console.groupEnd();

3. Extract (specific) properties to a temp object

   // OLD CODE
   console.debug('Current state', myObject);
   
   // NEW CODE
   const temp = {
     name: myObject.name,
     id: myObject.id,
     data: myObject.data,
   };
   console.debug('Current state', temp);

[dotproto]

There's way too much subtly in my last comment. I think the simplest, most actionable guidance we can share is to recommend that developers only log the specific properties they need where possible. If they need to log objects during development, they can use element.cloneNode() for elements and structuredClone(object) for JavaScript objects, but this should be avoided (especially in production) due to the additional memory overhead this can incur.

[rebloor]

@dotproto is this just about logs? The original blog post suggested that this issue could prevent the extension from working correctly. Would failing to log information from a dead object have the same effect?

[dotproto]

Apologies for the delay on following up on this. I seems I misunderstood the issue that motivated this. I was familiar with dead object references, but not the specific ways folks were using it.

My examples focused on logging because that was a quick, easy-to-test scenario to experiment with and show in a short snippet here. Basically, you log something before DevTools has a chance to see the object so it doesn't cache/copy/whatever the object so it can be inspected, then when you open DevTools the underlying DOM object reference can't be resolved and the issue appears.

That said, logging as I've done here is just a specific presentation of a more general issue. The main workaround is to store the data needed at the time it is first retrieved rather than trying to look up the data you need later after the reference is no longer valid.

@rebloor, if you like, I can address the motivating use cases more directly, but I'll need to set aside some time for that. Let me know :)

[rebloor]

@dotproto I couldn't find any conversations that suggested this was a regularly encountered issue. Therefore, as the issue has been open for some time, I'm inclined to go with the minimal information and have updated the PR along those lines. If we should get feedback or see any obvious signs that this is a more widespread problem, we can revisit.