1181187 - Explore shipping tab queues only for Android M users to avoid permissions bump

Status: RESOLVED WONTFIX

(Firefox for Android Graveyard :: General, defect)

Description

[:Margaret Leibovic]

In this week's funnel meeting and product meeting, there was a lot of debate over the value of the tab queues feature vs. the cost of how a permissions bump hurts our update rate.

As a potential solution, I think we should explore including the SYSTEM_ALERT_WINDOW permission with a <uses-permission-sdk-m> manifest entry, and then only show the tab queue UI if the user has granted this permission bug 1180805).

As much as it's sad to not ship tab queues to all users, this could be a good way to incrementally roll this feature out to our release population, and we can gather feedback on how people are using it. Then, if we decide that it provides a lot of value, we could talk about a release with a permissions bump, or potentially there will be another feature that requires a bump coming down the pipeline.

Martyn or Sebastian, could you look into how hard it would be to make this change? I'm hoping that if it's not too invasive, we could uplift this to Firefox 41, which may actually be well timed with the release of Android M.

Comment 1

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

I think we should also explore looking at our Beta build for stuff like this.

Comment 2

[Martyn Haigh (:mhaigh)]

Just to comment that I would prefer to ship to Beta users instead - because of the nature of the product they will be more understanding of permission bumps.

Also - do we have any figures on how many people are using Android M currently?

Comment 3

[:Margaret Leibovic]

(In reply to Martyn Haigh (:mhaigh) from comment #2)
> Just to comment that I would prefer to ship to Beta users instead - because
> of the nature of the product they will be more understanding of permission
> bumps.

I agree beta could be a good proving ground for a feature, but our beta system is designed to help us vet the quality of what we intend to ship on release, so it may be a bit risky to have a feature enabled in beta that we don't ship in release, especially one that changes our logic for loading URLs. We would need a way to make sure we're continuing to test builds that have this feature disabled, if that's what we're planning to ship.

To get around this, perhaps we could limit the build define to just wrap the permission request, and the rest of the code should be able to act appropriately depending on whether or not the permission is available (similar to what the M-style permission approach would look like).

> Also - do we have any figures on how many people are using Android M
> currently?

I would imagine it's effectively 0%, since there's only a developer preview available right now.

Comment 4

[Sebastian Kaspari (:sebastian; :pocmo)]

I wish we could push this feature to all users. I feel like this is a feature where we could really differentiate from other browsers.

Anyways, in order to use the permission features of Android M we will have to be able to build against the M SDK. To get this working we'll need to fix a subset of the bugs linked to bug 1169425. It's probably worth noting that apps build against the preview SDK only run on devices with at least(!) M (preview) - this is a restriction of the preview. So we will need to wait for and build against the final version of the SDK to create anything that is releasable. This will probably postpone the feature even more because we can't ship these M features in Nightly, Aurora, etc right now.

The permission we are talking about is SYSTEM_ALERT_WINDOW to draw on top of other applications, right? Maybe we can explore ways to ship tab queue "light" to pre-M devices without the permission - using (already existing) notifications or an overlay activity?

Comment 5

[Karen Rudnitski [:kar]]

I like the idea of exploring what *could* be done without the need for a new permissions. Let's put those options on the table whilst we get more 'permissions bump' data.

Comment 6

[Martyn Haigh (:mhaigh)]

I'm not super crazy about this idea, I'm afraid.  

We ruin the main concept behind the feature if we remove that permission.  The idea is that when the user is in another app, they can queue tabs to open, hassle free and without interfering with their current flow.  The user can click a link, see that it's been queued and keep on interacting with the original app whilst our interactive notification is still on screen.  As soon as we remove that permission we stop the flow of whatever the user is doing and we force the user to either interact with our notification or to completely stop what they're doing whilst the notification is onscreen.  Either way it doesn't work.

I'd rather hold the feature back and maintain it's original functionality than create a broken version just to prevent a permission bump.

Comment 7

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Idea: on pre-M, we could bring up a new Activity that acts as a glorified toast and dismisses itself after a brief timeout. If the user misses the ability to open now, they can use the existing notification.

We can alter the animations to make this new Activity less intrusive and still provide some context to the current app (e.g. share overlay's animation and black overlay). But as Martyn mentions...

(In reply to Martyn Haigh (:mhaigh) from comment #6)
> As
> soon as we remove that permission we stop the flow of whatever the user is
> doing and we force the user to either interact with our notification or to
> completely stop what they're doing whilst the notification is onscreen. 

It still interrupts the user's flow and is a step down from drawing directly over the active application that the user can still interact with.

Comment 8

[Sebastian Kaspari (:sebastian; :pocmo)]

We'll need to build against the Android M SDK to get the permission APIs: Bug 1183061.

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

I don't see this bug as a way forward. Tab Queues should be enabled everywhere.

Comment 10

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

bug 1147265 provides a method for displaying a non-interactive toast (with any appearance) over content. If we shipping tab queue without the super toast and relied on users using the notification bar to quick switch to Firefox, we could ship this without the permissions bump.

NI mhaigh for awareness.

Comment 11

[Martyn Haigh (:mhaigh)]

From my point of view, we should either ship TQ with the permission bump, or not at all.  We ruin it as soon as we start ripping bits out.

Comment 12

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Michael Comella (:mcomella) from comment #10)
> bug 1147265 provides a method for displaying a non-interactive toast (with
> any appearance) over content. If we shipping tab queue without the super
> toast and relied on users using the notification bar to quick switch to
> Firefox, we could ship this without the permissions bump.
> 
> NI mhaigh for awareness.

Thanks for adding this info, but I agree with Martyn. We will likely add more interactivity to TabQueue UI, not less.