841821 - We should display add-ons that don't work on private windows/tabs differently

Status: RESOLVED INACTIVE

(Toolkit :: Add-ons Manager, defect)

Description

[Erik Vold [:erikvold] (please needinfo? me)]

Same as bug 841793 but for Fennec.

In bug 748604 more specifically bug 820582 we are adding a private-browsing mode to add-ons made with the sdk, in order to prevent add-ons that don't support private windows from accessing them.  Which means that these add-ons won't work on private windows, which is something people might expect to see when there is no indication that the add-on is different.

I'm just a couple of ideas from the top of my head:

- change the background color
- add some warning/informational text to the addon details page, like "This add-on doesn't support private browsing"
- add a private-browsing support on/off icon

Comment 2

[Erik Vold [:erikvold] (please needinfo? me)]

Hmm I think I meant to have one of these two bugs for the Firefox product.

Comment 3

[Blair McBride [:Unfocused] (UNAVAILABLE)]

If the add-on does the wrong thing with private windows, it shouldn't get AMO review. 

Or am I missing something here?

Comment 4

[Erik Vold [:erikvold] (please needinfo? me)]

(In reply to Blair McBride [:Unfocused] (Back from the dead. Mostly.) from comment #3)
> If the add-on does the wrong thing with private windows, it shouldn't get
> AMO review. 
> 
> Or am I missing something here?

There is a new feature for sdk add-ons, they now have to opt-in to see/work with private windows/tabs

This happened because the old sdk private-browsing module was too closely intertwined with the global pb implementation, so we had to break that api when per window private browsing (pwpb) was introduced.  Then we discovered that the sdk panel module API had to be redesigned to support pwpb, and since a lot of ui modules are used in combination with panel we had to implement this private-browsing permission feature which add-on devs now have to opt-in to in order to see private windows..

I'm not sure we should make this a priority yet though, take it easy for now Blair.

We should discuss this with UX at some point before implementing anything too I think.

I'll get back to you in this bug later.

Comment 5

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Ah, ok.

(In reply to Erik Vold [:erikvold] [:ztatic] from comment #4)
> I'm not sure we should make this a priority yet though

Agreed. My impression is that adding something to indicate this in the Add-ons Manager UI isn't going to achieve much, but it will add noise to the UI. Though I'd like to hear what UX thinks.

If we were to want something like this, I think I'd like to explore doing is as a first step in a larger scope - so we can display various traits add-ons have (private windows isn't all that special, IMO), but in a way that we know adds benefit and not noise.

Comment 7

[BMO Automation]

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.