1111160 - [EME] Need specific errors when playback fails due to CDM problems.

Status: RESOLVED FIXED

(Core :: Audio/Video, defect)

Description

[Justin Dolske [:Dolske]]

When media playback fails due to unavailability of a required CDM, Firefox UI (bug 1111155 and bug 1111153) would like to specifically indicate what the problem was.

I think the 4 interesting cases are:

1) CDM is installed but specifically disabled
2) All DRM support has been disabled (media.eme.enabled == false)
3) Required CDM is not supported by Firefox
4) We're still trying to download the CDM

Bug 1089885 comment 2 is basically what's needed.

Note that the default videocontrols are only have content privileges (for bug 1111155), whereas for bug 1111153 we'll have UI with chrome privileges. In bug 1089883 comment 1 I noted that there's a potential fingerprinting issue for being overly specific about why is failed, but... Given that we're only likely to support a small number of CDMs, the difference between "unsupported" and "disabled" is something the page could figure out anyway.

I'm not sure how much of this needs to be explicitly signaled by Gecko (vs figuring it out on the front-end side). But ideally it would all happen within a single error event, and ideally it would enable a site using their own custom controls to provide appropriately-specific error UI (or appropriately-nonspecific, depending on your PoV ;).

Comment 1

[Chris Pearce [:cpearce (Not reading bugmail)]]

This is a bit tricky, as in most cases the error that will happen in code not (necessarily) connected to a media element. Mostly the errors are reported to the site's script for it to handle. There's not a good way for us to handle most of these cases automatically.

The control flow is: script calls navigator.requestMediaKeySystemAccess(), which returns a promise. When the promise is resolves script will be able to create a MediaKeys object that it can use to interact with the CDM. If the requested MediaKeySystem is disabled, the promise will be rejected with an error. I don't think it makes sense for us to intercept that error, as site's script should already be handling that, and there's no easy way for us to determine if the site does in fact handle it.

Currently, if our media stack encounters an encrypted video and EME is enabled, we'll dispatch an "encrypted" event to the <video> element and wait until a MediaKeys object is assigned to the <video> element (via HTMLMediaElement.setMediaKeys).

So we won't actually report an error to the video element if a MediaKeys object is never set on a media element.



(In reply to Justin Dolske [:Dolske] from comment #0)
> I think the 4 interesting cases are:
> 
> 1) CDM is installed but specifically disabled

In this case, navigator.requestMediaKeySystemAccess() will reject the promise it returns. It's indistinguishable from case 3.

We probably will never have HTMLMediaElement.setMediaKeys() called upon the media element, and so the media stack will wait forever for a CDM/MediaKeys that will never arrive.

> 2) All DRM support has been disabled (media.eme.enabled == false)

In this case, the media stack will fire an "error" event at the <video> element, I think a "corrupted content error" message (or somesuch) appears in the video controls.

> 3) Required CDM is not supported by Firefox

In this case, navigator.requestMediaKeySystemAccess() will reject the promise it returns. It's indistinguishable from case 1.

> 4) We're still trying to download the CDM

I planned for the promise returned by navigator.requestMediaKeySystemAccess() to wait while the download is progressing. Currently I don't know how Firefox JS will communicate that to Gecko.

Comment 2

[Justin Dolske [:Dolske]]

Oops, this bug fell through the cracks. Late followup, but we'll be needing to sort this out quickly to unblock the UI work on top of it.

(In reply to Chris Pearce (:cpearce) from comment #1)
> This is a bit tricky, as in most cases the error that will happen in code
> not (necessarily) connected to a media element. Mostly the errors are
> reported to the site's script for it to handle. There's not a good way for
> us to handle most of these cases automatically.

My understanding of the concern here is that most of these conditions (1,2,4) will be rare enough that sites probably won't handle them well themselves, nor will be able to point out the specific reason something isn't working. Or, as happened with H.264, may just opt to treat all errors as "try using Chrome".

I think what you're saying is probably of more interest with case #3 -- for example, a site might try to use an unsupported CDM but then fallback to one that is supported? In which case having the browser showing an error is poor UX. [Seems like that could still be handled by removing our UI upon successful invocation of another CDM following an error.]


> > I think the 4 interesting cases are:
> > 
> > 1) CDM is installed but specifically disabled
> 
> In this case, navigator.requestMediaKeySystemAccess() will reject the
> promise it returns. It's indistinguishable from case 3.

For content, yes, but we could presumably differentiate it to chrome via a custom chrome-only event?

> > 2) All DRM support has been disabled (media.eme.enabled == false)
> 
> In this case, the media stack will fire an "error" event at the <video>
> element, I think a "corrupted content error" message (or somesuch) appears
> in the video controls.

We'll still need a way to differentiate this specific error from other errors. Maybe a chrome-only flavor of .code on the error event?

Note that the UI we're primarily interested in implementing (bug 1111153) is a chrome notification bar. For our default video controls (bug 1111155) it's not as important to be specific (although we should be as reasonably helpful when possible).

> > 3) Required CDM is not supported by Firefox
> 
> In this case, navigator.requestMediaKeySystemAccess() will reject the
> promise it returns. It's indistinguishable from case 1.
> 
> > 4) We're still trying to download the CDM
> 
> I planned for the promise returned by
> navigator.requestMediaKeySystemAccess() to wait while the download is
> progressing. Currently I don't know how Firefox JS will communicate that to
> Gecko.

Hmm, that will help in normal cases (well, the "normal" case of installing Firefox and immediately trying to open a page using DRM before the CDM can download, which seems uncommon). But there will still be slow networks, and waiting 30 minutes for something to happen with no feedback isn't great.

And then there's broken networks and locked down systems, where the CDM install may outright fail.

Comment 3

[Justin Dolske [:Dolske]]

(In reply to Chris Pearce (:cpearce) from comment #1)

> So we won't actually report an error to the video element if a MediaKeys
> object is never set on a media element.

Oh, and specifically to this part, I think it would be fine to have these errors just fire at the document/window. As a page-level notification bar, we don't actually need to tie it to a specific media element.

Comment 4

[Chris Pearce [:cpearce (Not reading bugmail)]]

I agree that these cases will be uncommon, so won't likely be handled by sites.

Thinking about this a bit deeper, I think Gecko can detect the 4 cases you're interested in, inside our Navigator::RequestMediaKeySystemAccess() implementation, and send a chromeonly event to notify chrome (as you suggested). However the gotcha here is that we can't definitively know if or when script will call navigator.requestMediaKeySystemAccess() again after the a promise returned by a previous requestMediaKeySystemAccess() call is rejected.

So as you suggest above, I think the only way you'll be able to show a notification bar is for Gecko to dispatch a chromeonly event to the doc/window when a navigator.requestMediaKeySystemAccess() promise is rejected or resolved. You need to hide the notification bar on a successful MediaKeys request.

I would suggest that chrome JS sets a short timeout when the "requestMediaKeySystemFailed" event fires (say 500ms), and if you don't receive a "requestMediaKeySystemSucceeded" event before the timeout, show the UI.

So if it works for you, I can go ahead and add add a chromeonly event that dispatches a chromeonly event to the doc/window when a navigator.requestMediaKeySystemAccess() promise is rejected or resolved. 

So... For that notification, should we use simple events, one for each failure case plus one success case, or a custom event type with a field denoting the failure reason?

(In reply to Justin Dolske [:Dolske] from comment #2)
> Hmm, that will help in normal cases (well, the "normal" case of installing
> Firefox and immediately trying to open a page using DRM before the CDM can
> download, which seems uncommon). But there will still be slow networks, and
> waiting 30 minutes for something to happen with no feedback isn't great.
> 
> And then there's broken networks and locked down systems, where the CDM
> install may outright fail.

I would argue that if it takes 30 minutes to download the CDM (which is about 7MB last time I saw an Adobe beta) that "premium" streaming video services are not going to be usable regardless of whether we have finished downloading the CDM or not.

Regardless, I think that it should be chrome JS's responsibility to report incomplete CDM download to the user. Shall Gecko dispatch a chromeonly event in this case too? We still need to figure out how chrome signals Gecko to wait for the download to complete (since the download happens in chrome code), and when the download is complete, but we can do that in another bug.

Comment 5

[Justin Dolske [:Dolske]]

(In reply to Chris Pearce (:cpearce) from comment #4)

> I would suggest that chrome JS sets a short timeout when the
> "requestMediaKeySystemFailed" event fires (say 500ms), and if you don't
> receive a "requestMediaKeySystemSucceeded" event before the timeout, show
> the UI.

Seems like a good idea.

> So if it works for you, I can go ahead and add add a chromeonly event that
> dispatches a chromeonly event to the doc/window when a
> navigator.requestMediaKeySystemAccess() promise is rejected or resolved. 

WFM!
 
> So... For that notification, should we use simple events, one for each
> failure case plus one success case, or a custom event type with a field
> denoting the failure reason?

Hmm, I don't have a strong opinion here. But probably one failure event with a field to specify the reason. 


> I would argue that if it takes 30 minutes to download the CDM (which is
> about 7MB last time I saw an Adobe beta) that "premium" streaming video
> services are not going to be usable regardless of whether we have finished
> downloading the CDM or not.

Right, but it would be ideal to be able to signal what's happening to the user. That makes the problem more apparent, and suggests a course of action (i.e., wait for the download to finish).


> Regardless, I think that it should be chrome JS's responsibility to report
> incomplete CDM download to the user. Shall Gecko dispatch a chromeonly event
> in this case too? We still need to figure out how chrome signals Gecko to
> wait for the download to complete (since the download happens in chrome
> code), and when the download is complete, but we can do that in another bug.

This is actually tough UX... Most of the time any download/install is going to happen long before the user actually attempts to do something needing a CDM (if at all!), and so interrupting whatever the user is currently doing with a mysterious error about a failure is going to be weird, at best. So I suspect we'd still want to defer telling about a failure in this background process until they actually go to use it.

Maybe, for now, we could treat it as a variation akin to #1? If the page tries to use a CDM we know about but isn't installed (because it's still downloading, failed to install, or whatever) we treat it as an error for chrome and show a generic "Firefox is having a problem, try later" message? At the least we should add telemetry for these failures so we know how often it happens and what the causes are.

I'd think this would be fair to spin off to a separate bug. I'll also note that I think the priority is to handle the unsupported/disabled CDM cases, and that while dealing with pending or broken installs is something we should do it isn't a strict requirement for the initial Firefox 38 work.

Comment 6

[Justin Dolske [:Dolske]]

Is this something you (or your delegate :) will be able to pick up soon? We'll shortly be ready to implement the front-end bits of bug 1111153 and bug 1111155, which are blocked on this.

Comment 7

[Chris Pearce [:cpearce (Not reading bugmail)]]

Sure.

Just a quick question: do you also want a generic "failed due to unspecified error" message, or do you *only* want to know about the failures in the 4 specified cases and not in other cases?

Comment 8

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Patch

Dolske: how's this?

Comment 9

[Chris Pearce [:cpearce (Not reading bugmail)]]

Would it be better to use an observer service notification, then we can pass arbitrary data (like an error code) over in the "someData" field of the notification?

Comment 10

[Justin Dolske [:Dolske]]

(In reply to Chris Pearce (:cpearce) from comment #7)

> Just a quick question: do you also want a generic "failed due to unspecified
> error" message, or do you *only* want to know about the failures in the 4
> specified cases and not in other cases?

Do we know anything about the possible causes/fixes for such general errors?

Probably fine to have a generic event, but I don't know that we'd want to hook up UI for it. The other 4 are for fairly specific things that a user can act upon, whereas this isn't.

(In reply to Chris Pearce (:cpearce) from comment #9)
> Would it be better to use an observer service notification, then we can pass
> arbitrary data (like an error code) over in the "someData" field of the
> notification?

Events or notifications would be fine. I'd gently prefer events as being more webby and avoiding XPCOM goopyness.

Gijs: any opinion on the above?

Comment 11

[Justin Dolske [:Dolske]]

Comment on attachment 8559427 [details] [diff] [review]
Patch

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

::: dom/base/Navigator.cpp
@@ +2600,5 @@
>  }
>  
>  #ifdef MOZ_EME
> +void
> +Navigator::DispatchChromeOnlyEvent(const nsAString& aEventName)

I think we'll want to be able to link up the event with the relevant... key system?

Specifically for the CDMDisabled case (so we know which one to enable), but could be useful for the others even if we don't show it in the UI.

I see you've already commented in 1129370, we probably want to pass the same thing around for both cases.

Comment 12

[Justin Dolske [:Dolske]]

Speaking of, I guess Gijs already implemented bug 1127416 using the observer service.

Comment 13

[:Gijs (he/him)]

Yes, either an observer service notification or a custom event with the relevant bits in the event.detail field would work.

Comment 14

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Patch v2: Using observer service

Dispatch observer service notification when a request to access CDM is denied and there's something the user can do about it (flip a pref, etc). Include the keySystem string and reason for denial in JSON as data to notification.

We also notify when the CDM is successfully created, and provide the keySystem as data in that case too.

I've tested this locally, and will follow up with a patch to change test_eme_obs_notification.html (or somesuch) to also test these.

Comment 15

[:Gijs (he/him)]

Comment on attachment 8562690 [details] [diff] [review]
Patch v2: Using observer service

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

(stealing!)

From looking over the code, this looks like it'd do what we need, but for the below...

::: dom/base/Navigator.cpp
@@ +2620,5 @@
> +{
> +  nsAutoString data;
> +  data.AppendPrintf("{\"keySystem\":\"%s\",\"reason\":\"%s\"}",
> +                    NS_ConvertUTF16toUTF8(aKeySystem).get(),
> +                    KeySystemStatusToNotification(aStatus));

If I'm a webpage and ask for keySystem 'org.foo.here"aresomequotes', does this break the JSON in the way I expect it would here (when trying to tell chrome that the page is asking for an unsupported keysystem), or is there some other reason that won't even make it to this code? :-)

Comment 16

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8562690 [details] [diff] [review]
Patch v2: Using observer service

>+      return NS_LITERAL_STRING("cdm-disabled").get();

This is returning a pointer into a temporary object.  That seems pretty fishy.

You should probably do:

  return MOZ_UTF16("cdm-disabled");

>+      return NS_LITERAL_STRING("cdm-supported").get();

"cdm-not-supported", perhaps?

>+  data.AppendPrintf("{\"keySystem\":\"%s\",\"reason\":\"%s\"}",
>+                    NS_ConvertUTF16toUTF8(aKeySystem).get(),
>+                    KeySystemStatusToNotification(aStatus));

Are you guaranteed that aKeySystem is ASCII?  Because if not, this will corrupt the string, no?

Given that this string is passed in directly from JS, I doubt you're guaranteed that.  So what you probably want to do is use an nsPrintfCString and then do a UTF-8-to-UTF-16 conversion on it afterward.

Also, I'm a bit confused about KeySystemStatusToNotification here.  It's returning char16_t*, but then you pass it to something that expects char*?  Won't this just always truncate after the first (or zeroth, depending on endianness) char?

> +  obs->NotifyObservers(nullptr, "request-cdm-failed", data.get());

Should probably null-check obs.

>+  auto status = MediaKeySystemAccess::IsKeySystemSupported(aKeySystem);

Is there a reason to avoid writing KeySystemStatus on the lhs, there?  That doesn't seem like a complex-enough type to hide under "auto".

Also, it's odd to have a function called IsKeySystemSupported that returns something other than a boolean.  A better name is probably in order.

>+      return KeySystemStatus::kKeySystemNotInstalled;

So if IsKeySystemSupported returns this, we won't immediately reject the promise.  What will the page observe in this case?  Just a promise that never settles?  Same thing when kKeySystemDisabled is returned, or kKeySystemNotSupported.

>+    if (IsVistaOrLater()) {
>+      return KeySystemStatus::kKeySystemNotSupported;
>+    }

Isn't this test backwards?

>+  data.AppendPrintf("{\"keySystem\":\"%s\"}", NS_ConvertUTF16toUTF8(mKeySystem).get());

Again, this will corrupt a non-ASCII mKeySystem.

>+  obs->NotifyObservers(nullptr, "request-cdm-succeeded", data.get());

Again, need a null-check.

Comment 17

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to :Gijs Kruitbosch from comment #15)
> If I'm a webpage and ask for keySystem 'org.foo.here"aresomequotes', does
> this break the JSON

Good point! I will add code to whitelist/validate the keysystem string.

Comment 18

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Patch v3: Using observer service

* Review comments addressed.
* KeySystem string is whitelisted; if the keysystem string is unknown, the "request-cdm-failed" observer-service notification's data will be {"keySystem":"","reason":"cdm-not-supported"}.
* Also added logging for the failure case, and manually tested it. Will follow up with a regression test...

Comment 19

[:Gijs (he/him)]

Comment on attachment 8563287 [details] [diff] [review]
Patch v3: Using observer service

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

::: dom/media/eme/MediaKeySystemAccess.cpp
@@ +124,5 @@
>  #ifdef XP_WIN
>    if ((aKeySystem.EqualsLiteral("com.adobe.access") ||
> +       aKeySystem.EqualsLiteral("com.adobe.primetime"))) {
> +    // Win Vista and later only.
> +    if (!IsVistaOrLater()) {

Should we check the 64-bit-ness thing here or do that in a follow-up bug?

@@ +140,4 @@
>    }
>  #endif
>  
> +  MOZ_ASSERT(!IsKnownKeySystem(aKeySystem));

Isn't this going to crash non-Windows debug builds if you pass com.adobe.access/primetime?

Comment 20

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8563287 [details] [diff] [review]
Patch v3: Using observer service

I'm not sure what I think of the whitelisting approach.  Seems like the message for "keysystem not available", whichever one that is, should really include the keysystem...  Otherwise people who request some MS/Google thing will have no idea what went wrong.

Would it help to use an actual thing that produces JSON instead of trying to kinda pretend to be producing JSON?

The MOZ_ASSERT(!IsKnownKeySystem(aKeySystem)) seems wrong to me; it could be known but not supported, no?

Comment 21

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Boris Zbarsky [:bz] from comment #20)
> Comment on attachment 8563287 [details] [diff] [review]
> Patch v3: Using observer service
> 
> I'm not sure what I think of the whitelisting approach.  Seems like the
> message for "keysystem not available", whichever one that is, should really
> include the keysystem...  Otherwise people who request some MS/Google thing
> will have no idea what went wrong.

Well, the UX guys could comment here as to whether they *want* the keysystem string in the case where it's an unsupported keysystem. How much sense would a user make out of being shown a message "com.drmsystem.name is unsupported"? Gijs?

> Would it help to use an actual thing that produces JSON instead of trying to
> kinda pretend to be producing JSON?

Sure. What should I use?
 
> The MOZ_ASSERT(!IsKnownKeySystem(aKeySystem)) seems wrong to me; it could be
> known but not supported, no?

Naming things is hard. :/

Comment 22

[:Gijs (he/him)]

(In reply to Chris Pearce (:cpearce) from comment #21)
> (In reply to Boris Zbarsky [:bz] from comment #20)
> > Comment on attachment 8563287 [details] [diff] [review]
> > Patch v3: Using observer service
> > 
> > I'm not sure what I think of the whitelisting approach.  Seems like the
> > message for "keysystem not available", whichever one that is, should really
> > include the keysystem...  Otherwise people who request some MS/Google thing
> > will have no idea what went wrong.
> 
> Well, the UX guys could comment here as to whether they *want* the keysystem
> string in the case where it's an unsupported keysystem. How much sense would
> a user make out of being shown a message "com.drmsystem.name is
> unsupported"? Gijs?

I think in principle right now we don't care for the user-facing notification bar, and "com.foo.foopy" definitely isn't going to help the user. But we could log an error to the developer console with the requested keysystem name and that could help developers, I guess?

Part of me thinks they should already know what kind of keysystem they've requested. On the other hand, if it's provided dynamically in some way, it might still be helpful if we show it (it will help their debugging cycle in terms of "oh, we accidentally tried to use Apple's/MS's/Google's CDM in Firefox").

Comment 23

[Boris Zbarsky [:bzbarsky]]

> it will help their debugging cycle in terms of ...

Exactly.

> What should I use?

Probably the simplest thing is to define a Web IDL dictionary that describes your structure, fill it in, and then do:

  nsString json;
  if (!myDictionary.ToJSON(json)) {
    // Out of memory... handle it however you want
  }

Comment 24

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to :Gijs Kruitbosch from comment #19)
> Comment on attachment 8563287 [details] [diff] [review]
> Patch v3: Using observer service
> 
> Review of attachment 8563287 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/media/eme/MediaKeySystemAccess.cpp
> @@ +124,5 @@
> >  #ifdef XP_WIN
> >    if ((aKeySystem.EqualsLiteral("com.adobe.access") ||
> > +       aKeySystem.EqualsLiteral("com.adobe.primetime"))) {
> > +    // Win Vista and later only.
> > +    if (!IsVistaOrLater()) {
> 
> Should we check the 64-bit-ness thing here or do that in a follow-up bug?

We don't need to; the CDM downloader won't download a CDM when running in 64bit Firefox on Windows.

Comment 25

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to Chris Pearce (:cpearce) from comment #24)
> We don't need to; the CDM downloader won't download a CDM when running in
> 64bit Firefox on Windows.

.. Because we don't list a CDM in the update.xml for 64bit Windows build because Adobe hasn't supplied one yet for x64.

Comment 26

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Patch v4

Using a WebIDL dictionary. Also change to send a "mediakeys-request" notification, instead of separate success/fail notifications, as whether the request succeeded or failed can be inferred from the status in the notification's data.

Comment 27

[Chris Pearce [:cpearce (Not reading bugmail)]]

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d79a50e70050

Comment 28

[Boris Zbarsky [:bzbarsky]]

You don't happen to have an interdiff from v3 by any chance, do you?

I'll review this in the morning either way; if you do happen to have an interdiff that would be very nice.

Comment 29

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Interdiff between v3 and v4

Interdiff between v3 and v4, as requested.

Comment 30

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 8563862 [details] [diff] [review]
Patch v4

Thanks, that looks good.

One thing that may be worth it is to make the dictionary members required, like so:

 dictionary RequestMediaKeySystemAccessNotification {
   required DOMString keySystem;
   required MediaKeySystemStatus status;
 };

and then you don't need the Construct() calls; you can just assign to them.

Comment 31

[:Gijs (he/him)]

Comment on attachment 8563862 [details] [diff] [review]
Patch v4

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

Apologies for the delay, my home (office) internet is dead and today has been going "on square wheels" as we say in the Netherlands.

Anyway, this looks fine to me. I guess in bug 1129370 we can drop the notification I originally added and replace its use on the chrome side with the cdm-created one? Or would that miss cases? (I'm assuming the cdm-created thing fires for all CDMs including clearkey; I've not checked...)

Comment 32

[Chris Pearce [:cpearce (Not reading bugmail)]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/713722c64bd3

Comment 33

[Chris Pearce [:cpearce (Not reading bugmail)]]

(In reply to :Gijs Kruitbosch from comment #31)
> I guess in bug 1129370 we can drop the
> notification I originally added and replace its use on the chrome side with
> the cdm-created one? Or would that miss cases? (I'm assuming the cdm-created
> thing fires for all CDMs including clearkey; I've not checked...)

Yeah, I think this would work.

Comment 34

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/713722c64bd3

Comment 35

[Chris Pearce [:cpearce (Not reading bugmail)]]

https://hg.mozilla.org/releases/mozilla-beta/rev/4c7cf01583e2

Comment 36

[Chris Pearce [:cpearce (Not reading bugmail)]]

Attachment: Beta patch

Patch for beta branch as part of EME platform uplift.

Comment 37

[Chris Pearce [:cpearce (Not reading bugmail)]]

Comment on attachment 8572369 [details] [diff] [review]
Beta patch

Requesting retroactive approval for Beta landing as part of EME platform uplift.

Comment 38

[Lawrence Mandel [:lmandel] (use needinfo)]

Comment on attachment 8572369 [details] [diff] [review]
Beta patch

Previously approved as part of the EME platform landing on Beta.