Bug 710107 - Support radio type for simple-prefs

[taku0]

Added “menulist” and “radio” types to simple-prefs.

Sample:

"preferences": [
  {
    "name": "openButton",
    "title": "Mouse button to open menu",
    "type": "menulist",
    "value": 2,
    "options": [
        {
            "value": "0",
            "label": "left_button"
        },
        {
            "value": "1",
            "label": "middle_button"
        },
        {
            "value": "2",
            "label": "right_button"
        },
        {
            "value": "3",
            "label": "fourth_button"
        },
        {
            "value": "4",
            "label": "fifth_button"
        }
    ]
  },
  {
    "name": "radio",
    "title": "Label color",
    "type": "radio",
    "value": "red",
    "options": [
        {
            "value": "red",
            "label": "red"
        },
        {
            "value": "blue",
            "label": "blue"
        }
    ]
  }
]

The values of the “label” are used as l10n keys, or used vervatim as labels if no matching entries are exist in locale file.

Note that “value” of items are always strings like “on” and “off” properties for “boolint” type.

[Gozala]

@erikvold I think you'd be the perfect reviewer for this, could you please pick this one up ?

Thanks!

[Gozala]

@taku0 @erikvold Also I think creating a bug for this one would make a lot of sense.

[taku0]

@Gozala
I found a relevant bug after submitting this pull request.
Bug 710107 - Support radio type for simple-prefs

[taku0]

Updated the title.

[erikvold]

hey @taku0 thanks for taking this one on! I'm just starting to review this, but so far I noticed there aren't any tests, that is something that should be added.

There is a new type of test for Jetpacks called add-on tests which use a addon as a test, which would allow us to test this bug most extensively, but there are other tests that currently exist that should be extended as well. Let me know if you need/want help with this.

[erikvold]

I think that we should just use "options" instead of "menulist" and "radio" to specify the preference value options

[erikvold]

please also mention these new types in the documentation, but I won't block on this, it can be another bug.

[taku0]

Added test for options.xul generation.
I am not sure how to test l10n.
It seems that there are no tests for conventional preference types.

[erikvold]

Let's use core.get(name + "_options." + item.getAttribute("label")) to stick to the convention already started.

[erikvold]

This branch should be updated, master has changed a bit. Other than the one change mentioned for the l10n this looks good. Once you do the merge with master I'll run the tests and it should be good!

[taku0]

Merge succeeded without conflict and test_xpi.py works fine :).

[erikvold]

looks good! I just need to get home and try on Fennec now..

[erikvold]

hmm, there is an issue on Fennec with the menu drop down, when I select it I don't see the "left_button" option, and when I select a value I am asked to make a selection a second time. I can take a look into these issues.

[erikvold]

ok this looks like it is a platform bug to me

[erikvold]

Thanks @taku0 !

[erikvold]

I filed bug 802651

[brettz9]

This is cool. Does the menulist option allow for omitting the value or label to serve as the other? What about hierarchical menus? Thanks!

[brettz9]

Also, any way to distinguish single select while allowing multiple select?