1. Open browser toolbox 2. Add a breakpoint in ext-tabs-base.js, inside the query method. For example, https://searchfox.org/mozilla-central/rev/8220783953b0311e1d64c2366f732a159f05ed7e/toolkit/components/extensions/ext-tabs-base.js#1804 3. Load the attached add-on in about:debugging, it will use browser.tabs.query 4. The debugger pause 5. Switch to the console 5. Enter `window` 6. Expand `extension`, `tabManager` and `extension` properties. 7. Scroll or wait a bit Result: Firefox crashes. https://crash-stats.mozilla.com/report/index/2d17eb46-7536-4c11-a28b-10cf60180324 https://crash-stats.mozilla.com/report/index/d89d0910-20e1-4478-a218-135c80180324

Regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=e9997d3ed86127e8a6e6827e67762db5a722f3c9&tochange=a4252412b1ac3b90d0845e7c8af5f8231d4e8bce Can't reproduce on 56.0.2, this excludes bug 1396570. Then it's either bug 1396676 or bug 1396449. Since Kris does not answer ni, I will block both and someone in CC may know better.

This is almost certainly bug 1396449.

:jdm is there a better component for this bug? I'm not sure how to help.

Marissa, can you help find an owner for this issue? The crash volume is moderate but since we have steps to reproduce it, maybe it's fixable if we find the right person to work on it.

Hey BZ! Would you please take a look at this? If you need to delegate, please feel free to do so. Thank you!

Sorry, I didn't see the needinfo. Someone will need to get the crash annotations so we can see what classes this is actually crashing for. My guess is that it's a WebExtensionPolicy object. Those are cycle collected, but we store weak pointers to them on extension codebase principals, so I suppose it's technically possible for us to revive a reference to one after the cycle collector has decided to collect it.

(In reply to Kris Maglione [:kmag] from comment #7) > My guess is that it's a WebExtensionPolicy object. Those are cycle > collected, but we store weak pointers to them on extension codebase > principals, so I suppose it's technically possible for us to revive a > reference to one after the cycle collector has decided to collect it. Oh, but obviously that can't be the problem, since this assertion means we're calling NoteChild on a node from more places than it has references. Which means that it's more likely a manifestation of bug 1470965.

So far I can't reproduce the problem. I followed the steps from comment 0, but placing the breakpoint at https://searchfox.org/mozilla-central/rev/088938b1495aeac586bff94234c9382a4b8ca6da/toolkit/components/extensions/parent/ext-tabs-base.js#1876 and then examining the "windowWrapper" object. I'm using a build from revision 7bfbfba4b30c, in case that matters. Oriol, can you still reproduce this?

Fixed in https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9da8a5d80b984d473d8eeb30d3f3acf36ffe546f&tochange=9c7bb8874337c2d40aef3d9945b10490a5115188, probably in bug 1470965 as Kris said. It has been uplifted, I will test next beta to ensure this is fixed in 62.