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

NEW
Unassigned

Status

Firefox OS
General
2 years ago
2 years ago

People

(Reporter: elin, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
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.
blocking-b2g: --- → 2.5?
(Reporter)

Updated

2 years ago
Blocks: 1192026
(Reporter)

Comment 2

2 years ago
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.
(Reporter)

Comment 4

2 years ago
Cool, I can sense the dark side XD

Updated

2 years ago
QA Whiteboard: [COM=Add-on]
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
feature-b2g: --- → 2.5?
Flags: needinfo?(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.
blocking-b2g: 2.5? → ---
Flags: needinfo?(mhenretty)
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.
Flags: needinfo?(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.
feature-b2g: 2.5? → ---
Flags: needinfo?(mhenretty)
You need to log in before you can comment on or make changes to this bug.