The enum in the HomePager is called Page which can imply it is an explicit ordering of the pages in the HomePager when in actuality, it is just a listing of the different page types available in the HomePager (for example, see WIP in bug 862805).

It seems the enum is specified with the assumption that the pages are listed in order [1]. We make similar assumptions, such as that the pages are only ever used once. For example, in HomePager.show() we have: setCurrentItem(adapter.getItemPosition(page), false); [2] Which will not work if a value from the enum is used twice. The implementer of this bug should verify that these assumptions are not made. [1]: https://mxr.mozilla.org/mozilla-central/source/mobile/android/base/home/HomePager.java?rev=13048fd980ed#39 [2]: https://mxr.mozilla.org/mozilla-central/source/mobile/android/base/home/HomePager.java?rev=13048fd980ed#166

Changing the summary here to reflect what we'll need to do for bug 862805 to work. Instead of using this enum to create the different pages in HomePager, we should make some other data structure to control the default set of pages (and their order).

Margaret said she'd take this over via IRC due to the scope creep.

wesj may also want to look into this while I work on some other parts of bug 862805 :)

Not actively working on this.

I'll bootstrap the infrastructure to manage about:home pages. This includes both the backend bits (i.e. change about:home to be backed by a 'configuration' instead of fixed list of pages) and the UI to manage it.

I'm duping this to bug 942231, since that bug addressed the underlying problem here by creating a new HomeConfig.PageType enum that allows for multiple pages of the same type. I'm also working in bug 949181 to get rid of the HomePager.Page enum altogether, so that we're just using the HomeConfig logic to keep track of the different pages.