1167246 - Addon simple preferences do not appear in addons manager on Android using JPM

Status: RESOLVED FIXED

(Add-on SDK Graveyard :: General, defect, P2)

Description

[Dave Royal]

Attachment: [e-mail]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 2015051400
Firefox for Android

Steps to reproduce:

I have an addon built with addon-sdk-1.17. It uses simple preferences and works on desktop and Android. I rebuilt it using jpm.

It works as before on desktop. 
But on Android the prefs don't show in the addons manager. 
It still works, though - I can see and set the pref in about:config

Attached the addon xpi
Just load it and look for the prefs - present on desktop, absent on Android.

(Despite its name, this addon does not touch the clipboard. It runs a content script - originally a Greasemonkey script - that send the contents of a textarea to another addon, which does copy it to the clipboard. The preference is a list of URLs to run the content script on - equivalent to the @includes in the original GM script. I intend to include the clipboard part in this addon, hence the name. but haven't done that yet.)

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

Is this something on our side or does this bug belong to the Addon-SDK? If it is ours do we want to/plan to fix this?

Comment 2

[:Margaret Leibovic]

This is probably an issue with the add-on SDK, if the problem seems to be caused by using jpm.

However, our add-on options UI is pretty terrible on Fennec (we have our own bad way of parsing an options.xul file), and the real long term solution here would be something like bug 1079466.

Comment 3

[Dave Royal]

I notice that if I disable the addon, then enable it again, the word 'OPTIONS' very briefly appears.

Comment 4

[Dave Royal]

I rewrote this addon. The new version uses a simple-prefs 'control' button.

Using jpm it works on desktop, but on Fennec the options and the button don't appear so it cannot be used. I regenerated it with SDK 1.17 and it works fine on both desktop and Fennec.

I can attach both versions of the addon if that's helpful but the original attachment demonstrates the problem.

I'll change the product to the addon SDK.

Comment 5

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

(In reply to Dave Royal from comment #4)
> I rewrote this addon. The new version uses a simple-prefs 'control' button.
> 
> Using jpm it works on desktop, but on Fennec the options and the button
> don't appear so it cannot be used. I regenerated it with SDK 1.17 and it
> works fine on both desktop and Fennec.
> 
> I can attach both versions of the addon if that's helpful but the original
> attachment demonstrates the problem.
> 
> I'll change the product to the addon SDK.

That's too bad.  jpm does handle inline prefs differently, and we didn't make testing on fennec a priority.  This might be a little tricky to implement, because we might need to patch fennec.

Comment 6

[Alexander]

It seems, since Firefox 44, jpm was made the required tool for add-on packing. My cfx-packed one, which worked perfectly fine, which had been waiting for review for more than 6 months, was simply ... rejected due to that fact. It's all awfull but OK, I've repacked it with jpm and what I see? No preferences on Fennec. What's now, guys? What else should I do to have this small simple damn thing working on Firefox, huh? It's almost a YEAR as I have nothing but troubles with it on each of a new version of Firefox: bugs, new bugs, another bugs, and just an aeon-long review process! Now jpm (which is buggy) is a requirement, mandatory "signed" status to have it works, etc. Please, excuse me, I'm just going out of patience. Just take a look at my activity here - all the bugs I submitted were only because of this simple add-on. Just troubles and nothing more. Sorry, if it was a wrong place to complain.

Comment 7

[Daniel Kladnik]

I can confirm this bug. Only in Firefox on Android, when build with jpm and when I tap on my addons name, options don't appear. this is the error i get:

I/stdout  (19027): console.error: jpm-bug-test: 
I/stdout  (19027):   Message: TypeError: doc.getElementById(...) is null
I/stdout  (19027):   Stack:
I/stdout  (19027):     onAddonOptionsDisplayed@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/preferences/native-options.js:1:840
I/stdout  (19027): Observer<.observe@resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/commonjs/sdk/system/events.js:14:44
I/stdout  (19027): showDetails/xhr.onload@chrome://browser/content/aboutAddons.js:31:42
I/stdout  (19027): 1454677768768        addons.update-checker   WARN    HTTP Request failed for an unknown reason
I/stdout  (19027): 1454677768771        addons.update-checker   WARN    HTTP Request failed for an unknown reason
I/stderr  (19027): JavaScript strict warning: resource://gre/modules/FormHistory.jsm, line 66: ReferenceError: reference to undefined property change.guid

preferences in package.json are simple:
...
"preferences": [{
    "name":"contextmenu",
    "title":"Enable context menu options",
    "description":"Display context menu options for reporting and whitelisting",
    "type":"bool",
    "value":true
  }],
...

Comment 8

[rizsanyi]

Attachment: nativeoptions.patch

I have a simple patch that fixes the getElementById issue. But even with this patch the options do not appear.

Comment 9

[Dave Royal]

There is now a workaround by Luca Greco in bug 1243467

Comment 10

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: MozReview Request: Bug 1167246 - Fix SDK native-options module on Android.

Review commit: https://reviewboard.mozilla.org/r/44113/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/44113/

Comment 11

[Luca Greco [:rpl] [:luca] [:lgreco]]

Comment on attachment 8716311 [details] [diff] [review]
nativeoptions.patch

Marked as obsolete, new patch submitted through mozreview (and based on the workaround npm module created as part of Bug 1243467)

Comment 12

[Dave Townsend [:mossop]]

Comment on attachment 8737793 [details]
MozReview Request: Bug 1167246 - Fix SDK native-options module on Android.

https://reviewboard.mozilla.org/r/44113/#review41123

Comment 13

[Luca Greco [:rpl] [:luca] [:lgreco]]

Comment on attachment 8737793 [details]
MozReview Request: Bug 1167246 - Fix SDK native-options module on Android.

Now that the patch is r+ from an Addon SDK point of view, I'd like to get at least a feedback on the Firefox for Android side, especially because the Addon SDK tests are not currently integrated with the Android testing (and it seems that the jetpack test suite are using xul overlays to integrate itself into the Desktop mochitests, which doesn't make the thing simpler)

The interesting bits of the patch from an Android point of view are:

- the selection of the options box and the tweak that makes the options header visible (from line 43 to line 51 of the attached patch)

- the explicit usage of document.createElementNS with the XUL xml namespace, because the "about:addons" page is an xhtml page on Android and a xul page on Desktop (from line 132 to line 182 of the attached patch)

This will not solve all the issues with the XUL based options on Android, but it helps by fixing the bigger issue that the addon developers are experiencing starting from Firefox for android 45 and XPI generated using jpm, and it is one step in the direction of removing the XUL usage from the options (and the WebExtensions options UI will not make any usage of XUL at all, so the things will be nicer in the feature)

Comment 14

[:Margaret Leibovic]

Comment on attachment 8737793 [details]
MozReview Request: Bug 1167246 - Fix SDK native-options module on Android.

https://reviewboard.mozilla.org/r/44113/#review41381

Looks reasonable to me. Honestly, our current about:addons options support is a buggy mess, so anything is an improvement.

Comment 15

[Luca Greco [:rpl] [:luca] [:lgreco]]

The try build completed successfully:

- https://treeherder.mozilla.org/#/jobs?repo=try&revision=fae5e77d75d1

(which at least ensures that the module behavior tested on Firefox Desktop is consistent with the previous non-patched native-options SDK module).

Added checkin-needed keyword.

Comment 16

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/f5d7c57cdfd7

Comment 17

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/f5d7c57cdfd7

Comment 18

[Alexander]

Fennec 52.0 turned all back - no preferences are displayed again. It may be some other cause now there, but the problem is the same. My add-on - https://addons.mozilla.org/en-US/firefox/addon/cctoo/

Comment 19

[Luca Greco [:rpl] [:luca] [:lgreco]]

Hi Alexander,
Thanks for reporting it, I spent some time debugging the issue and: yes, it is a different issue but it has the same outcome (the SDK preferences are not rendered in the about:addons addon details page).

I've been able to track it down and I'm preparing a fix for it (I'm going to file a separate bugzilla issue and then link it in a new comment on this one).

Also, I'm taking a look for possible workarounds that could be applied to the addon sources itself to fix the preferences rendering on the Firefox versions where the fix will not be available.

Comment 20

[Luca Greco [:rpl] [:luca] [:lgreco]]

Hi Alexander,
I filed this issue as Bug 1350327.

While digging into it I've identified the regression in Bug 1300808, which has landed in Firefox 51.

Did you have noticed the same issue on Firefox for Android 51?

Comment 21

[Alexander]

(In reply to Luca Greco [:rpl] from comment #20)
> Hi Alexander,
> I filed this issue as Bug 1350327.
> 
> While digging into it I've identified the regression in Bug 1300808, which
> has landed in Firefox 51.
> 
> Did you have noticed the same issue on Firefox for Android 51?

Hi. It seems you're right - on 51.0 my add-on shows no preferences the same way it does on 52.0.

Comment 22

[Luca Greco [:rpl] [:luca] [:lgreco]]

Hi Alexander,
Thanks for the confirmation.

I resolved Bug 1350327 as a duplicate, because a fix for the same regression have been landed today on Firefox 55 (Bug 1329027).