1057151 - emit "addon-options-displayed" even when there are no options to display

Status: RESOLVED INVALID

(Toolkit :: Add-ons Manager, defect)

Description

[Erik Vold [:erikvold] (please needinfo? me)]

In bug 1052803 add-ons built with jpm don't display their simple-prefs, which use inline prefs, because the sdk listens for an "addon-options-displayed" observer service notification to build and display the simple prefs as inline prefs.

We could have jpm/aom use a stub optionsURL, like "data:text/xml,<placeholder/>", but then we'd have to check that no other options.xul was provided.

Firing a "addon-options-displayed" whenever the add-on details page is display seems like a more simple solution to me.

Steps to reproduce:

1) create an add-on with no inline prefs
2) listen for the "addon-options-displayed" notification with the observer service
3) open the add-on's details page in the aom

Expected:

The "addon-options-displayed" notification fires

Actual:

The "addon-options-displayed" notification does not fire

Comment 1

[Erik Vold [:erikvold] (please needinfo? me)]

Attachment: Link to Github pull-request: https://github.com/erikvold/gecko-dev/pull/1

Comment 2

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Comment on attachment 8477097 [details] [review]
Link to Github pull-request: https://github.com/erikvold/gecko-dev/pull/1

This isn't adequate, as to the Add-ons Manager the add-on still has no prefs - so it won't display relevant UI in the list view (for instance).

This needs fixed at the backend level, so it's reflected in the API. As mentioned in bug 915376, an alternate solution is to introduce another settings type (OPTIONS_TYPE_INLINE_GENERATED) that corresponds to dynamically generated prefs.

I don't see a way around knowing if there's an options.xul or not - as we need to know at install type whether the add-on as prefs or not, so the UI and API isn't misleading. Put another way: We need to avoid the situation where an add-on has no prefs, but about:addons displays UI for showing prefs for that add-on.

Comment 3

[Erik Vold [:erikvold] (please needinfo? me)]

(In reply to Blair McBride [:Unfocused] from comment #2)
> Comment on attachment 8477097 [details] [review]
> Link to Github pull-request: https://github.com/erikvold/gecko-dev/pull/1
> 
> This isn't adequate, as to the Add-ons Manager the add-on still has no prefs
> - so it won't display relevant UI in the list view (for instance).
> 
> This needs fixed at the backend level, so it's reflected in the API. As
> mentioned in bug 915376, an alternate solution is to introduce another
> settings type (OPTIONS_TYPE_INLINE_GENERATED) that corresponds to
> dynamically generated prefs.
> 
> I don't see a way around knowing if there's an options.xul or not - as we
> need to know at install type whether the add-on as prefs or not, so the UI
> and API isn't misleading. Put another way: We need to avoid the situation
> where an add-on has no prefs, but about:addons displays UI for showing prefs
> for that add-on.

Ah good point, I forgot about getting the UI displayed properly.

I think I can work around this bug with https://github.com/mozilla/jpm/pull/155

Thanks for the feedback!