1612730 - videos from prosieben.at can no longer be played

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect, P2)

Description

[Sören Hentzschel]

[Tracking Requested - why for this release]:
Some videos can no longer be played in Firefox Nightly.

STR:

1. open https://www.prosieben.at/tv/schlag-den-star/video/20201-frank-rosin-kocht-mario-basler-ganze-folge
2. try to play the video

Expected:

The video works.

Actual:

The following error message appears:

LICENCE ERROR
Due to copyright restrictions, this video is not available in your current browser, or using your current browser settings. Please try viewing this video with a different browser on your device.

It also happens with other videos on this website. It works in Fiefox 73.0b11, but not in Firefox Nightly on macOS Catalina. It also happens with a new Firefox profile. There are no problems in other browsers like Google Chrome.

Comment 1

[Daniel Bodea [:danibodea]]

The video from that link does not load and play in any browser AND it shows me the "LOCATION ERROR Sorry, this video is not available in your country." on ALL browsers except Google Chrome, where it does not show any error message, just a black rectangle.
Furthermore, I have also attempted to load the video using VPN from different locations including Austria, Germania, Romania, United States... without having any positive results.

This being said, this bug appears to be invalid because the site might not work as intended OR it may not be testable from my side.
Sören Hentzschel, are you using this link from Austria? Where are you from?
Please test if the issue is reproducible in safe mode, here is a link that can help you:
https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode

Thank you for your contribution!

Comment 2

[Sören Hentzschel]

are you using this link from Austria? Where are you from?

Yes, I am using the website from Austria.

I tested again on a different computer. There is no Firefox Beta installed but Firefox Stable and Firefox Nightly. It works as expected in Firefox Stable and Google Chrome, not in Firefox Nightly.

Please test if the issue is reproducible in safe mode

Same issue in safe mode but this was expected because, as said in comment #0, it even happens with a new Firefox profile.

Comment 3

[Daniel Bodea [:danibodea]]

I have managed to reproduce this issue using the Hotspot Shield VPN Client. It appears that all Firefox browsers will show the following behavior:

Precondition: Third-party VPN app is installed and running while being set to Austria.

1. Open browser.
2. Reach the page: https://www.prosieben.at/tv/schlag-den-star/video/20201-frank-rosin-kocht-mario-basler-ganze-folge
   Notice 1: A yellow notification bar is displayed saying: "Firefox is installing components needed to play the audio or video on this page. Please try again later."
   Notice 2: The browser is now installing "Widevine Content Decryption Module provided by Google Inc.". This can be verified by going to the "about:addons" page and checking whether Widevine is displayed in the Plugins tab.
   Actual: Message displayed: "Due to copyright restrictions, this video is not available in your current browser, or using your current browser settings. Please try viewing this video with a different browser on your device."
   Expected: The video plays correctly.
3. Leave the tab open a longer time (5-10 minutes).
4. Refresh tab.
5. Play video.
   Notice 3: The video will play after a tab refresh if Widevine is installed.

NOTE: This video was played on all the last versions of the main channels.
NOTE: In some cases, the video would not play even after a long while. (I am suspecting VPN to be the culprit of the slow DMR software installation.)

I do not know what the actual issue is here, but I can suspect Widevine installation is too slow.
Since I could properly play the videos after DMR software was installed, I will change the bug title to reflect the actual issue.

Comment 4

[Sören Hentzschel]

No, this is NOT the issue I see… Widevine IS already installed and it works on other websites like Amazon Prime. Therefore I will revert the original title because the reported issue is not about the installation at all. I will also revert the keywords because it's a regression and we still need the regression window: It works in Firefox 72 and Firefox 73 but not in Firefox 74…

Comment 5

[Daniel Bodea [:danibodea]]

Considering I could make the video play in the latest versions of all channels, I cannot reproduce your issue. I want to mention again that it is most probably related to the installation of the DMR software (Widevine) AND that its installation is sometimes VERY slow. It may show as installed but still not play the video in some random cases when I would simply wait a bit longer.

Considering the fact that we appear to have a hard time reproducing it, Henrik, can you help up by regression the issue yourself?
It also may be related to your hardware.

I will try to be as clear as possible about how to do it:

You need to install an application called mozregression through the terminal:
a. Install Xcode: https://apps.apple.com/us/app/xcode/id497799835?ls=1&mt=12
b. Install Brew:

1. Open terminal.
2. Input command: /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
   c. Install Python3 with Brew:
3. Open Terminal.
4. Input command: brew install python3
   d. Install mozregression using python3:
5. Open terminal.
6. Input command: pip3 install mozregression
   More info on the installation:
   https://programwithus.com/learn-to-code/install-python3-mac/
   https://mozilla.github.io/mozregression/install.html
   https://pypi.org/project/mozregression/

You have to determine a build that reproduces the issue using the mozregression app:
a. Open terminal.
b. Open builds one by one using the command example: mozregression --launch 2019-05-24
(it will open a nightly build with that date)
c. Test your issue and note down a date of a build that reproduced the issue.
Then you should also find a build date that does NOT reproduce it, using the same method.
(You need an older good date and a more recent bad date of nightly builds.)

You will use mozregression app to "bisect" builds that reproduce the issue by builds that do not reproduce it in search of the one build/changeset that introduced the issue, in the first place:
a. Open terminal.
b. Use the good and bad build date in the following command:
mozregression --good yyyy-mm-dd --bad yyyy-mm-dd
(where the yyyy-mm-dd is the date of the good/bad build dates determined above)
c. Builds will open one-by-one, you will need to test each one of them and see whether the issue reproduces. If it reproduces, then you need to go to the terminal and write "bad" and if not, you need to write "good" button and tap enter. After your input, the current build will close and another will open for the bisection/regression process to continue.
d. When bisection is done, you will have the information in the terminal window; bisection may also fail due to not enough builds, but the logs can always be useful.
Copy the logs found in the terminal in a text file and attach it to this bug.

If there is still information you need regarding the regression process, please request information from me.
Thank you for your contribution!

Comment 6

[Sören Hentzschel]

I want to mention again that it is most probably related to the installation of the DMR software (Widevine) AND that its installation is sometimes VERY slow.

After a few days Widevine should be installed. And again: Widevine works without any problems on other services like Amazon Prime. If the problem were the slow installation of Widevine Amazon Prime would not work.

When I filed the issue I was not able to find a regression range with mozregression so maybe it has something to do with the Widevine version. I will check this and also try mozregression again later, but probably not today. I will keep the needinfo? request for now.

Comment 7

[Pascal Chevrel:pascalc]

Tracking for 74.

Comment 8

[Sören Hentzschel]

Unfortunately I am not able to find a regression range, even with older builds the error appears. I also tested with the same Widevine version as in Firefox 72 and it happened. Are there some Widevine / EME / CDM / sandbox differences between Stable / Beta and Nightly?

I noticed the following message in the web console (Nightly only):

Error: No source provided with supported DRM system for your device.

Amazon Prime, tvnow.at and DAZN still work.

Comment 9

[Jens Stutte [:jstutte]]

:danibodea, can we reproduce this now entirely?

Comment 10

[Sören Hentzschel]

I cannot reproduce in Firefox 74 Beta 1, but still in Firefox 75 Nightly. Were there some Nightly-only changes during the Firefox 74 cycle which could affect this? Both versions use the same Widevine version (4.10.1582.2). Is there some kind of media error logging?

Comment 11

[Daniel Bodea [:danibodea]]

I can now confirm comment 10. While using Nord VPN extension (with a paid subscription), the issue occurs on Nightly v75.0a1 from 2020-02-11, but does not occur on Beta v74.0b1.
I have performed a regression test using mozregression and discovered that before the last changes on this component, the behavior was the one I described in the second part of this comment. Mozregression results:

2020-02-12T16:26:48: INFO : Narrowed inbound regression window from [007007b0, 196a50e2] (4 builds) to [bdc62559, 196a50e2] (2 builds) (~1 steps left)
2020-02-12T16:26:48: DEBUG : Starting merge handling...
2020-02-12T16:26:48: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=196a50e2cdd65c3bb1098862f769610ec470ecf5&full=1
2020-02-12T16:26:49: DEBUG : Found commit message:
Bug 1568903 - Part 11: Update ecma-globals list in mocha interfaces tests. r=jorendorff
Differential Revision: https://phabricator.services.mozilla.com/D53169
2020-02-12T16:26:49: DEBUG : Did not find a branch, checking all integration branches
2020-02-12T16:26:49: INFO : The bisection is done.
2020-02-12T16:26:49: INFO : Stopped

However, another issue is encountered on the Beta build, on my system: the secondary monitor intermittently stops receiving video input when opening this video. What's special about my monitor is that it is linked through my integrated graphics card (ATI Radeon 3000 Graphics) in opposition to the primary that is linked through the dedicated graphics card (GeForce GT 1030). If I open the Beta window on the primary monitor, it will still affect the other monitor (the secondary). This issue also occurs on the Release v72.0.2, Release v73.0, ESR v68.4.2esr and ESR v68.5.0esr.
I have logged a new bug for this issue: bug 1614932.

Comment 12

[Jens Stutte [:jstutte]]

Just a wild guess: might this depend on gfx.direct3d11.use-double-buffering=true flag blocked outside of nightly by bug 1610912 / bug 1608579 ?

Comment 13

[Daniel Bodea [:danibodea]]

Switching "gfx.direct3d11.use-double-buffering" from "true" to "false" does not change anything. the issue reproduces just the same.

Comment 14

[Julien Cristau [:jcristau]]

Promise.any is nightly only.

Comment 15

[Sören Hentzschel]

Hi :anba,

I needinfo?ed you just to make sure that you're aware of the regression. Can you have a look? Thank you!

Comment 16

[André Bargull [:anba]]

I was able to reproduce the issue at https://www.prosieben.de, too, so all three ProSieben domains are probably affected (prosieben.de, prosieben.at, prosieben.ch). The website contains the following Promise.any polyfill (I've added whitespace for readability):

function(e, t, n) {
    "use strict";
    Object.defineProperty(t, "__esModule", {value: !0});
    var i = function() {
        function e() {}
        return e.polyfill = function() {
            window.Promise && (window.Promise.any = window.Promise.any || function(e) {
                var t = [],
                    n = !0,
                    i = Promise.resolve(null);
                return e.forEach((function(e, r) {
                    i = i.then((function() { return e }))
                       .then((function(e) { t[r] = e, n = !1 }))
                       .catch((function() { t[r] = void 0 }))
                })), i.then((function() {
                    return n ? Promise.reject(t) : t
                }))
            })
        }, e
    }();
    t.PromiseAny = i
}

The semantics of that polyfill probably don't match what's spec'ed at https://github.com/tc39/proposal-promise-any and got implemented in bug 1568903. I wasn't able to find any public repository (neither at GitHub nor npm) for that polyfill, so maybe it's some custom code from ProSieben?

The next steps here are probably to inform ProSieben that their polyfill doesn't match https://github.com/tc39/proposal-promise-any and therefore already breaks Firefox Nightly and in the future will also lead to issues in stable Firefox and Chrome (when https://bugs.chromium.org/p/v8/issues/detail?id=9808 gets implemented). Until the website gets fixed, we probably need to keep Promise.any restricted to Nightly to minimise the number of affected Firefox users. I don't think we need to back out bug 1568903 at this point, because only a single website is affected.

I wasn't able to find any contact information at prosieben.de for technical issues, just a general email address for viewer questions/problems at https://www.prosieben.de/service/kontakt-hilfe: <[e-mail]>.

Comment 17

[André Bargull [:anba]]

Hi Jason. Do you know who to contact from Moz to handle these kinds web-compat issues with websites? Thanks!

Comment 18

[Jens Stutte [:jstutte]]

Anne, can you help here?

Comment 19

[Anne (:annevk)]

André, should bug 1599769 depend on bug 1568903? (Seems weird they're not linked and makes it seem as if it's shipping.)

Karl, Mike, turns out Promise.any isn't web-compatible, but it might be fine since it's a single site and Chrome will soon ship as well. See comment 16 for all the details.

Comment 20

[André Bargull [:anba]]

Sure, I can change bug 1599769 to depend on bug 1568903.

(Also clearing the NI for Jason, because my question is already handled.)

Comment 21

[Mike Taylor [:miketaylr]]

Prosieben looks like one of these mega-corps with a lot of digital outlets.... tricky to find the right folks.

I'll try reaching out to the people associated with this related-looking GitHub org, https://github.com/orgs/p7s1digital/people

Comment 22

[Mike Taylor [:miketaylr]]

(Note: one of the folks I emailed passed the message along to the relevant dev team)

Comment 23

[david.kagerer]

Hello Mike,

I'm the Team Lead from the Web Team at ProSiebenSat.1 Digital GmbH. My team and my self are responsible for developing the prosieben.de, sat1.de and other tv channel websites.
Thank you all for the debugging effort and reporting it to us.
We have added the issue to into our system and will start working on it as soon as possible.
I will give you an update when we have fixed the promise polyfill on our side.

Comment 24

[Mike Taylor [:miketaylr]]

Andre, do we have a sense of when we're trying to ship Promise.any? It might be helpful for the ProSieben team to know so they can plan the timing of the fix. I see it's currently Nightly-only... Are we trying to ship to Release in 75? 76? Do we know?

Comment 25

[Mike Taylor [:miketaylr]]

(maybe that's a better question for Jason ^__^)

Comment 26

[Martin Matzanke]

Hey guys!

thanks for the investigation. The problem was in one of our dependencies where they polyfilled Promise.any int the described wrong way which we fixed now from our side. We are testing the next release of the player on our side and it will be available soon. We plan to release it latest beginning of next week.

Thanks again for letting us know about the problem!
Martin

Comment 27

[Mike Taylor [:miketaylr]]

We plan to release it latest beginning of next week.

Awesome, thanks!

Comment 28

[Mike Taylor [:miketaylr]]

Martin -- quick question. The dependency that had the bug, was this an internal script, or is it publicly available elsewhere? If so, it would be good for us to get in touch with them as well.

Comment 29

[Martin Matzanke]

https://www.npmjs.com/package/bitmovin-player That's dependency which had this bug in version <8.27.0. They are probably build in a lot of sites. Dunno if they give the customers they have to you, but you should try it via mail there + we have a meeting with them beginning next week and will tell them that they should inform their customers.

Comment 30

[Mike Taylor [:miketaylr]]

Excellent, thanks. We can try to do some research to see how widespread it is on the web.

Comment 31

[Jason Orendorff [:jorendorff]]

Mike, do you want to take this bug to another component? It looks unactionable from our end and I was going to mark it RESOLVED INVALID.

Comment 32

[Mike Taylor [:miketaylr]]

Yeah, let's move it to webcompat -- it sounds like the site is going to fix it on their end from Comment #29.

Comment 33

[Sören Hentzschel]

The issue seems to be fixed, the videos on prosieben.at are working again.

Comment 34

[Mike Taylor [:miketaylr]]

Great, let's close it -- thanks for checking (and thanks to the Prosieben engineers for fixing so quickly).