1212685 - Redesign add-on manager inline options flow

Status: NEW

(Toolkit :: Add-ons Manager, defect, P3)

Description

[Dan Callahan [:callahad]]

https://developer.chrome.com/extensions/optionsV2

This is the successor to the options_page api discussed in Bug 1212684.

Comment 1

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

We might be able to use some UX advice here.

Comment 2

[Markus Jaritz [:designakt] (UX)]

Having options implemented as Chrome does seams fine. We also would like to move from option pages, to modal-overlays for options, as we currently also use them in about:preferences. (e.g. about:preferences#content - Choose… )
In this modal-overlay we can show the option we currently display in about:addons underneath the details, or let users specify a HTML themselves.
The header of this modal should state the name of the add-on.

Comment 3

[Blake Winton (:bwinton) (:☕️)]

After chatting with Andy in IRC, I believe I've convinced him that this actually should be part of V1 of WebExtensions.

Comment 4

[Andy McKay]

We'd need some UX for this we believe, would you be able to help bwinton?

Comment 5

[Blake Winton (:bwinton) (:☕️)]

That kind of UX is more of Markus's area.  Markus, could you spec something out for Chrome-style options overlays?

(For a V1, maybe we can get by with hooking up the WebExtensions optionsV2 to the existing add-ons options UI?)

Comment 6

[Markus Jaritz [:designakt] (UX)]

Attachment: add-ons-options-modal.png

I would suggest putting the options in a modal that overlays about:addons using the same modal that is used in about:preferences.
This modal should also be able to be opened through right-click on a browser/page-action icon in the toolbar to allow for an easier modification of the add-on without the need to go through the add-ons manager. Therefor the top section of the modal should clearly stat which add-on is being modified. (and maybe even allow to disable the add-on)

Currently this solutions leave open how to deal with add-ons that have huge numbers of options. Maybe such add-ons, even if it should not be the default, could open their preferences in a tab.

Comment 7

[Kris Maglione [:kmag]]

Implementing this as a modal on about:addons has some complications. We already have a detail view, implemented as a panel, which handles things like enabling/disabling the add-on, and surfacing inline options from XUL add-ons. If we implement the WebExtension options as a modal, we need to decide whether we still want that panel view to be available to them, how it relates to the modal, how the experience differs between WebExtensions with options, WebExtensions without options, and XUL add-ons...

For what it's worth, I'd be in favor of replacing the detail view with a modal panel for all add-ons, since I find the behavior of the detail panel confusing, but that would probably require more UX work, and might make the implementation a bit more difficult.

Comment 8

[Markus Jaritz [:designakt] (UX)]

(In reply to Kris Maglione [:kmag] from comment #7)
> Implementing this as a modal on about:addons has some complications. We
> already have a detail view, implemented as a panel, which handles things
> like enabling/disabling the add-on, and surfacing inline options from XUL
> add-ons. If we implement the WebExtension options as a modal, we need to
> decide whether we still want that panel view to be available to them, how it
> relates to the modal, how the experience differs between WebExtensions with
> options, WebExtensions without options, and XUL add-ons...
> 
> For what it's worth, I'd be in favor of replacing the detail view with a
> modal panel for all add-ons, since I find the behavior of the detail panel
> confusing, but that would probably require more UX work, and might make the
> implementation a bit more difficult.

I agree with your view. We should get rid of the detail panel and work with modals. 
Redesigning the add-on Manager is task we are planing to do, but currently other task within add-ons have higher priority. Having the preferences in a modal as shown above could be a first step towards a new add-ons manager.

Comment 9

[Ryan Feeley [:rfeeley]]

Attachment: add-ons-modal.gif

I thought that this design (mine) was a pretty straight-forward modal replacement of the Details view. Won't it work as an incremental step?

Comment 10

[Ryan Feeley [:rfeeley]]

Comment on attachment 8689594 [details]
add-ons-options-modal.png

As discussed last in person, thumbs up!

Comment 12

[Daniele "Mte90" Scasciafratte]

any news for that?

Comment 13

[Kris Maglione [:kmag]]

Retargeting this, since we decided to go with a simpler model for the initial implementation.

Comment 14

[Kris Maglione [:kmag]]

Blake, are you at all interested in working on the CSS for this?

If not, I can give it a shot. I'm planning on working on this in the next quarter, so I'm going to have to start thinking about how to implement it over the next few weeks.

Comment 15

[Blake Winton (:bwinton) (:☕️)]

I'm more than happy to let you take it.  :)

Having said that, I strongly suggest we use the CSS from the new panel stuff in bug 1225633, which is taken straight from the style guide.  If you need any changes to it, let me know, and I'll make them in the style guide, and re-generate that file, so that we can be consistent.  (Which I think means I'll be happy to help, but would still prefer you to drive this bug. ;)

Comment 16

[Kris Maglione [:kmag]]

Works for me. Thanks

Comment 17

[Andrew Swan [:aswan]]

Ping ddurst to consider this again as part of the about:addons rewrite.
Note that we have a ton of open bugs on inline options pages (from a very quick search, at least bug 1420606, bug 1490865, bug 1398481, bug 1402627, bug 1398466, bug 1430648, bug 1418617). I suspect a bunch of these are inherent in having a remote options page framed inside about:addons so just switching to a modal won't immediately solve them.
If we haven't totally abandoned the philosophy of "great or dead", perhaps we'd be better off just always putting options pages into a tab.

Comment 18

[Andrew Swan [:aswan]]

Whoops, the last bug from the list in comment 17 isn't about inline options pages but add bug 1542794 to the list.

Comment 19

[Kris Maglione [:kmag]]

(In reply to Andrew Swan [:aswan] from comment #17)

If we haven't totally abandoned the philosophy of "great or dead", perhaps we'd be better off just always putting options pages into a tab.

I don't think that's a good idea. Even if we didn't care about the UX aspects, most of the bugs relating to inline options also apply to things like browser action popups and sidebars, which we definitely need to keep. And the general problems with OOP iframes need to be deal with for Fission no matter what we do here.

The remaining layout bugs shouldn't be a problem for the modal popup flow.

Comment 20

[Kris Maglione [:kmag]]

And several of those bugs only have to do with the browser_style CSS, which doesn't have anything to do with the options page being embedded.

Comment 21

[David Durst [:ddurst]]

Now not XUL, do we re-visit the modal overlay conversation at the beginning of this thread?