671598 - Add-on sometimes doesn't start when Firefox does

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: General, defect, P1)

Description

[Atul Varma [:atul]]

This is very odd. I have made two add-ons with Jetpack:

  https://github.com/hackasaurus/hackasaurus-sharing-addon

and

  https://github.com/toolness/collusion

Both of these add-ons put a widget in the add-on bar, but sometimes starting Firefox doesn't display the widget. Additionally, the page-mod installed by collusion isn't activated when this happens; it's as though the add-on's main.js just fails to run at all. No errors appear to be logged in the error console, either.

Going to about:addons and disabling, then re-enabling the add-on makes it work properly.

The strange thing is that no one else has reported this bug to me; both addons have been used by other people, and while they've reported plenty of bugs that are my fault, they've never reported this one. So I'm not sure if it's something curious about my set-up.

Comment 1

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Does this happen with just one of those two installed/active?

Comment 2

[Dave Townsend [:mossop]]

Can you set extensions.logging.enabled to true in about:config and see what shows up in the error console in the cases when the add-on isn't started? It should have logging about the restartless add-ons that it tries to run.

Comment 3

[Atul Varma [:atul]]

Ah, I think I've found a way to consistently reproduce the bug.

Wes: It happens in the simplest case, when just one addon is installed.

Dave: It looks like the addon *is* being properly bootstrapped even when the add-on appears to fail to start. Here's part of my log:

  LOG addons.xpi: Loading bootstrap scope from /Users/atul/Library/Application Support/Firefox/Profiles/rkopwwwd.default/extensions/jid1-F9UJ2thwoAm5gQ@jetpack
  LOG addons.xpi: Calling bootstrap method startup on jid1-F9UJ2thwoAm5gQ@jetpack version 0.11
  Could not read chrome manifest file '/Applications/Firefox.app/Contents/MacOS/extensions/{972ce4c6-7e08-4474-a285-3208198ce6fd}/chrome.manifest'.

I'm not sure what {972ce4c6-7e08-4474-a285-3208198ce6fd} is, but I suspect it doesn't matter.

The conditions to reliably reproduce this error are to simply close all browser windows on OS X, press apple-Q to quit, and then start firefox up again. The single window with the user's home page in it doesn't have the widget it's expected to have.

However, quit Firefox *now* and restart it, and there is a widget and everything works fine. This is because whenever session restore kicks in to open the home tab from my last session, things work, but things don't work when there's no session to restore. At least that seems to be the case. I wonder if some observer isn't getting fired or somesuch.

Anyways, if this is a real bug and not just my system being wonky, I think I can fix it!

My prefs are set to "show my windows and tabs from last time", btw.

Comment 4

[Dave Townsend [:mossop]]

(In reply to comment #3)
> Dave: It looks like the addon *is* being properly bootstrapped even when the
> add-on appears to fail to start. Here's part of my log:
> 
>   LOG addons.xpi: Loading bootstrap scope from
> /Users/atul/Library/Application
> Support/Firefox/Profiles/rkopwwwd.default/extensions/jid1-
> F9UJ2thwoAm5gQ@jetpack
>   LOG addons.xpi: Calling bootstrap method startup on
> jid1-F9UJ2thwoAm5gQ@jetpack version 0.11
>   Could not read chrome manifest file
> '/Applications/Firefox.app/Contents/MacOS/extensions/{972ce4c6-7e08-4474-
> a285-3208198ce6fd}/chrome.manifest'.
> 
> I'm not sure what {972ce4c6-7e08-4474-a285-3208198ce6fd} is, but I suspect
> it doesn't matter.

That second message is ignorable (filed as a bug elsewhere that I can't find right now) but the first suggests that this is definitely an SDK issue and not an add-ons manager issue.

Comment 5

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

It looks like harness.js is waiting for 'sessionstore-windows-restored' event which is not emitted in scenarios described by Atul.

Also, Alex pointed out to me that this he had relevant discussion about this with myk: https://bugzilla.mozilla.org/show_bug.cgi?id=646767

Comment 6

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Attachment: Pointer to Github pull request: https://github.com/mozilla/addon-sdk/pull/224/files

Pointer to Github pull-request

Comment 7

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Comment on attachment 551423 [details]
Pointer to Github pull request: https://github.com/mozilla/addon-sdk/pull/224/files

This change makes harness to start add-on on "final-ui-startup" instead of "sessionstore-windows-restored" that is not always emitted.

Comment 8

[Dietrich Ayala (:dietrich)]

See also bug 645428, which might ensure that sessionstore-windows-restored is sent in these cases, but I am not totally sure about that. Jetpack is mentioned.

Comment 9

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 551423 [details]
Pointer to Github pull request: https://github.com/mozilla/addon-sdk/pull/224/files

Per bug 645428, this is a platform bug, and the best fix is the platform one tracked by bug 645428.

If that can't happen in a reasonable timeframe, then we can consider working around it in the SDK in the meantime.  But the patch would need to identify the change as a temporary workaround and reference the bug for the platform fix.

It would also need to change the reference to sessionstore-windows-restored in Harness_observe, identifying "final-ui-startup" as the notification to remove for both XULRunner and Firefox.

(Note: we can also consider making final-ui-startup the permanent notification, which may have some merit, at least until we start loading addons in their own processes; but as far as I can tell, no one has done the due diligence there, so we don't have grounds for doing so at this time.)

Comment 10

[Myk Melez [:myk] [@mykmelez]]

zpao: in bug 645428, comment 6, you say you're willing to take the fix in that bug if a better one doesn't come along before the freeze for Firefox 6.  We're now running up against the freeze for Firefox 8.  Are you still willing to take that fix?

Comment 11

[Myk Melez [:myk] [@mykmelez]]

Note also that <https://developer.mozilla.org/en/Observer_Notifications> says final-ui-startup requires registration with the category manager.

Currently, harness.js is an XPCOM component that registers with the category manager for profile-after-change, at which point it registers with the observer service for final-ui-startup.  But we want to get rid of that XPCOM component.  If we do so, can we still register for final-ui-startup from bootstrap.js?

Comment 12

[Dave Townsend [:mossop]]

(In reply to Myk Melez [:myk] from comment #11)
> Note also that <https://developer.mozilla.org/en/Observer_Notifications>
> says final-ui-startup requires registration with the category manager.

I believe that to be a lie and I'm removing it from the docs

Comment 13

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Is this still relevant ? bug 645428 is already landed so we might want to leave it as is.

Comment 14

[Myk Melez [:myk] [@mykmelez]]

Yes, let's leave it the way it is instead of adding a temporary workaround.

Comment 15

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

Ah sorry, Myk's comment actually prompted me to wrap bug 645428 up. I meant to comment here. Oops!