When users globally out out of DRM (by unchecking the "Play DRM" pref in Preferences > Content) we should remove all DRM CDMs that have already been downloaded. (Note: opting out currently prevents future downloads and disables anything that has been downloaded). Stephen and I spoke. The implementation is up for discussion, but we were seeking the easiest path to implementation and believe our suggestion below accomplishes this. We suggest presenting a simple UX in the preferences screen where users opt out. 1. User unchecks "Play DRM" in Preferences > Content 2. A confirmation dialog appears, informing users that they "are opting out and that all DRM binaries will be deleted from their machine". Also, they "can turn this back on if they later change their mind". User clicks [Confirm] or [Cancel] 3. After user confirmation, all downloaded CDMs are deleted in the background. 4. Any downloaded CDMs that were once visible in the Add-on manager are simply gone. No new ones will appear. There is no additional UX on the add-on manager.
Priorities permitting, I would volunteer to take care of step 3 and 4. Do we want to file a separate UX bug for step 2, or is this existing behavior? Also, can we nail down what should happen when a user enables the "Play DRM" pref again? Should we check for CDMs immediately? Should we delay? What if the user toggles the pref back and forth a number of times, I'm assuming we'd want to cancel any pending checks and only perform one if the user settles on "Play DRM"? Once we know what should happen I think we'd want to file these issues as separate bugs.
Good idea Stephen. This is now the meta bug for all of this work.
Summary: Uninstallation of CDM binaries for users who opt-out of DRM → [META][EME] Uninstallation of CDM binaries for users who opt-out of DRM
[Tracking Requested - why for this release]: If deleting the CDM binary blocks our EME MVP, we should uplift this fix to 38.
tracking-firefox38: --- → ?
Does deleting CDM binaries block the EME MVP? Please confirm so we know if this needs to be tracked.
No, at this time binary deletion is not blocking MVP. I'm still working through when we need to deliver this.
In that case we won't track, yet, and when you do have a sense of the timeline we can track appropriately.
status-firefox37: --- → unaffected
status-firefox38: --- → affected
status-firefox39: --- → affected
tracking-firefox38: ? → -
Javaun: if we are creating an EME-free repack (bug 1144903), can we defer this work to delete the CDM binary to post-MVP?
Blocking EME MVP again because spohl is still investigating the uninstall feature.
Assignee: nobody → spohl.mozilla.bugs
Priority: -- → P1
Assignee: spohl.mozilla.bugs → nobody
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
NI'ing Sylvestre to make sure he's tracking this for 38 as it's now in scope. He is watching dependent Bug: 1145694, just making sure any other relevant bugs are watched.
Javaun, I am sorry but I am not sure I understand this correctly. This bug is closed and marked as wontfix for 38 ?!
Flags: needinfo?(sledru) → needinfo?(jmoradi)
This bug was WONTFIX'd when we thought uninstall the CDM binaries would be more difficult than it was. However, Stephen has since completed the work in the blocking bugs (bug 1145336, bug 1145694, and bug 1146565) and uplifted to Aurora 38. I don't think there is anything else to do here.
status-firefox38: wontfix → fixed
Yes, sorry, this is resolved and uplifted. Clearing NI.
You need to log in before you can comment on or make changes to this bug.