Closed Bug 1171693 Opened 4 years ago Closed 4 years ago

Add note about CDM downloads to about:rights

Categories

(Firefox :: General, defect, P1, major)

defect

Tracking

()

VERIFIED FIXED
Firefox 41
Tracking Status
firefox39 + wontfix
firefox38.0.5 --- wontfix
firefox40 --- wontfix
firefox41 --- fixed
firefox44 --- verified
firefox45 --- verified

People

(Reporter: gpiper, Assigned: Dolske)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

We need the following text added to the "about:rights" page (listed as a new bullet last in the list):

"In order to play back certain types of video content, Firefox downloads certain content decryption modules from third parties."
Assignee: nobody → dolske
Severity: normal → major
Priority: -- → P1
Attached patch Patch v.1Splinter Review
Couple of notes:

* I didn't update the Android version of about:rights (mobile/android/chrome/content/aboutRights.xhtml). AFAIK we don't (yet?) support CDMs on Android, so I'm assuming we don't want have about:rights claim something we don't actually do. I thought about making this conditional on some #ifdef/setting to make it future-proof, but I don't think there's anything appropriate to check. So if we do add Android CDM support in the future, someone will need to update about:rights there.

* As of bug 1160101, we don't even attempt to download the Adobe CDM unless it's an official Firefox build (which includes official builds of Nightly/Aurora/Beta). So I didn't add this string to the "unbranded" version of about:rights (toolkit/content/aboutRights-unbranded.xhtml). Given why DRM and CDMs exist, it seems unlikely to me that there would ever be a 3rd party CDM that would be happy running in an unknown environment. (And, as with Android, there doesn't seem to be a suitable thing to check to make this future-proof.)

* I'm assuming we do not want this statement in about:rights to be conditional on the user having DRM enabled. (i.e. should we hide if the user has disabled DRM and CDM downloads per https://support.mozilla.org/en-US/kb/enable-drm, or if they're using the "DRM free" download of Firefox that has this already disabled). 

Let me know if any of these assumptions are incorrect!
Attachment #8617584 - Flags: review?(gijskruitbosch+bugs)
(In reply to Justin Dolske [:Dolske] from comment #1)
> Created attachment 8617584 [details] [diff] [review]
> Patch v.1
> 
> Couple of notes:
> 
> * I didn't update the Android version of about:rights
> (mobile/android/chrome/content/aboutRights.xhtml). AFAIK we don't (yet?)
> support CDMs on Android, so I'm assuming we don't want have about:rights
> claim something we don't actually do. I thought about making this
> conditional on some #ifdef/setting to make it future-proof, but I don't
> think there's anything appropriate to check.

#ifdef MOZ_ADOBE_EME ?
[Tracking Requested - why for this release]:

We should uplift this change to Beta 39. It is a simple HTML change to mention that Firefox may download Adobe's CDM.
Comment on attachment 8617584 [details] [diff] [review]
Patch v.1

Review of attachment 8617584 [details] [diff] [review]:
-----------------------------------------------------------------

I like how we're internally numbering these points in an unordered list. :-)

(and no, don't think we need this for android, though there maybe we should be saying something about how we use the decoders on the device/OS to do video playback, even if not DRM-decrypting?)
Attachment #8617584 - Flags: review?(gijskruitbosch+bugs) → review+
(In reply to Chris Pearce (:cpearce) from comment #2)
> (In reply to Justin Dolske [:Dolske] from comment #1)
> > Created attachment 8617584 [details] [diff] [review]
> > Patch v.1
> > 
> > Couple of notes:
> > 
> > * I didn't update the Android version of about:rights
> > (mobile/android/chrome/content/aboutRights.xhtml). AFAIK we don't (yet?)
> > support CDMs on Android, so I'm assuming we don't want have about:rights
> > claim something we don't actually do. I thought about making this
> > conditional on some #ifdef/setting to make it future-proof, but I don't
> > think there's anything appropriate to check.
> 
> #ifdef MOZ_ADOBE_EME ?

I missed this comment; that seems like the right idea, though whether we'd use adobe's CDM and not something else on Android is another question that I am not the right person to answer.

Re: 39 - this is going to be "fun" because l10n freeze. :-\
Tracking 39 because 39 is affected. Requesting more information from Liz about uplift.
Flags: needinfo?(lhenry)
Axel, flod, looks like an incoming l10n request for beta.
Flags: needinfo?(lhenry)
Flags: needinfo?(l10n)
Flags: needinfo?(francesco.lodolo)
(In reply to :Gijs Kruitbosch from comment #5)
> (In reply to Chris Pearce (:cpearce) from comment #2)
...
> > #ifdef MOZ_ADOBE_EME ?
> 
> I missed this comment; that seems like the right idea, though whether we'd
> use adobe's CDM and not something else on Android is another question that I
> am not the right person to answer.

That's why I didn't use this -- it's for a particular CDM, and not for the general notion of "might download a CDM". Given that all this stuff is kinda new, it's probably just not realistic to make things solidly future-proof right now. :)
I think there are a few questions to ask to the folks that request this change:

- I don't suspect there's a legal aspect to this? I.e., any particular care for the actual translations required? The string doesn't sound like it, but want to make sure.

- Is this critical to 39?

- What's the appropriate answer for a late l10n landing, show English text or no text?

Note, this is late for both 39 and 40. 39 is out of scope for the majority of our locales, 40 is more on a "we might be lucky on some".
Flags: needinfo?(l10n)
Flags: needinfo?(francesco.lodolo)
My understanding from Geoff is that this does not need to land in 40.
If this can ride with 41, which is currently in nightly, then we can avoid breaking the string freeze and a lot of hassle.
https://hg.mozilla.org/mozilla-central/rev/0cf6fd563bf7
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 41
Summary: Addition to About:rights → Add note about CDM downloads to about:rights
I have seen this issue in nightly 41.0a1 (2015-06-04)(Build ID:20150604030205)

Verified as fixed on latest Bata 41.0b7 (Build ID: 20150903133607)

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:41.0) Gecko/20100101 Firefox/41.0

[testday-20150904]
(In reply to Justin Dolske [:Dolske] from comment #1)
> * As of bug 1160101, we don't even attempt to download the Adobe CDM unless
> it's an official Firefox build (which includes official builds of
> Nightly/Aurora/Beta). So I didn't add this string to the "unbranded" version
> of about:rights (toolkit/content/aboutRights-unbranded.xhtml).

Justin, I see "In order to play back certain types of video content, &brandShortName; downloads certain content decryption modules from third parties." in the about:rights page of Beta 41, but not Aurora 42 or Nightly 43. Are you sure Nightly and Aurora are not "unbranded"? I thought only Beta and Release were considered branded. Since Nightly and Aurora do download the Adobe CDM, their about:rights page should definitely include this string.
Flags: needinfo?(dolske)
(In reply to Chris Peterson [:cpeterson] from comment #15)
> (In reply to Justin Dolske [:Dolske] from comment #1)
> > * As of bug 1160101, we don't even attempt to download the Adobe CDM unless
> > it's an official Firefox build (which includes official builds of
> > Nightly/Aurora/Beta). So I didn't add this string to the "unbranded" version
> > of about:rights (toolkit/content/aboutRights-unbranded.xhtml).
> 
> Justin, I see "In order to play back certain types of video content,
> &brandShortName; downloads certain content decryption modules from third
> parties." in the about:rights page of Beta 41, but not Aurora 42 or Nightly
> 43. 

Let's deal with this over in bug 1198525.
Flags: needinfo?(dolske)
I have reproduced this bug with Firefox Nightly 41.0a1 (Build ID: 20150604030205) on 
windows 8.1 64-bit with the instructions from comment 0 .

Verified as fixed with Firefox Aurora 44.0a2 (Build ID: 20151210004006)
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0

Verified as fixed with Firefox Nightly 45.0a1 (Build ID: 20151209095500)
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
QA Whiteboard: [bugday-20151211]
Confirmed Resolved status with Aurora 44.0a2 (2015-12-10) 

Mozilla/5.0 (Windows NT 6.1; rv:44.0) Gecko/20100101 Firefox/44.0
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.