1359108 - Widevine plugin crashes if the user profile on located on a remote drive

Status: ASSIGNED

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

Description

[Sbmk]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0
Build ID: 20170418123315

Steps to reproduce:

Hi,

We have been using the 39.0 ESR 32b (Windows 7 64 Pro) version without any flaw for a long time, but a recent update to 52.1.0 ESR 32b lead us into troubles : the Widevine plugin crashes when using Spotify Web Player for an example.

So I tried to investigate further, and discovered that it works without any problem as long as the Firefox profile is located on the hard drive.

But we are intensively using roaming profiles and folder redirection, so our user's profiles are located on a network share. And that was working perfectly before the last update.

I have also tried several sandbox security levels (0,1,2,3) without any success.

Is there a bug a an expected behaviour ?

Regards


Actual results:

https://crash-stats.mozilla.com/report/index/553066b1-6c17-4dca-a2c0-920130170424

Comment 1

[Marcia Knous [:marcia]]

Adding signature and moving to the correct component.

Comment 2

[Nicholas Nethercote [inactive]]

This crash signature is the #4 Windows topcrash in Nightly 20170519030205, although it's a relatively small number of users experiencing the crash many times.

Bug 1346620 and bug 1330930 have the same crash signature; I don't know if they have distinct root causes.

Comment 3

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

This is caused by the sandbox.

Chrome now puts their CDM in the Program Files directory. Potentially we could rewrite our GMP downloader to run as part of the Firefox update and run with admin privileges so we can write there too.

Comment 4

[Bob Owen (:bobowen)]

(In reply to Chris Pearce (:cpearce) from comment #3)
> This is caused by the sandbox.
> 
> Chrome now puts their CDM in the Program Files directory. Potentially we
> could rewrite our GMP downloader to run as part of the Firefox update and
> run with admin privileges so we can write there too.

Using a network drive by itself shouldn't cause us to block it.
I suspect that the roaming profile and folder redirection must involve symlinks or junction points and it will be that which is causing the sandbox to reject the rule.

So, hopefully once we fix that it will fix this as well.

All that being said, as I've mentioned before, I'm not convinced the profile is the best place for the CDM anyway.
ProgramData is another possible option.

Comment 5

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

Easy way to repro: The ProgramData folder in Windows XP was in "C:\Users\All Users" but in Vista and later it's in c:\ProgramData, and the OS redirects "C:\Users\All Users" to c:\ProgramData. So if you create your firefox profile in "C:\Users\All Users" you'll have a path with something like a symlink/junction and that causes the sandbox to block CDM loading.

Comment 6

[Bob Owen (:bobowen)]

(In reply to Bob Owen (:bobowen) from comment #4)
...
> Using a network drive by itself shouldn't cause us to block it.

Looks like I was wrong about this and it has regressed at some point.
Now cpearce has fixed the symlinks/junction point issue, I'll use this bug to look into the network drive issue.

Comment 7

[Bob Owen (:bobowen)]

It looks like this is our old friend the side-by-side assembly manifest.
This rang a bell and from looking back through IRC it seems I came to this conclusion before.

The openh264 CDM, which doesn't have one, works fine.

You can't remove it on the 32-bit widevine DLL without completely breaking it, but removing it for the 64-bit one works.
This includes if I creates a profile on a symlink to a network drive, with cpearce's patch from bug 1346620.

cpearce - I thought we'd asked for the manifest to be removed?

I notice that the latest CDM, which is now in Chrome's Program Files dir doesn't have one.

Comment 8

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

Thanks Bob. I have coincidentally just received a new version of the Widevine CDM to deploy, and the Win32 DLL doesn't have a manifest. So we should have this variant fixed in the next CDM update.

Comment 9

[starbrk]

Hi, I moved my profile to a symlinked folder (standard_location -> c:\firefox) and now I experience same crash on Spotify web player. Firefox 54.0.1 64bit Windows 10

Comment 10

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

This is an assigned P1 bug without activity in two weeks. 

If you intend to continue working on this bug for the current release/iteration/sprint, remove the 'stale-bug' keyword.

Otherwise we'll reset the priority of the bug back to '--' on Monday, August 28th.

Comment 11

[Bulk Bug Changes for mreavy's org]

Mass change P1->P2 to align with new Mozilla triage process

Comment 12

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 desktop browser crashes on nightly

:bobowen, could you consider increasing the severity of this top-crash bug?

For more information, please visit auto_nag documentation.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.

For more information, please visit auto_nag documentation.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

The bug is linked to a topcrash signature, which matches the following criterion:

• Top 10 desktop browser crashes on nightly

:bobowen, could you consider increasing the severity of this top-crash bug?

For more information, please visit auto_nag documentation.

Comment 16

[Andrew Osmond [:aosmond] (he/him)]

I'll take a look.

Comment 17

[Andrew Osmond [:aosmond] (he/him)]

I did a bunch of combinations and was unable to reproduce. Profile/install path with symlinks and/or on network drives. It all seems to work. I did put up a patch to fix the somewhat related issue in bug 1763978.

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.

For more information, please visit auto_nag documentation.