Closed Bug 1280829 Opened 5 years ago Closed 4 years ago

Widevine videos on my.xfinity.net do not play

Categories

(Core :: Audio/Video: Playback, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla52
Tracking Status
firefox48 --- wontfix
firefox49 --- wontfix
firefox50 --- verified
firefox51 --- verified
firefox52 --- verified

People

(Reporter: cpeterson, Assigned: cpearce)

References

()

Details

Attachments

(1 file)

STR:
1. Spoof Chrome UA!
2. Disable Shockwave Flash plugin (so site doesn't prefer it).
3. Load http://my.xfinity.com/video/
4. Try to play a video.

RESULT:
The video shows a loading spinner for 10–20 seconds before giving up without any obvious error message. You can see the EME icon in the address bar and the following browser console message:

MediaKeySystemAccess::GetKeySystemStatus(com.widevine.alpha, minVer=-1) result=available version='1.4.8.866' msg=''
needinfo cpearce to test. You do not need a Comcast/Xfinity account to watch these videos. Don't forget to disable Flash!
Flags: needinfo?(cpearce)
Priority: -- → P2
Mass change P2 -> P3
Priority: P2 → P3
The problem here is that the site creates a Widevine CDM, and attaches it to the media element, but then plays non encrypted content through the media element, and our logic to prevent non-MSE video working with EME triggers and blocks playback. If I set the pref media.eme.mse-only=false, playback works fine.

We need to make our logic to block EME in non-MSE smarter.
Flags: needinfo?(cpearce)
Also worth pointing out, with Flash disabled, I didn't need to spoof my UA to Chrome's.
Assignee: nobody → cpearce
Summary: Widevine videos on my.xfinity.net do not play (when spoofing Chrome UA) → Widevine videos on my.xfinity.net do not play
Comment on attachment 8793124 [details]
Bug 1280829 - Only block non-MSE content which is encrypted once it reaches load metadata.

https://reviewboard.mozilla.org/r/79906/#review78660
Attachment #8793124 - Flags: review?(jyavenard) → review+
Pushed by cpearce@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/38b23abc04be
Only block non-MSE content which is encrypted once it reaches load metadata. r=jya
https://hg.mozilla.org/mozilla-central/rev/38b23abc04be
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
Chris, is this something you are looking to uplift?
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #9)
> Chris, is this something you are looking to uplift?

Yes! Thanks for the reminder.
Flags: needinfo?(cpearce)
Comment on attachment 8793124 [details]
Bug 1280829 - Only block non-MSE content which is encrypted once it reaches load metadata.

Approval Request Comment
[Feature/regressing bug #]: EME
[User impact if declined]: Some sites which initialize EME but try to play non-EME video (in the video which has EME initialized) will refuse to play.
[Describe test coverage new/current, TreeHerder]: We have plenty of EME mochitests.
[Risks and why]: Low; we're some guards that cause us to refuse to playback, but the remaining guard is very reliable; all playbacks pass through it, so I'm confident this will work.
[String/UUID change made/needed]: None.
Attachment #8793124 - Flags: approval-mozilla-beta?
Attachment #8793124 - Flags: approval-mozilla-aurora?
Comment on attachment 8793124 [details]
Bug 1280829 - Only block non-MSE content which is encrypted once it reaches load metadata.

Aurora51+, Beta50+
Attachment #8793124 - Flags: approval-mozilla-beta?
Attachment #8793124 - Flags: approval-mozilla-beta+
Attachment #8793124 - Flags: approval-mozilla-aurora?
Attachment #8793124 - Flags: approval-mozilla-aurora+
does not apply cleanly to beta:

Tomcats-MacBook-Pro-2:mozilla-central Tomcat$ hg graft --edit -r 2d7f4fd136fa
grafting 366227:2d7f4fd136fa "Bug 1280829 - Only block non-MSE content which is encrypted once it reaches load metadata. r=jya, a=ritu"
merging dom/html/HTMLMediaElement.cpp
warning: conflicts while merging dom/html/HTMLMediaElement.cpp! (edit, then use 'hg resolve --mark')
Flags: needinfo?(cpearce)
I've managed to reproduce this issue on an older Nightly build from 2016-06-19 with STR provided by Chris.

This is verified fixed on Firefox 50.0b4-build1 (2016-10-03), latest Aurora 51.0a2 (2016-10-04) and latest Nightly 52.0a1 (2016-10-04) across platforms:
- Windows 10 x64
- Ubuntu 16.04 X64 LTS
Also this issue is verified fixed on 50.0b4-build1 (2016-10-03) and latest Aurora 51.0a2 (2016-10-04) running macOS 10.12.1.

Unfortunately, with the latest Nightly build (2016-10-04), I can still reproduce the issue on Mac OS X 10.10.4 and 10.12.1. I see the loading spinner for a few seconds and then it stops, as reported in comment 0. 
What do you think about this, Chris?
Thank you for checking this Ciprian.

This regressed after I landed my patch in Nightly, between 2016-09-28 and 2016-09-29. It's regressed in 32bit Windows as well. I'll open a new bug for that.
Filed bug 1307595 to track fixing the regression.
This is verified fixed on latest Nightly/Aurora builds from 2016-10-10 on the following OSes:
- Windows 7 x64
- Ubuntu 16.04 x64 LTS
- Mac OS X 10.11.6

Per comment 16 and based on verification from above, I will set the flags accordingly.
You need to log in before you can comment on or make changes to this bug.