1417743 - Webextension alarm fails to run on initial load

Status: RESOLVED DUPLICATE of bug 1432605

(WebExtensions :: General, defect, P5)

Description

[brandon]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36

Steps to reproduce:

1) Run add-on as temporary on via full install
2) Load the debug screen
3) Observe the errors related to alarms

Hosted Add-on:
https://addons.mozilla.org/en-US/firefox/addon/blockade-io/

Access to raw source:
https://github.com/blockadeio/firefox_extension


Actual results:

My webextension uses alarms to bootstrap its configuration. When performing the initial load of the extension, I've noticed that it hangs and never configures itself. However, if I "reload" the extension, everything begins to work properly.

Digging into the issues a bit, I see some errors related to alarms that make me feel like my alarm triggers are never taking place:

TypeError: alarmCallbacksMap.get(...) is undefined[Learn More]  ext-alarms.js:52:26

Full dump of console errors:
https://pastebin.com/v7wZ3LvB


Expected results:

When loading my extension, it will pop-up a setup page that waits for an alarm to trigger an AJAX call which performs the initial extension setup. A successful installation will show a complete setup page with the words "test extension" shown and not a spinning dialog that never finishes loading.

Comment 1

[Bob Silverberg [:bsilverberg]]

I will investigate.

Comment 2

[Bob Silverberg [:bsilverberg]]

I tried to reproduce these errors and was unable to do so. I did three tests, each with a clean profile:

1. I installed the extension from AMO via https://addons.mozilla.org/en-US/firefox/addon/blockade-io/.
2. I downloaded the source code from https://github.com/blockadeio/firefox_extension and loaded the extension temporarily via about:debugging.
3. With the source code from #2, I used web-ext run to launch the extension in a new profile.

None of these yielded the errors reported above.

I do see the spinner on the configuration page, with the message "Status: Syncing database with cloud node...", but no error messages in the console from ext-alarms.js.
  
With which version of Firefox were you seeing these errors? Is it possible to produce a reduced extension that demonstrates this problem?

Comment 3

[brandon]

I am using Firefox 57.0 (64-bit) on Mac 10.12.6 with the primary testing method of loading code by zipping the extension folder and temporarily loading the extension via the about:debugging interface like you mention.

As you note, "Status: Syncing database with cloud node..." should show up, but if the alarms are working properly then it will trigger a remote load of the Blockade database which then updates to show a message of success where you can test the extension.

After loading the extension, I click debug, accept the connection from the pop-up and then get presented with several errors already present inside of the console. If I keep that debugging window open, click "reload", I can see the debug message from my console go away and they don't come back. If I load the setup page by going to the options page, I can see the "All done! Test extension." message. 

I have not tried to isolate this by simplifying the extension at all. I am willing to do that, but want to check platforms first.

Comment 4

[Bob Silverberg [:bsilverberg]]

Thanks Brandon. I tried the same steps as you, loading the extension and then clicking debug to open the separate browser toolbox, but I still am not seeing any of the errors you mention in the console. The only message I see in the console is one saying "Loading remotely", which is coming from "blockade.js:28:13". 

Would you be able to try this on Nightly (which is how I'm testing it) to see if that makes any difference?

Comment 5

[brandon]

Test on 59.0a1 nightly and had some new errors (copy from console):

formatURL: Couldn't find value for key: OLD_VERSION  nsURLFormatter.js:127
IndexedDB UnknownErr: ActorsParent.cpp:598 (unknown)
Content Security Policy: Directive ‘child-src’ has been deprecated. Please use directive ‘worker-src’ to control workers, or directive ‘frame-src’ to control frames respectively.  (unknown)
getScreenshot error: Error: page-thumbnail:error  Screenshots.jsm:61
Loading remotely  blockade.js:28:13
Source map error: TypeError: NetworkError when attempting to fetch resource.
Resource URL: moz-extension://da9feded-af31-704e-94f6-7c91af824735/resources/external/bootstrap.min.css
Source Map URL: bootstrap.css.map[Learn More]

Still sees like I am getting the same error of the "loading remotely" not actually spurring the initial bootstrap network call. Again, when I hit "reload" everything picks up okay. Without the reload, it doesn't seem like the extension over loads properly and thus never configures itself. Confirmed this by browsing the test web page and noticed it was not blocked, even after some time has passed.

If there's nothing glaring in the console logs above that could suggest the issue, I may strip the extension down in order to isolate what's happening here.

Comment 6

[Bob Silverberg [:bsilverberg]]

I did some more local testing and while I do see the error you report for:

Source map error: TypeError: NetworkError when attempting to fetch resource.
Resource URL: moz-extension://da9feded-af31-704e-94f6-7c91af824735/resources/external/bootstrap.min.css
Source Map URL: bootstrap.css.map[Learn More]

I'm not sure it's related. I was also able to reproduce the "alarmCallbacksMap.get(...) is undefined" error, but only after a reload of the extension. So that error does not seem to show up for the error case you describe (the initial install) but only upon reload, which allows the extension to operate properly, so again I don't think it's related to your problem. I believe the alarms error is happening because the setup page is destroyed and is similar to bug 1418311, so I will file a separate bug for that.

In the meantime, I'm not sure there's much more I can do without a reduced test case to prove that it's not just a problem with your extension code. Once you have one I'll be happy to investigate further.

Comment 7

[Firefox Bug Husbandry Bot]

Bulk move of bugs per https://bugzilla.mozilla.org/show_bug.cgi?id=1483958

Comment 8

[Rob Wu [:robwu]]

Based on the error message and the source code at the time of this error, I believe that this is a duplicate of bug 1432605 (and fixed).

The error "alarmCallbacksMap.get(...) is undefined[Learn More]  ext-alarms.js:52:26" points to:
https://searchfox.org/mozilla-central/rev/403075400af13241a01fdca91cee44c2c88457a8/toolkit/components/extensions/ext-alarms.js#52

DUe to bug 1432605, whenever another extension page used the alarms API, the collection of alarms was cleared.
Consequently, callbacks for previously registered alarms weren't fired.
Furthermore, because the collection was cleared without resetting the underlying timer, the above error message occurred when the timer was triggered after the extension was shut down.