Closed Bug 892136 Opened 12 years ago Closed 11 years ago

Dialog to manage installed add-ons

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: Margaret, Unassigned)

References

Details

When tapping on an installed add-on, we should show enable/disable/uninstall options. We should also figure out a way to let add-ons show their own settings in this UI, which will require looking into the current APIs we support, as well as some UX work.
Cc'ing wesj, because I think he had ideas about how to do this settings API for add-ons.
Just want to clarify that I think we want a full Settings page for managing specific add-ons, not just a dialog. So the question here is, does Android give us enough UI controls to recreate the prefs that we offer to Add-ons developers, such that we can put it into Android Settings content like this So something like: +-----------------------------------+ |< Adblock plus ON / OFF | |---------------+-------------------| | OPTIONS | +---------------+-------------------+ | +--+ | | Disable Everywhere | X| | | +--+ | +-----------------------------------+ | +-------------+| | Filter | EasyList v|| | Subscriptions +-------------+| +-----------------------------------+ | +--+ | | Allow non-intrusive ads | X| | | +--+ | +-----------------------------------+ | +--+ | | Hide placeholders of blocked | | | | elements +--+ | +-----------------------------------+ | +--+ | | Correct mistyped addresses | | | | +--+ | +-----------------------------------+
Assignee: chriskitching → nobody
Thinking about an Add-ons rewrite, I wonder if the right sequence of events is to first create a add-on prefs screen that matches our current Settings (basically, use a new PreferenceActivity with a Preferences screen) for this as a half-way fix (so we can keep it in the current flow of our "about:addons" page), and then once we integrate addons into Settings (an no longer use about:addons) just move that page into Settings. This has the downside that the addons settings won't really match the styling on about:addons, but handling the add-on preferences should be the most complicated part (I think) - making the list of add-ons should be much easier. Alternatively, we could do the work of pulling addons into Settings first and use just launch the current add-on settings XUL prefs screen - I'm not entirely sure how this would work. Robin, what are your thoughts on Add-ons right now? Maybe we can meet and go over what you've thought of and figure out how to break it into pieces. My context of Addons is pretty much just these mocks that Ian has had up (for years) so a refresh might be in order!
Flags: needinfo?(randersen)
I think we need a "options" transition first. Margaret started thinking about deprecating outputs.xul (an overlay like system that limits our ability to go Native) and instead using an Options.jsm (a JS based API for creating options that could be implemented using HTML to start and Native Android later).
Flags: needinfo?(margaret.leibovic)
(In reply to Mark Finkle (:mfinkle) from comment #4) > I think we need a "options" transition first. Margaret started thinking > about deprecating outputs.xul (an overlay like system that limits our > ability to go Native) and instead using an Options.jsm (a JS based API for > creating options that could be implemented using HTML to start and Native > Android later). Yeah, I think we should fix bug 1079466 before we start working on creating a native add-ons experience, especially since we'll need to give add-on developers time to migrate to this new system for creating add-on options.
Flags: needinfo?(margaret.leibovic)
(In reply to Chenxia Liu [:liuche] from comment #3) > Alternatively, we could do the work of pulling addons into Settings first > and use just launch the current add-on settings XUL prefs screen - I'm not > entirely sure how this would work. My vote would be to go for this first. Any new system would want this for backwards compatibility anyway. Its a good intermediate, even if we hold it at nightly for awhile. I had a WIP at making options.xul work with a native UI somewhere, using mutation listeners to message changes back and forth between the HTML and Java UI's. It worked, but (as you'd expect) was death by a thousand paper cuts. With the flood of new bugs proposing the same thing, I can't find it :( I do worry that any new system wouldn't provide enough flexibility to be useful.... but as long as the JS can receive click callbacks on rows and make dynamic updates to the UI based on them, I think it would be fine. I wonder if we'd actually be better to write a generic Prefs.jsm if we were going to do that. Then add-ons can just register something to show in either one of our pages or their pages at startup. i.e. No need for a separate options.jsm. Maybe that's what bug 1079466 is about?
(In reply to Wesley Johnston (:wesj) from comment #6) > Maybe that's what bug 1079466 is about? Bug 1079466 is about removing the implementation details (XUL or HTML) from the options system. Making it entirely JS-based means we can implement the setting elements however we want, much like Prompt.jsm. I have been thinking a lot about "moving about: pages to native UI" lately, and I'm not sure we should do it. At all. I don't see the value in it. I even see Chrome on Android using "chrome://history", and Bookmarks and Recent Tabs are content pages too, respecting back/forward session. What's the value for moving this stuff into native UI rather than leaving it as content pages?
(In reply to Mark Finkle (:mfinkle) from comment #7) > (In reply to Wesley Johnston (:wesj) from comment #6) > > > Maybe that's what bug 1079466 is about? > > Bug 1079466 is about removing the implementation details (XUL or HTML) from > the options system. Making it entirely JS-based means we can implement the > setting elements however we want, much like Prompt.jsm. Yes. If you look in that bug, you'll see I also mentioned that the add-on SDK already supports a JS API for add-on prefs. Under the hood, they create XUL for that the way an add-on would use options.xul, but for mobile we could just redirect the API calls to our own module. I think more than anything else, we should just stop using XUL. If you see all the dependencies on bug 1079466, you'll see that most of the problems with add-on settings are related to XUL bugs that are just too much of a pain to fix. I also think parsing and translating options.xul to something else sounds like a recipe for pain and bugs. I would like to encourage add-on authors to just use a new JS API, which a lot of them actually already do if they're using the add-on SDK. > I have been thinking a lot about "moving about: pages to native UI" lately, > and I'm not sure we should do it. At all. I don't see the value in it. I > even see Chrome on Android using "chrome://history", and Bookmarks and > Recent Tabs are content pages too, respecting back/forward session. +1. I think our about: pages suffer mostly from a lack of love, not a lack of technological capabilities.
> Robin, what are your thoughts on Add-ons right now? Maybe we can meet and go > over what you've thought of and figure out how to break it into pieces. My > context of Addons is pretty much just these mocks that Ian has had up (for > years) so a refresh might be in order! Chenxia, I just sent you a meeting invite for next week. Let's see what we can do!
Flags: needinfo?(randersen)
We decided that it's not worth the effort to try to make a whole new native add-ons UI. Instead, we're using bug 1053397 to track improvements to the current about:addons page.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.