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.
[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.
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?
(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.
Cool, I can sense the dark side XD
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...
Michael, You call on if this should be a blocking bug or feature blocker
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.
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.
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.