1135010 - Ensure EME support/disabled warning notification bars take fallbacks used by the website into account

Status: RESOLVED WONTFIX

(Firefox :: General, defect)

Description

[:Gijs (he/him)]

(In reply to Chris Pearce (:cpearce) from bug 1111153 comment #31)
> So if a site tries to start EME but fails, we can detect that and show UI,
> but what if the site also detects that failure and falls back to use
> Silverlight or Flash, or some other plugin? Then we'll be showing the
> notification bar saying the site requires something in order to work, but
> the site is still working...

Stephen/Georg, can we detect silverlight (being used by the page) ? I would expect the page not to initialize silverlight until after the HTML5 route fails (graceful fallback). That will presumably affect what we can do here. I suppose we could theoretically check if silverlight is at least installed and enabled and then either wait with showing UI to see if the page initializes silverlight, and/or hide the UI if it's created, or something?

Javaun/Dolske, thoughts about if/what we want to do here for v1?

Comment 1

[Stephen A Pohl [:spohl]]

(In reply to :Gijs Kruitbosch from comment #0)
> (In reply to Chris Pearce (:cpearce) from bug 1111153 comment #31)
> > So if a site tries to start EME but fails, we can detect that and show UI,
> > but what if the site also detects that failure and falls back to use
> > Silverlight or Flash

How will the site detect this failure? If we're responsible for notifying the site of a failure, shouldn't we wait to notify the site until after we know whether or not the user has gone through whatever steps are necessary to use EME?

Comment 2

[Stephen A Pohl [:spohl]]

(In reply to Stephen Pohl [:spohl] from comment #1)
> (In reply to :Gijs Kruitbosch from comment #0)
> > (In reply to Chris Pearce (:cpearce) from bug 1111153 comment #31)
> > > So if a site tries to start EME but fails, we can detect that and show UI,
> > > but what if the site also detects that failure and falls back to use
> > > Silverlight or Flash
> 
> How will the site detect this failure? If we're responsible for notifying
> the site of a failure, shouldn't we wait to notify the site until after we
> know whether or not the user has gone through whatever steps are necessary
> to use EME?

After reading this again I realize I may have misunderstood the question: Is the question what we should do with the notification presented to the user when the site opted to fall back to Flash or Silverlight? Couldn't we choose text for the notification bar that would take this into account? Such as: "This website tried using EME, but you disabled it. This website may offer an alternative player for this content, or you can enable EME by clicking here."

Comment 3

[:Gijs (he/him)]

(In reply to Stephen Pohl [:spohl] from comment #2)
> After reading this again I realize I may have misunderstood the question: Is
> the question what we should do with the notification presented to the user
> when the site opted to fall back to Flash or Silverlight?

Yes. Also note that there are various possibilities for the notifications (API disabled, CDM disabled, CDM not supported (on this platform/architecture), CDM too old (ie we want a newer version), CDM still downloading/installing. But yes, we could update them. :-)

> Couldn't we choose
> text for the notification bar that would take this into account? Such as:
> "This website tried using EME, but you disabled it. This website may offer
> an alternative player for this content, or you can enable EME by clicking
> here."

Changing the strings here is one option, yes, although it's a bit late for v1 / 38 unless we act very quickly (ie before Monday's uplift).

Comment 4

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

(In reply to :Gijs Kruitbosch from comment #0)
> Stephen/Georg, can we detect silverlight (being used by the page) ?

From the Gecko side, this is quite easy. However, how would you distinguish between Flash playing an ad and Flash playing the actual video? You'd need heuristics, which could fail some of the time.


(In reply to Stephen Pohl [:spohl] from comment #1)
> How will the site detect this failure?

The EME JavaScript APIs report the failure to script.

> If we're responsible for notifying
> the site of a failure, shouldn't we wait to notify the site until after we
> know whether or not the user has gone through whatever steps are necessary
> to use EME?

The EME JS APIs are async, so we could do this.

Comment 5

[Justin Dolske [:Dolske]]

This came up before, the question is if sites are actually likely to have fallback or not. It seems likely that most users are not going to disable DRM, and so this becomes an edge-case that sites might just ignore. And AIUI, serving DRM has financial / business costs, so there are pressures to minimize how many DRM flavors are being served.

Also, even with fallback we'd (arguably) still want to show this UI to encourage people to prefer an HTML5 implementation instead of Flash/Silverlight (due to the serious performance and stability problems they're causing).

Chris: do we know what our initial launch partner is planning to do? If they're not doing fallback (specifically, try EME and fallback upon failure), then I think this pretty clearly isn't something we need to worry about right away.

Comment 6

[Georg Fritzsche [:gfritzsche]]

(In reply to :Gijs Kruitbosch from comment #0)
> (In reply to Chris Pearce (:cpearce) from bug 1111153 comment #31)
> > So if a site tries to start EME but fails, we can detect that and show UI,
> > but what if the site also detects that failure and falls back to use
> > Silverlight or Flash, or some other plugin? Then we'll be showing the
> > notification bar saying the site requires something in order to work, but
> > the site is still working...
> 
> Stephen/Georg, can we detect silverlight (being used by the page) ?

We can definitely detect when Flash or Silverlight is loaded in a page, but i'm not sure if this is a reliabe indicator for a fallback being loaded by the site.
At least Flash is being used all over the place and could be loaded later by ads, sound player or some "copy to clipboard" functionality.

Comment 7

[:Gijs (he/him)]

(In reply to Justin Dolske [:Dolske] from comment #5)
> This came up before, the question is if sites are actually likely to have
> fallback or not. It seems likely that most users are not going to disable
> DRM, and so this becomes an edge-case that sites might just ignore. And
> AIUI, serving DRM has financial / business costs, so there are pressures to
> minimize how many DRM flavors are being served.
> 
> Also, even with fallback we'd (arguably) still want to show this UI to
> encourage people to prefer an HTML5 implementation instead of
> Flash/Silverlight (due to the serious performance and stability problems
> they're causing).

Yeah. There's the additional point that you *can* turn off the "you've disabled this" notification permanently from the notification itself, so I guess for that case, I'm not too worried. Unsupported OS is probably the biggest "problem", but then, those user groups are also comparatively small... So maybe we shouldn't worry about it too much?
 
> Chris: do we know what our initial launch partner is planning to do? If
> they're not doing fallback (specifically, try EME and fallback upon
> failure), then I think this pretty clearly isn't something we need to worry
> about right away.

Per bug 1131758 comment #5, I believe they will do fallback.

Comment 8

[:Gijs (he/him)]

It seems to me, judging by comment #4 and comment #6, that trying to detect the fallback likely won't work well. This leaves two options (thanks, Chris/Stephen for the suggestion!):

1) improve messaging (and potentially make the "unsupported" notification dismissible as well? Don't know if it's worth doing that per-site...)
2) make the disabled case effectively wait for some time / forever for the user to enable EME if it's disabled? Wonder if that doesn't then introduce latency that the site/user doesn't want, though... OTOH, this also sounds like a more significant engineering/UX effort (what kind of UI would we use, what kind of timeout / do we just wait forever) for an odd user segment: EME is disabled, but they do have plugins that support DRM installed. Seems likely to me that if they're against EME, they're also less likely to have such plugins, and then the fallback won't work either, so it's a bit of a waste to try to optimize for that case.

Plus, showing them UI every time might be seen as trying to "convince" them that they should be enabling that. This goes back to the second para of comment #5 as well: if the fallback would work, it seems like there's a technical merit to them enabling EME and not needing the fallback, and it seems odd to disable it for HTML5 and not for plugins? Or am I missing reasons for why you'd disable the HTML5 solution and still be using the EME-inclusive plugins?

Comment 9

[Javaun Moradi [:javaun]]

Knowing that the v1 is available on limited platforms and will be throttled, is it likely that percentage of clients playing via NPAPI plugin may be high at the outset? And will many of them see this notification? 

(In reply to Justin Dolske [:Dolske] from comment #5)
 It seems likely that most users are not going to disable
> DRM, and so this becomes an edge-case that sites might just ignore.

> Chris: do we know what our initial launch partner is planning to do? If
> they're not doing fallback (specifically, try EME and fallback upon
> failure), then I think this pretty clearly isn't something we need to worry
> about right away.

Comment 10

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

(In reply to Justin Dolske [:Dolske] from comment #5)
> Chris: do we know what our initial launch partner is planning to do? If
> they're not doing fallback (specifically, try EME and fallback upon
> failure), then I think this pretty clearly isn't something we need to worry
> about right away.

I don't specifically know what they'll do. I assume they'll fallback.

It seems unlikely to me that a user who's paid for a subscription to a streamer of DRM video will disable EME, so we can probably punt on this problem for now.

Comment 11

[Chris Peterson [:cpeterson]]

cpearce: is this problem now handled by your change to delay the EME promise resolution until the CDM has been downloaded?

Comment 12

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

It would be if we'd implemented it yet, but we don't.

Comment 13

[Chris Peterson [:cpeterson]]

(In reply to Chris Pearce (:cpearce) from comment #12)
> It would be if we'd implemented it yet, but we don't.

cpearce: do we need to implement the delay-until-downloaded EME promises for 38? Do we need a separate bug for that? Enabling the content provider to handle the error inline with their content sounds like a better UX than Firefox using heuristics to detect plugins and show a warning in a notification bar.

Comment 14

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

I am going to delay the resolution of navigator.requestMediaKeysystemAccess() while we know that the Adobe CDM is enabled but not yet downloaded, based on the values of the prefs, in Bug 1146201.

Given that there's only a 60 second window when this can happen when updating Firefox from a build that doesn't support EME to a build that does support EME, and users are unlikely to update and immediately go to a site that uses EME, we can probably just WONTFIX this given my pending fix in Bug 1146201.

Comment 15

[:Gijs (he/him)]

SGTM!