Bugzilla

(In reply to David Walsh :davidwalsh from comment #17)
> :bdanforth Any thoughts on what could be causing this intermittent?  I'm wondering if it was a result of:
> 
> https://hg.mozilla.org/mozilla-central/rev/dedca1647cfe5f15b57580b8224b32022f9373e3

Hmm… It's possible, though thinking about it, I think this may be Bug 1597900, i.e. a test-only race condition from Bug 1542035.

I just noticed in Bug 1618059, this failing task (`test_panel_live_reload`) was pulled out from the test and made into a separate test, `test_extension_storage_actor_upgrade.js` by jdescottes and disabled on Windows. That just landed in `central` a day ago. Perhaps this bug should be updated to reflect that?

Either way, that doesn't address the root cause…

This test upgrades a test extension while the Storage panel is open. My best guess is that the storage actor is still targeting the fallback window (Or perhaps no window? See error below.) when `getStoreObjects` is called in these rare instances. Specifically, we have some [logic to return no data if the storage panel is targeting a fallback window](https://searchfox.org/mozilla-central/rev/e11d919cdc8a909354eb2c3e19904d9229c55d88/devtools/server/actors/storage.js#1902-1909).

I haven't been able to get the test to fail locally, but looking at the more recent logs in [Comment 8](https://bugzilla.mozilla.org/show_bug.cgi?id=1620767#c8) this theory may be further supported by an error that logs just before the assertion fails:
```
DBG-TEST: resource://devtools/server/actors/targets/browsing-context.js:390: error: NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDocShell.domWindow]
```
While we wait for the extension to upgrade, we don't explicitly wait for the storage actor to be targeting the extension page before calling `getStoreObjects` in the test. Perhaps there is a way to do that?

Of course, I could be totally off base; it has been a while. Rpl was my mentor on this work; rpl, what do you think about this theory? Is there a change we could make in the test or elsewhere that would avoid this issue?

jdescottes [mentions in the separate test comments](https://searchfox.org/mozilla-central/rev/e11d919cdc8a909354eb2c3e19904d9229c55d88/devtools/server/tests/xpcshell/test_extension_storage_actor_upgrade.js#7-8) that the test started failing a lot "...as soon as we start auto-attaching targets". jdescottes: I would also be curious if you have any thoughts here?

(In reply to David Walsh :davidwalsh from comment #17)
> :bdanforth Any thoughts on what could be causing this intermittent?  I'm wondering if it was a result of:
> 
> https://hg.mozilla.org/mozilla-central/rev/dedca1647cfe5f15b57580b8224b32022f9373e3

Hmm… It's possible, though thinking about it, I think this may be Bug 1597900, i.e. a test-only race condition from Bug 1542035.

I just noticed in Bug 1618059, this failing task (`test_panel_live_reload`) was pulled out from the test and made into a separate test, `test_extension_storage_actor_upgrade.js` by jdescottes and disabled on Windows. That just landed in `central` a day ago. Perhaps this bug should be updated to reflect that?

Either way, that doesn't address the root cause…

This test upgrades a test extension while the Storage panel is open. My best guess is that the storage actor is still targeting the fallback window (Or perhaps no window? See error below.) when `getStoreObjects` is called in these rare instances. Specifically, we have some [logic to return no data if the storage actor is targeting a fallback window](https://searchfox.org/mozilla-central/rev/e11d919cdc8a909354eb2c3e19904d9229c55d88/devtools/server/actors/storage.js#1902-1909).

I haven't been able to get the test to fail locally, but looking at the more recent logs in [Comment 8](https://bugzilla.mozilla.org/show_bug.cgi?id=1620767#c8) this theory may be further supported by an error that logs just before the assertion fails:
```
DBG-TEST: resource://devtools/server/actors/targets/browsing-context.js:390: error: NS_ERROR_NOT_AVAILABLE: Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDocShell.domWindow]
```
While we wait for the extension to upgrade, we don't explicitly wait for the storage actor to be targeting the extension page before calling `getStoreObjects` in the test. Perhaps there is a way to do that?

Of course, I could be totally off base; it has been a while. Rpl was my mentor on this work; rpl, what do you think about this theory? Is there a change we could make in the test or elsewhere that would avoid this issue?

jdescottes [mentions in the separate test comments](https://searchfox.org/mozilla-central/rev/e11d919cdc8a909354eb2c3e19904d9229c55d88/devtools/server/tests/xpcshell/test_extension_storage_actor_upgrade.js#7-8) that the test started failing a lot "...as soon as we start auto-attaching targets". jdescottes: I would also be curious if you have any thoughts here?