Closed Bug 1261302 Opened 6 years ago Closed 6 years ago

Ride content notification's BOOT and push's PUSH permissions with the 48 train

Categories

(Firefox for Android Graveyard :: General, defect)

All
Android
defect
Not set
normal

Tracking

(firefox48 fixed)

RESOLVED FIXED
Firefox 48
Tracking Status
firefox48 --- fixed

People

(Reporter: sebastian, Assigned: nalexander)

References

Details

Attachments

(1 file)

The current implementation of content notifications requires a permission bump. See bug 1241810 comment 140 and following comments.

We could ship the feature without the BOOT permission. This means we could not restore the alarms to look for content updates after the device has been rebooted. After the app has been launched we can restore the alarms and check for updates again.
@barbara: I commented on the AHA card too: Content notifications require a permission bump. We could try to ship it without the permission (With the limitations mentioned in comment 0) or accept the new permission and synchronize it with the push feature which seems to require a new permission too.
Flags: needinfo?(bbermes)
If push notifications require a permission bump, we should be good to bundle it though, as push and this one are in the 48 Aha column.

Would that solve the issue?
Flags: needinfo?(s.kaspari)
Flags: needinfo?(nalexander)
Flags: needinfo?(margaret.leibovic)
Flags: needinfo?(bbermes)
(In reply to Barbara Bermes [:barbara] from comment #2)
> If push notifications require a permission bump, we should be good to bundle
> it though, as push and this one are in the 48 Aha column.
> 
> Would that solve the issue?

We should be very careful to have these two permission bumps go out together, but doing so doesn't really solve the issue; permission bumps are always an issue.

I reason as follows: Push cannot function without a permission bump, and therefore since we want push we must have a bump.  I know of no evidence suggesting that asking for 2 permissions is worse than asking for 1, so there's little harm to asking for the content notification permission at the same time.

Now, schedule.  We intend to have Push ride the 48 train, at least up to Beta to get some real testing.  Therefore we should ride this permission with the 48 train as well, and possible ride the Push permission past the actual Push feature in order to keep these two together.
Flags: needinfo?(nalexander)
I agree with Nick's assessment of the situation.
Flags: needinfo?(margaret.leibovic)
(In reply to Nick Alexander :nalexander from comment #3)
> Now, schedule.  We intend to have Push ride the 48 train, at least up to
> Beta to get some real testing.  Therefore we should ride this permission
> with the 48 train as well, and possible ride the Push permission past the
> actual Push feature in order to keep these two together.

Ok, the permission for content notification is already in 48 (No flags).

The permissions for push are currently behind MOZ_ANDROID_GCM. If they should ride the trains possibly without the feature then we need to make them independent from the flag, I guess?
Flags: needinfo?(s.kaspari)
Modifying this to track riding the permissions together.
Assignee: nobody → nalexander
Status: NEW → ASSIGNED
Summary: Content notifications: Consider shipping without boot permission → Ride content notification's BOOT and push's PUSH permissions with the 48 train
Comment on attachment 8737863 [details]
MozReview Request: Bug 1261302 - Decouple the push permission from MOZ_ANDROID_GCM. r?sebastian

https://reviewboard.mozilla.org/r/44151/#review40779
Attachment #8737863 - Flags: review?(s.kaspari) → review+
https://hg.mozilla.org/mozilla-central/rev/2ce54341d00d
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
I am a bit concerned that we are pushing APZ & new text selection which we have been waiting on for a while with a permission bump. Especially if we plan on turning off the permissions in the beta cycle.
Flags: needinfo?(margaret.leibovic)
Flags: needinfo?(bbermes)
So your proposal would be:
* Let the permissions ride up until 48.0 Beta but ship 48 without them (-> and without push / content notifications)
* Then release the features (with permissions) in 49 or later

Is this correct?

From what nalexander wrote it seems like this is something we are already considering for push. For content notifications I don't really have a strong opinion. The feature is behind a switchboard flag (Unfortunately we can't do that for permissions) and Beta might already give us plenty of data. However by the time we hit Beta we might be confident enough to release it.
Flags: needinfo?(bbermes)
(In reply to Kevin Brosnan [:kbrosnan] from comment #11)
> I am a bit concerned that we are pushing APZ & new text selection which we
> have been waiting on for a while with a permission bump. Especially if we
> plan on turning off the permissions in the beta cycle.

I'm a bit confused about what exactly your concern is here. Is it that beta users won't accept the update and we won't get enough APZ testing?

I think we should definitely plan to have the push/content notifications go out in the same release with a single permission bump, but I don't think it's a problem if that's in 48 vs. 49. However, if we are going to hold this to 49, we should decide early in the beta cycle to make sure we have time to turn these features off.

Barbara, let's make sure that the push and content notification Aha cards both have permission bump tags.
Flags: needinfo?(margaret.leibovic) → needinfo?(bbermes)
Also I hate dependencies but if content notifications slips to 49, we will need to back this out of our onboarding round 2 slides as we wanted to promote this.

Both cards have permission bumps tags.
Flags: needinfo?(bbermes) → needinfo?(alam)
Flags: needinfo?(alam)
(In reply to Barbara Bermes [:barbara] from comment #14)
> Also I hate dependencies but if content notifications slips to 49, we will
> need to back this out of our onboarding round 2 slides as we wanted to
> promote this.
> 
> Both cards have permission bumps tags.

I think it's risky to couple first run slides to other experiments, we should avoid that if possible (I think there are plenty of other things for us to promote).
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.