Improve lightweight theme installation

RESOLVED INACTIVE

Status

()

P3
normal
RESOLVED INACTIVE
2 years ago
7 months ago

People

(Reporter: andy+bugzilla, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(firefox50 affected)

Details

(Whiteboard: [UX needed]triaged)

(Reporter)

Description

2 years ago
When you install a lightweight theme you get this confirmation message:

https://www.dropbox.com/s/7ed2mwxgll2bel3/Screenshot%202016-07-14%2015.13.25.png?dl=0

Which gives you choice to "undo" or "manage" the lightweight theme. The latter takes you to about:addons > Appearance.

However we don't allow just any site to install themes, you have to explicitly allow them. Unfortunately its not done as a modern permission, you get this dialog:

https://www.dropbox.com/s/1tpbkvtr86jia8f/Screenshot%202016-07-14%2015.13.36.png?dl=0

The list of sites that's allowed to install lightweight theme without that permission prompt is already set to addons.mozilla.org (see about:preferences > security).

I can see the point of the prompt asking users for permission, but it ensures that a site can't do a drive by installation of a theme in a bad way.

However we can make the reasonable assumption that AMO is not going to allow a drive by installation.

If that's the case, is the post install message worth having around still?

This would make other bugs like bug 1284561 easier (or non-existant).

Comment 1

2 years ago
Hi Markus or Philip, how do you feel about changes andy is talking about with uneccessary message?
Flags: needinfo?(mjaritz)

Updated

2 years ago
Whiteboard: [UX needed]
Ah, this is relevant for Personas Plus as well.
(Reporter)

Comment 3

2 years ago
(In reply to Andreas Wagner [:TheOne] from comment #2)
> Ah, this is relevant for Personas Plus as well.

In that it would be good to remove for that add-on as well?
(In reply to Andy McKay [:andym] from comment #3)
> (In reply to Andreas Wagner [:TheOne] from comment #2)
> > Ah, this is relevant for Personas Plus as well.
> 
> In that it would be good to remove for that add-on as well?

I don't have a strong opinion either way. PP behavior is a bit inconsistent currently, though (https://github.com/mozilla/personas-plus/issues/53) and I think it makes sense to follow whatever is decided here.
I mostly agree with Andy. But I think it is not only about drive-by installation of themes, but about giving users another chance (if they accidentally clicked add). This is usually in form of either "ask for permission" or "ask for forgiveness". Disco Pane has this built in, as you can easily revert your action. As does the current theme install with its "undo" to revert your action. And extensions currently use "ask permission" to re-confirm that the users did click install intentionally.

Therefor, I think we should wait with removing undo until we have another way for users to easily undo a theme they (accidentally) installed. Like the new install switch. (And maybe by then we can replace the whole bar with the confirmation panel we use for extensions on disco pane.)
Flags: needinfo?(mjaritz)
(Reporter)

Comment 6

2 years ago
We can control the install and uninstall options on pages like the discovery pane or the AMO. But we can't control it on other sites and domains where it could be anything. 

If the undo has merit on other domains where we don't control the flow, perhaps it should go behind a domain list?

Also I find this behaviour between themes and add-ons (which can arguably do way more damage) inconsistent and perhaps there's an opportunity to simplify a few things with this.
(Reporter)

Comment 7

2 years ago
Interested in dveditz opinion.
Flags: needinfo?(dveditz)
The lightweight themes "API" lets a whitelisted site install a theme, but not remove it. A user can end up with an unwanted theme (on aesthetic grounds, or because it was malicious) and not know how to get rid of it since the install/uninstall actions are unrelated. I believe that's the motivation behind the Firefox 3.x UX team wanting that "undo" bar to appear.

If we restrict the permission to "good" sites then maybe were OK without it -- AMO can have a help link "How do I uninstall a theme?" or something. FWIW I know I try themes that I think I will like and then have regrets -- I appreciate the UNDO button. (I also use Personas Plus which has a "Default" menu item that's easier to use than opening up the Add-ons manager.)

Any time a non-whitelisted site tries to install an add-on or theme we prompt the user to add them to the whitelist! _That_ is the horrible thing here: just because the user wants this one thing while they are paying attention doesn't mean that site is trustworthy with those powerful abilities for all time. I'd really REALLY like to kill that "Allow" prompt -- make the site have to explain how to go into prefs and add them, or for add-ons explain that the user should download the file and then open it in Firefox. (speaking of which, we might want to register the .xpi extension with Firefox to make this path easier -- would still bring up the install prompt of course.)

If you want to encourage more sites to use Lightweight themes (and why not? They're cool!) then let me brainstorm an alternative:
 a) whitelisted sites (like AMO) can preview and install themes as now (no prompt first)
 b) any site can attempt to install a theme, but if they do they get a doorhanger confirmation
    prompt _first_ similar to the one for installing an addon.
 c) the prompt on non-whitelisted sites has a "never for this site" option like other
    permission doorhangers, so the user can easily deal with annoying sites.
 d) in no case does Firefox prompt the user to add the site to the whitelist
 e) after installing a theme non-whitelisted sites (at least) get the undo bar

I think this means non-whitelisted sites don't get to "preview" themes because it would be odd for a user to get a prompt, have the theme go away, and then if they like it get another prompt when it was installed for real. Or maybe a preview gets the initial prompt and an infobar with "this is a preview, click here to keep this theme".

On usability grounds I think you still want the "undo" bar after installing a theme. You could justify getting rid of it for whitelisted special-purpose install sites like AMO. Is this really annoying users? Doesn't seem like it's going to happen all that much.
Flags: needinfo?(dveditz)

Updated

2 years ago
Flags: needinfo?(amckay)

Updated

2 years ago
Priority: -- → P3
(Reporter)

Comment 9

2 years ago
Part of my goal here is to try and get themes, extensions and add-ons using a similar interface for users sake (why do they look and act differently) and from a code point of view (let's reduce the amount of stuff we have to maintain). There will and should be differences between the two, but lets try and minimize those.

(In reply to Daniel Veditz [:dveditz] from comment #8)
> If you want to encourage more sites to use Lightweight themes (and why not?
> They're cool!) then let me brainstorm an alternative:
>  a) whitelisted sites (like AMO) can preview and install themes as now (no
> prompt first)
>  b) any site can attempt to install a theme, but if they do they get a
> doorhanger confirmation
>     prompt _first_ similar to the one for installing an addon.
>  c) the prompt on non-whitelisted sites has a "never for this site" option
> like other
>     permission doorhangers, so the user can easily deal with annoying sites.
 
Markus, how does this fit in with your other suggested UX changes to the install flow?

>  d) in no case does Firefox prompt the user to add the site to the whitelist
>  e) after installing a theme non-whitelisted sites (at least) get the undo
> bar

+1, on pure self interest AMO and the disco pane could avoid the undo bar. Since there's an uninstall now right in the disco pane (and soon in AMO) that interaction is really nice for users, the undo bar just gets in the way.

I wonder if we can make this prompt the same as all the other permissions and doorhangers.

> I think this means non-whitelisted sites don't get to "preview" themes
> because it would be odd for a user to get a prompt, have the theme go away,
> and then if they like it get another prompt when it was installed for real.
> Or maybe a preview gets the initial prompt and an infobar with "this is a
> preview, click here to keep this theme".

> On usability grounds I think you still want the "undo" bar after installing
> a theme. You could justify getting rid of it for whitelisted special-purpose
> install sites like AMO. Is this really annoying users? Doesn't seem like
> it's going to happen all that much.

BTW, I have regrets with all themes, but then I'm a boring person who likes the default.
Flags: needinfo?(amckay) → needinfo?(mjaritz)
Whiteboard: [UX needed] → [UX needed]triage
(Reporter)

Updated

2 years ago
Summary: Remove the the undo option for theme install → Improve lightweight theme installation
(Reporter)

Updated

2 years ago
Depends on: 1298989
(Reporter)

Updated

2 years ago
Whiteboard: [UX needed]triage → [UX needed]triaged
The main experience will be Themes provided through AMO as it is now. 

(In reply to Markus Jaritz [:maritz] (UX) from comment #5)
> I think we should wait with removing undo until we have another
> way for users to easily undo a theme they (accidentally) installed. Like the
> new install switch. (And maybe by then we can replace the whole bar with the
> confirmation panel we use for extensions on disco pane.)

As soon as we have undo in form of uninstall in AMO we can remove the undo-bar for installs through AMO. If we want we can remove it now already for disco pane.

How we deal with 3rd party sites offering themes is an issue for considerably less users. It can be handled as Daniel suggests. However, instead of the undo-bar, I would then use the same install confirmation we use for extensions, but with an added undo option - or a notice of how to revert back.
Flags: needinfo?(mjaritz)

Comment 11

7 months ago
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Last Resolved: 7 months ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.