1214155 - [Add-ons] onenabledstatechange event didn't fire when add-on disabled

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect)

Description

[elin]

I created a test add-on to see if onenabledstatechange works properly:
https://github.com/elin-moco/simple-addon/tree/cant-detect-disable
currently it only fires when add-on enabled, but not when add-on disabled.

Comment 1

[Michael Henretty [:mikehenrty][:mhenretty]]

[Blocking Requested - why for this release]:

This seems like basic broken functionality, since add-ons need to do nice things when disabling themselves. We also should put some integration tests in Gaia to protect this functionality.

Comment 2

[elin]

https://developer.mozilla.org/en-US/Firefox_OS/Add-ons#App_management_functions_in_add-ons
Also since current API need manifest URL to determine which event is for current add-on,
we might need to get this bug solved to be able to get the manifest URL grammatically:
https://bugzilla.mozilla.org/show_bug.cgi?id=1212371

cuz we won't be able to know (and hardcode) the manifest URL in advance when submitting to marketplace, can we?

Comment 3

[Michael Henretty [:mikehenrty][:mhenretty]]

(In reply to elin from comment #2)
> https://developer.mozilla.org/en-US/Firefox_OS/Add-
> ons#App_management_functions_in_add-ons
> Also since current API need manifest URL to determine which event is for
> current add-on,
> we might need to get this bug solved to be able to get the manifest URL
> grammatically:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1212371
> 
> cuz we won't be able to know (and hardcode) the manifest URL in advance when
> submitting to marketplace, can we?

That's a good point. I think for now we have a workaround (however terrible) in that you can just use manifest.name. So I don't think we need to block on that bug 1212371, but it would be nice to have.

Comment 4

[elin]

Cool, I can sense the dark side XD

Comment 5

[[:fabrice] Fabrice Desré]

I'm still not sure why the event handler is not triggered when enabled = false, but if you use navigator.mozApps.mgmt.addEventListener("enabledstatechange", ...) instead everything works fine and that's a cleaner solution.
I'm puzzled...

Comment 6

[Mahendra Potharaju [:mahe]]

Michael, You call on if this should be a blocking bug or feature blocker

Comment 7

[Michael Henretty [:mikehenrty][:mhenretty]]

Mahe, can you tell me what the difference between a blocker and a feature blocker is?

Let's not block the release on this since comment 5 shows a workaround. I'll update the MDN doc to call this out.

Comment 8

[Mahendra Potharaju [:mahe]]

Michael, I was calling all regressions, foxfood bugs in 2.5 blocker list and other bugs from exploratory testing as b2g blocker.

 Any bug in a 2.5 feature is being called as feature blocker. My thought is if a feature is No-Go, it gets easier to manage all feature related patches. 

Let me know if you think this is causing confusion or there are/were better ways to do this.

Comment 9

[Michael Henretty [:mikehenrty][:mhenretty]]

Totally makes sense, thanks for the explanation. This one would be more like a feature blocker, as you mentioned. But given that we have a workaround, I think there are more important things to work on for add-ons to be a go in 2.5.

Comment 10

[BMO Automation]

Firefox OS is not being worked on