Luca Greco [:rpl] [:luca] [:lgreco] Reporter
	Description • 8 years ago

In Bug 1167246, it had been reported that the SDK addon preferences are not shown as expected on Firefox for Android 52.

The reason seems to be that no "addon-options-displayed" notification is sent, and after some digging I've been able to identify that the regression is related to the changes introduced by Bug 1300808 (Opening options for Web Extensions produces XML parsing errors on Android), landed in Firefox 51.

The issues has been introduced by the following switch:
- http://searchfox.org/mozilla-central/rev/9af9b1c7946ebef6056d2ee4c368d496395cf1c8/mobile/android/chrome/content/aboutAddons.js#230-236

In particular, the switch added in Bug 1300808 is checking the optionsType property without converting it from string to number (e.g. like we do here: http://searchfox.org/mozilla-central/rev/c48398abd9f0f074c69f2223260939e30e8f99a8/toolkit/mozapps/extensions/internal/XPIProvider.jsm#7320), and so the optionsURL is set to the empty string.
(For legacy addons, the optionsType is retrieved from the install.rdf XML file and it is type string, while the AddonManager.OPTIONS_TYPE_INLINE const is type number).

With the optionsURL set to an empty string, the following XHR request raises an exception:
- http://searchfox.org/mozilla-central/rev/9af9b1c7946ebef6056d2ee4c368d496395cf1c8/mobile/android/chrome/content/aboutAddons.js#368

That is caught and ignored, and so it becomes a silent error (http://searchfox.org/mozilla-central/rev/9af9b1c7946ebef6056d2ee4c368d496395cf1c8/mobile/android/chrome/content/aboutAddons.js#399).

I've not tested it yet, but the issue is probably not restricted to the SDK addons, also the legacy bootstrap addons are probably affected as well.

	Luca Greco [:rpl] [:luca] [:lgreco] Reporter
	Comment 2 • 8 years ago

It looks like the same regression has been fixed in Bug 1329027
(the main difference between the patch attached to this issue and the one landed in Firefox 55 is that the parseInt call do not specify the base to use for the conversion).

I'm resolving this issue as a duplicate of Bug 1329027.