Closed Bug 892125 Opened 7 years ago Closed 5 years ago

Create "Add-ons" page in settings


(Firefox for Android :: General, defect, P5)




Tracking Status
fennec + ---


(Reporter: Margaret, Unassigned)



(Keywords: productwanted)


(3 files)

This bug is about making a first implementation of the "Add-ons" page in settings. To start, let's have "Browse Firefox Add-ons" open a link to AMO, and just show a list of installed add-ons.

You'll need to communicate with JS to get the add-on data, similarly to how the "SearchEngines:Get"/"SearchEngines:Data" messages work. I think it would be good to implement this in a lazy-loaded script (Addons.js or something like that), since we won't need this data on startup. You'll need to use toolkit's AddonManager.jsm module to get the addons. Here's an example of how we currently do it:
Depends on: 892136
To start - the uninteresting resource-modification-and-such patch.
Attachment #777284 - Flags: review?(liuche)
It appears that not all add-ons are equal - we categorise them into extensions, themes, and locales. Would it be worthwhile to have these on separate menus? I can certainly imagine a "Customise themes" menu might be worth having, and managing extra locales through a deeply hidden menu seems sort of annoying for the user (Who presumably isn't so great at english, since they're installing an addon to change it)

For now I'll proceed with the "Jam everything onto one list" approach - just mentioning this thought as a possible enhancement.
Yeah, I'd like to keep them in one list for now. Most of our users don't really understand the difference between these types of add-ons, so there isn't much benefit to chunking them out.
Depends on: 904286
We should track this for 26.
tracking-fennec: --- → ?
tracking-fennec: ? → 26+
Comment on attachment 777284 [details] [diff] [review]
Part 1/3: Adding the new menu page (Resource file changes, strings, etc.)

Clearing this review flag - let's do review when we have more of the patches in a finished state.
Attachment #777284 - Flags: review?(liuche)
Not tracking for Fx26. Moving to Fx27.
tracking-fennec: 26+ → 27+
Alas, there is no more time. Uploading my WIP patches - may or may not be of use.
Assignee: chriskitching → nobody
Re-noming, since this isn't a priority anymore.
tracking-fennec: 27+ → ?
tracking-fennec: ? → 29+
This isn't going to make 29. If we want to fix this, we should find an assignee.
tracking-fennec: 29+ → ?
Deb, what do you want to do here?
Flags: needinfo?(deb)
Keywords: productwanted
Is it realistic to target this for Fx31?
(In reply to Deb Richardson [:dria] from comment #11)
> Is it realistic to target this for Fx31?

I think liuche was going to start looking at this. She would probably be able to give an estimate.
Flags: needinfo?(liuche)
No, this won't make 31, because this is dependent on another settings rework, and we need to support some JS for add-on options. I'm not sure what this is supposed to look like, so I'll talk with ibarlow and see what ideas he has.
Flags: needinfo?(liuche)
tracking-fennec: ? → 32+
Flags: needinfo?(deb)
I've been playing a bit with reflecting the DOM into native UI, so that we could continue to use options.xul here, and allow pages to dynamically edit it. It doesn't do any work to actually reflect real add-ons into the Native UI yet.

This uses MutationObservers to try and reflect dom changes into the native ui. The updates are slow sometimes. I'm not sure if that's the MutationObserver being very async, or Android being dumb about preference view invalidation (I assumed the former originally, but now I've definitely seen the later happen).
tracking-fennec: 32+ → +
QA Contact: mihai.g.pop
filter on [mass-p5]
Priority: -- → P5
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.
Closed: 5 years ago
Resolution: --- → WONTFIX
No longer depends on: 904286
You need to log in before you can comment on or make changes to this bug.