1346620 - Netflix has never worked on Firefox: "The WidevineCdm plugin has crashed."

Status: VERIFIED FIXED

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

Description

[Nicholas Solin]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20170125094131

Steps to reproduce:

1. Log into Netflix.
2. Open a Netflix video.
3. Video will not load.




Actual results:

It displays this message:

"The WideviewCdm plugin has crashed. Learn more..."

The "Learn more..." link goes here:

https://support.mozilla.org/t5/Troubleshooting/Plugin-crash-reports/ta-p/17952

There are two buttons, "Reload Page" and "Submit Crash Report". Reloading the page does not fix the video. "Submit Crash Report" seems to do nothing.


Expected results:

It should have loaded the Netflix video.

Comment 1

[Nicholas Solin]

I typed the error message wrong. It is in fact:

"The WidevineCdm plugin has crashed. Learn more..."

Comment 2

[Nicholas Solin]

Attachment: 7133cab6-6a53-4ce0-a27a-88150500a9a7.dmp

Comment 3

[Nicholas Solin]

Attachment: 7133cab6-6a53-4ce0-a27a-88150500a9a7.extra

Comment 4

[YF (Yang)]

Please post the crash id (bp-) from about:crashes. Before copying, click on it to make sure it is submitted (as bp-).
https://developer.mozilla.org/en/How_to_get_a_stacktrace_for_a_bug_report

Comment 5

[Nicholas Solin]

I've got four submitted crashes in %APPDATA%\Mozilla\Firefox\Crash Reports\submitted:

Crash ID: bp-bf4be7c0-8d74-429f-bfb0-067db2170312
Crash ID: bp-81f6b8d7-0f70-4356-85cf-bc6a22170312
Crash ID: bp-3d6c0021-d4eb-4481-a868-8da092170312
Crash ID: bp-7c5b8a4e-3f8c-40c5-9056-22fb52170312

I can't even find the dmp file I uploaded in the pending directory so I'll probably just delete it.

Comment 6

[YF (Yang)]

(In reply to Nicholas Solin from comment #5)
> I've got four submitted crashes in %APPDATA%\Mozilla\Firefox\Crash
> Reports\submitted:
> 
> Crash ID: bp-bf4be7c0-8d74-429f-bfb0-067db2170312
> Crash ID: bp-81f6b8d7-0f70-4356-85cf-bc6a22170312
> Crash ID: bp-3d6c0021-d4eb-4481-a868-8da092170312
> Crash ID: bp-7c5b8a4e-3f8c-40c5-9056-22fb52170312
> 
> I can't even find the dmp file I uploaded in the pending directory so I'll
> probably just delete it.

The submitted dmp files will be automatically deleted.

Comment 7

[rishel.nick]

I've had the same problem several versions back.
Firefox x64, Windows 10, originally a Firefox x86 profile.

Crash ID: bp-a2e6bb14-f11b-4c9d-a7ee-0aa722170313

Comment 8

[rishel.nick]

(In reply to rishel.nick from comment #7)
> I've had the same problem several versions back.
> Firefox x64, Windows 10, originally a Firefox x86 profile.
> 
> Crash ID: bp-a2e6bb14-f11b-4c9d-a7ee-0aa722170313

Quick clarification, I've had the same problem several versions back into the current version of Firefox (52.0 x64).

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

gerald/cpearce - while this may subsume other bugs, you should follow the signature link.

Also: this may be a dup (just a guess)

Comment 10

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

rishel.nick, Nicholas Solin: Can you test something for us in order to help us fix this problem? Could you try setting the environment variable MOZ_DISABLE_GMP_SANDBOX to "1", restart Firefox, and see if you still get the same problem?

To set environment variables, open the Windows 10 Start menu, search for "Edit the system environment variables", and on the "Advanced" tab of the "System Properties" window that pops up click "Environment variables". Under "User variables for ..." click "New". Enter "Variable name" as MOZ_DISABLE_GMP_SANDBOX, with "Variable value" as "1" (without the quotes).

Often these failures are caused by a security feature called the "sandbox", and setting this environment variable turns off the sandbox. If setting this environment variable doesn't help, I recommend you remove the new environment variable.

Thanks!

Comment 11

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

From the uploaded crash report I can see that the GMPChild::ProcessingError has aReason = "(msgtype=0x76000C,name=PGMP::Msg_StartPlugin) Processing error: message was deserialized, but the handler returned false (indicating failure)"

In the past these have usually been caused by the sandbox blocking the load.

rishel.nick, Nicholas Solin: are you running any anti-virus or other security software? Are you on an enterprise version of Windows, or a machine managed by someone else?

Comment 12

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

Bob Owen: Any ideas as to how we can find out more information as to whether/why the sandbox could be blocking the Widevine CDM loading here?

Comment 13

[Bob Owen (:bobowen)]

We should be able to use logging settings similar to those in bug 1273372 comment 33, to see what the sandbox is blocking.

Nicholas - if you could update to the latest version of Firefox (52) and this time run with the following environment variables set before you start Firefox:

NSPR_LOG_MODULES="SandboxBroker:5,SandboxTarget:5,sync"
NSPR_LOG_FILE="%TEMP%\bug1346620sb.txt"
MOZ_WIN_SANDBOX_LOGGING=1

It should create that log file and ones like this: bug1346620sb.txt.child-* in the temp directory.

Please would you attach bug1346620sb.txt to the bug (if it is not empty).
Please also attach any of the child ones that mention the loading of widevinecdm.dll

You should remove those environment variables when you are finished, thanks.

Comment 14

[rishel.nick]

(In reply to Chris Pearce (:cpearce) from comment #10)
> rishel.nick, Nicholas Solin: Can you test something for us in order to help
> us fix this problem? Could you try setting the environment variable
> MOZ_DISABLE_GMP_SANDBOX to "1", restart Firefox, and see if you still get
> the same problem?

This "fixed" the issue.

(In reply to Chris Pearce (:cpearce) from comment #11)
> rishel.nick, Nicholas Solin: are you running any anti-virus or other
> security software? Are you on an enterprise version of Windows, or a machine
> managed by someone else?

Only running Windows Defender, on a self-managed Windows 10 Pro desktop. In case it's relevant I use symlinks to store my profile off of the C: drive.

(In reply to Bob Owen (:bobowen) from comment #13)
> Nicholas - if you could update to the latest version of Firefox (52) and
> this time run with the following environment variables set before you start
> Firefox:
> 
> NSPR_LOG_MODULES="SandboxBroker:5,SandboxTarget:5,sync"
> NSPR_LOG_FILE="%TEMP%\bug1346620sb.txt"
> MOZ_WIN_SANDBOX_LOGGING=1
> 
> It should create that log file and ones like this: bug1346620sb.txt.child-*
> in the temp directory.

I removed the MOZ_DISABLE_GMP_SANDBOX and added the above environment variables sans quotes/equal sign and couldn't find bug1346620sb.txt in the %TEMP% directory. When you said the latest version of Firefox, did you mean 52 nightly or stable 52.0.1? Crash report when I tried to produce the log file - https://crash-stats.mozilla.com/report/index/7ad02ccc-a2d6-4bc4-a7c0-9d5582170322

Comment 15

[Bob Owen (:bobowen)]

(In reply to rishel.nick from comment #14)
> (In reply to Chris Pearce (:cpearce) from comment #10)

> Only running Windows Defender, on a self-managed Windows 10 Pro desktop. In
> case it's relevant I use symlinks to store my profile off of the C: drive.

It's almost certainly the symlinks that are causing the problem.
We have to add a rule to the sandbox to allow the DLL to load, but those rules don't support symlinks or junction points.
We resolve the special case of people creating a junction point for their Users directory to another location.

I'm guessing that you have done something a little different to that.
 
> (In reply to Bob Owen (:bobowen) from comment #13)
> > Nicholas - if you could update to the latest version of Firefox (52) and
> > this time run with the following environment variables set before you start
> > Firefox:
> > 
> > NSPR_LOG_MODULES="SandboxBroker:5,SandboxTarget:5,sync"
> > NSPR_LOG_FILE="%TEMP%\bug1346620sb.txt"
> > MOZ_WIN_SANDBOX_LOGGING=1
> > 
> > It should create that log file and ones like this: bug1346620sb.txt.child-*
> > in the temp directory.
> 
> I removed the MOZ_DISABLE_GMP_SANDBOX and added the above environment
> variables sans quotes/equal sign and couldn't find bug1346620sb.txt in the
> %TEMP% directory. When you said the latest version of Firefox, did you mean
> 52 nightly or stable 52.0.1? 

I meant the latest release/stable version. The latest version of Nightly is 55.

I tend to use those settings from a different shell, I'd forgotten it's slightly different from the command prompt, where you don't specify the quotes. From a windows command line this works for me (assuming c: as the system drive and 32-bit firefox):

  set NSPR_LOG_MODULES=SandboxBroker:5,SandboxTarget:5,sync
  set NSPR_LOG_FILE=%TEMP%\bug1346620sb.txt
  set MOZ_WIN_SANDBOX_LOGGING=1
  "c:\Program Files (x86)\Mozilla Firefox\firefox.exe" -no-remote -P

The "-no-remote -P" opens the profile manager so you can create a separate one for testing and also allows you to run more than one instance.

If it is your windows profile that contains symlinks it's possible that the logging from the child won't work, but the log from the parent process (bug1346620sb.txt) should contain an error for attempting to add an invalid rule for the sandbox.

Comment 16

[Nicholas Nethercote [inactive]]

I see 15 occurrences of this crash signature in Linux Nightly 20170331102157, making it the #4 topcrash.

Comment 17

[Nicholas Nethercote [inactive]]

(In reply to Nicholas Nethercote [:njn] from comment #16)
> I see 15 occurrences of this crash signature in Linux Nightly
> 20170331102157, making it the #4 topcrash.

Oh, but they were all from a single installation.

Comment 18

[rishel.nick]

Attachment: Requested error logging file for sandbox + symlink(?) issues.

Comment 19

[rishel.nick]

The symlink is ~\AppData\Roaming\Mozilla\Firefox created via "mklink /d ..." (so a directory symlink and not a directory junctions though I'm uncertain the importance of the distinction).

When creating the new profile, warning at top says "Firefox is installing components needed to play the audio or video of this page. Please try again later.", after refreshing, "The WidevineCdm plugin has crashed." https://crash-stats.mozilla.com/report/index/3667d3de-a09e-4577-8692-55c9a1170423

There were 14 bug1346620sb.txt.child-# files also generated, there doesn't seem to be batch file uploads but I can attach those if useful too.

Comment 20

[rishel.nick]

Just confirmed that the issue does not seem to appear on Linux with an equivalent symlink setup.

Another peculiarity of my setup is that Linux and Windows share the same profile directory for Firefox. I cycled the "Enable DRM Content" as per the instructions here - https://help.netflix.com/en/node/40835 - with no luck.

Comment 21

[Anthony Jones (:ajones, :kentuckyfriedtakahe, :k17e)]

Bob/Chris - what needs to happen to fix this issue?

Comment 22

[Bob Owen (:bobowen)]

(In reply to rishel.nick from comment #18)
> Created attachment 8860762 [details]
> Requested error logging file for sandbox + symlink(?) issues.

Thanks for this, sorry that I missed your comments.

It confirms that the rule added by GMP code is being rejected by the sandbox.
It will be because of the symlink in that path.
No need to add any other logs.

(In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #21)
> Bob/Chris - what needs to happen to fix this issue?

Looks like we need a new version of WinUtils::ResolveMovedUsersFolder to resolve the path completely, symlinks and all junction points. The junction points are more of a pain I think, as you have to test and resolve each directory. As far as I'm aware there isn't a windows API that will do this for you, but maybe I was constrained by still supporting XP/Vista before. For the symlinks I think you can use GetFinalPathNameByHandle to resolve fully.
I guess the best plan will be to resolve symlinks first and then junction points, but I haven't tried anything, so there could be problems with that approach.

I'm going to probably need to do something similar for the content process soon, when I land settings to remove read access, but if someone wants to work on this for GMP for uplift that would be great. :-)

[1] https://hg.mozilla.org/mozilla-central/file/d8762cb96742/widget/windows/WinUtils.cpp#l1838

Comment 23

[Liz Henry (:lizzard) (relman/hg->git project)]

Might this be a duplicate of bug 1359108?

Comment 24

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

(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #23)
> Might this be a duplicate of bug 1359108?

This bug is that the sandbox prohibits loading the CDM if it is stored in a path which contains a symlink on Windows. Whereas bug 1359108 is that the sandbox prohibits loading the CDM if it is stored on a network drive. They're similar, but not the same case.

Comment 25

[Nicholas Solin]

(In reply to Bob Owen (:bobowen) from comment #13)
> Nicholas - if you could update to the latest version of Firefox (52) and
> this time run with the following environment variables set before you start
> Firefox:
> 
> NSPR_LOG_MODULES="SandboxBroker:5,SandboxTarget:5,sync"
> NSPR_LOG_FILE="%TEMP%\bug1346620sb.txt"
> MOZ_WIN_SANDBOX_LOGGING=1
> 
> It should create that log file and ones like this: bug1346620sb.txt.child-*
> in the temp directory.

I tried both MOZ_DISABLE_GMP_SANDBOX=1 and the three environment variables above, but neither was a solution to getting my Netflix to work on Firefox. The set of environment variables did create C:\Windows\Tempbug1346620sb.txt, but the file is completely empty. I do not see any bug1346620sb.txt.child-* files either.

For reference, my link creation command is:

MKLINK /J "C:\Users\Nicholas\AppData\Roaming\Mozilla" "D:\Users\Nicholas\AppData\Roaming\Mozilla

I don't know if this is different from Nicholas N.'s MKLINK syntax, the usage of /D instead of /J, or the fact that I'm symlinking the entire Mozilla folder for Thunderbird and Sunbird (yes, I still use Sunbird).

Comment 26

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

Attachment: Bug 1346620 - Resolve symlinks and junction points in path to GMP dir when loading GMP process.

The sandbox blocks loading of GMPs when the GMP resides in a directory stored
in a path which contains a symlink or junction point. So resolve GMP paths
fully before instantiating the GMP process.

Review commit: https://reviewboard.mozilla.org/r/147060/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/147060/

Comment 27

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

(In reply to Bob Owen (:bobowen) from comment #22)
> (In reply to Anthony Jones (:kentuckyfriedtakahe, :k17e) from comment #21)
> > Bob/Chris - what needs to happen to fix this issue?
> 
> Looks like we need a new version of WinUtils::ResolveMovedUsersFolder to
> resolve the path completely, symlinks and all junction points. 
[...]
> I'm going to probably need to do something similar for the content process
> soon, when I land settings to remove read access, but if someone wants to
> work on this for GMP for uplift that would be great. :-)

I've uploaded a patch that resolves junctions and symlinks, at least on my Win10 machine. I've not tested loading the CDM from a network drive yet. I was considering all the consequences of storing the GMP in ProgramData, and figured it would be quicker to fix the resolving symblinks/junctions issue first. Given that we'll need this change for the content process anyway, and possibly even for some crazy people who move their ProgramData to be behind a junction, I figured we can do this anyway now to get the bug fixed.

Comment 28

[Bob Owen (:bobowen)]

I'm going to have to create a function to resolve these things for bug 1369670.

So GMP could potentially use that, although it looks like bug 1370772 is going to load from under ProgramData anyway.
As I've said I think that is a good plan anyway, but we could also use the function once we've got it, just in case.

(In reply to Nicholas Solin from comment #25)
> (In reply to Bob Owen (:bobowen) from comment #13)
...
> I tried both MOZ_DISABLE_GMP_SANDBOX=1 and the three environment variables
> above, but neither was a solution to getting my Netflix to work on Firefox.
> The set of environment variables did create C:\Windows\Tempbug1346620sb.txt,
> but the file is completely empty. I do not see any bug1346620sb.txt.child-*
> files either.

Sorry, I must have missed your reply.

Looks like your issue isn't the sandbox then, we could really do with getting some logging in that case.
I think the env var setting I gave you was slightly off, if you're running them from a Windows command prompt (I usual do it from bash).
Could you try these instead (this should include GMP logging):

  set NSPR_LOG_MODULES=SandboxBroker:5,SandboxTarget:5,GMP:5,sync
  set NSPR_LOG_FILE=%TEMP%\bug1346620sb.txt
  set MOZ_WIN_SANDBOX_LOGGING=1

Also if you're testing in Firefox version 54 or later then these should be:

  set MOZ_LOG=SandboxBroker:5,SandboxTarget:5,GMP:5,sync
  set MOZ_LOG_FILE=%TEMP%\bug1346620sb.txt
  set MOZ_SANDBOX_LOGGING=1

Comment 29

[Bob Owen (:bobowen)]

Comment on attachment 8875637 [details]
Bug 1346620 - Resolve symlinks and junction points in path to GMP dir when loading GMP process.

https://reviewboard.mozilla.org/r/147060/#review151210

::: widget/windows/WinUtils.h:467
(Diff revision 1)
>    */
>    static uint32_t GetMaxTouchPoints();
>  
>    /**
> -   * Detect if path is within the Users folder and Users is actually a junction
> -   * point to another folder.
> +   * Fully resolves a path to its final path name. So if path contains
> +   * junction points or symlinks to another folders, we'll resolve the path

s/another/other/

::: widget/windows/WinUtils.cpp:1923
(Diff revision 1)
> +
> +  if (handle == INVALID_HANDLE_VALUE) {
> +    return false;
> +  }
> +
> +  DWORD pathLen = GetFinalPathNameByHandle(

nit: we should explicitly use GetFinalPathNameByHandleW I think.

::: widget/windows/WinUtils.cpp:1932
(Diff revision 1)
> +  }
> +  aPath = path;
> +
> +  // GetFinalPathNameByHandle sticks a "\\?\" in front of the path,
> +  // but that confuses some APIs so strip it off.
> +  auto i = aPath.find_first_not_of(L"\\\\?\\", 0);

This is a character search.
As it happens because the next character should be a drive letter then it should work (although you could just have L"\\\\?").
Maybe just use compare and erase so we don't create a new string:

if (aPath.compare(0, 4, L"\\\\\\\\?\\\\") == 0) \{
  aPath.erase(0, 4);
\}

Anyway, scratch all that, with the discovery over GetFinalPathNameByHandle (below) we should just convert the second \\ to a ? (so \\??\\ not \\\\?\\) this gives us the NT naming convention which is what the sandbox wants.
This will work for symlinks to network drives as well and we can remove that code that currently checks for this after the call to ResolveMovedUsersFolder.

Not sure if the library loading will work with the NT path though, so we might have to trim it off before passing it down to the child.

In that case, for the network drive case we would have to convert:
\\??\\UNC\\SERVER\\Share\\path
to
\\\\SERVER\\Share\\path

I guess we could get this code to do that and return two paths.

::: widget/windows/WinUtils.cpp:1965
(Diff revision 1)
> +  for (auto token : tokens) {
> +    p += token;
> +    p += L"\\";

I think we'd have to go backwards to get this to work and we'd lose the start of the path, but I noticed that this function wasn't modifying aPath anyway.
So, I tried GetFinalPathNameByHandle and it resolves junction points as well, so this is much easier than I thought.
We can just rename ResolveSymbolicLinks to ResolveJunctionPointsAndSymLinks

It wasn't available on WinXP, which must be why I didn't use it before.

Comment 30

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

Comment on attachment 8875637 [details]
Bug 1346620 - Resolve symlinks and junction points in path to GMP dir when loading GMP process.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/147060/diff/1-2/

Comment 31

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

I've updated the patch, but it doesn't work for network shares, even though the paths have the '\??\'. I'm not sure how to make the network shares work. It works fine with junction points and sym links.

Comment 32

[Bob Owen (:bobowen)]

Comment on attachment 8875637 [details]
Bug 1346620 - Resolve symlinks and junction points in path to GMP dir when loading GMP process.

https://reviewboard.mozilla.org/r/147060/#review151688

Given that network drives don't seem to be working now, I'll look into that in a follow-up.

::: dom/media/gmp/GMPProcessParent.cpp:57
(Diff revision 2)
>    // symbolic links or junction points. Sometimes the Users folder has been
>    // moved to another drive using a junction point, so allow for this specific
>    // case. See bug 1236680 for details.
> -  if (!widget::WinUtils::ResolveMovedUsersFolder(wGMPPath)) {
> -    NS_WARNING("ResolveMovedUsersFolder failed for GMP path.");
> +  if (!widget::WinUtils::ResolveJunctionPointsAndSymLinks(wGMPPath)) {
> +    GMP_LOG("ResolveJunctionPointsAndSymLinks failed for GMP path=%s",
> +            WideToUTF8(wGMPPath).c_str());

nit: Can we use %S  (uppercase) for the logging and not convert the string?

Comment 33

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

Comment on attachment 8875637 [details]
Bug 1346620 - Resolve symlinks and junction points in path to GMP dir when loading GMP process.

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/147060/diff/2-3/

Comment 34

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/552aa9d9f4f9
Resolve symlinks and junction points in path to GMP dir when loading GMP process. r=bobowen

Comment 35

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/552aa9d9f4f9

Comment 36

[Ryan VanderMeulen [:RyanVM]]

Not sure if this is worth considering for an Fx54 dot release ride-along candidate, but it'd probably be worth uplifting to ESR52 at least?

Comment 37

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

I feel like this should bake this a bit before we uplift it. Yes, uplifting to 52 ESR seems reasonable, after a bit of baking.

Comment 38

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

Nicholas Solin: would you be able to test our to see whether our fix works for you? The fix is in Firefox Nightly builds, which you can download from https://www.mozilla.org/en-US/firefox/channel/desktop/ . You will need to close other running Firefox instances before running the Nightly build. Thanks!

Comment 39

[rishel.nick]

Fix works on my end.

Comment 40

[Gerry Chang [:gchang]]

As 54 was released, we won't take this in 54 if we have 54 dot release.

Comment 41

[Ryan VanderMeulen [:RyanVM]]

Think we're ready to request ESR52 approval on this?

Comment 42

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

Comment on attachment 8875637 [details]
Bug 1346620 - Resolve symlinks and junction points in path to GMP dir when loading GMP process.

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration:
User impact if declined: Without this patch, some Windows users who have stored their Firefox profile in a non-standard location, inside a folder behind a symlink or "junction" point, will not be able to start the CDM process. This means that sites trying to play DRM protected video like Netflix won't work for these people. We still get a significant number of these failures on ESR52, so I think this will help.
Fix Landed on Version: 55
Risk to taking this patch (and alternatives if risky): This patch should be low risk; it's baked in Nightly and Beta for a few weeks now.
String or UUID changes made by this patch: None.

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Comment 43

[Gerry Chang [:gchang]]

Hi :cpearce,
May I know have you verified this in local ESR52 or can you help create a try build based on ESR52 and we can have QE to help verify this issue?

Comment 44

[Nicholas Solin]

(In reply to Chris Pearce (:cpearce) from comment #38)
> Nicholas Solin: would you be able to test our to see whether our fix works
> for you? The fix is in Firefox Nightly builds, which you can download from
> https://www.mozilla.org/en-US/firefox/channel/desktop/ . You will need to
> close other running Firefox instances before running the Nightly build.
> Thanks!

Don't worry, I use "-P encrypted -no-remote" so that I can have my encrypted profile open at the same time as my general browsing profile.

And... it works!!! Thank you very much for your work and thank you everyone for your contributions to this bug report.

Comment 45

[Gerry Chang [:gchang]]

Comment on attachment 8875637 [details]
Bug 1346620 - Resolve symlinks and junction points in path to GMP dir when loading GMP process.

Given we still have lots of users on ESR52, let's uplift it to ESR52.3.

Comment 46

[Ryan VanderMeulen [:RyanVM]]

This needs a rebased patch for ESR52.

Comment 47

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

For the record, this was landed on esr25:
https://hg.mozilla.org/releases/mozilla-esr52/rev/688c9284fb12

And then backed out:
https://hg.mozilla.org/releases/mozilla-esr52/rev/8e0ad123ef5e

The build failed on because this patch adds the use of the GetFinalPathNameByHandle() API, and that is only available on Windows Vista and later, and ESR52 is built with Windows XP code gen. So I'll need to rewrite the patch to load GetFinalPathNameByHandle from kernel32.dll manually, and preserve the existing fallback path on XP.

Comment 48

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

(In reply to Chris Pearce (:cpearce) from comment #47)
> The build failed on because this patch adds the use of the
> GetFinalPathNameByHandle() API, and that is only available on Windows Vista
> and later, and ESR52 is built with Windows XP code gen. So I'll need to
> rewrite the patch to load GetFinalPathNameByHandle from kernel32.dll
> manually, and preserve the existing fallback path on XP.

The (existing) fallback path isn't run on XP anyway, so we don't need to preserve the previous code path for XP anyway.

Comment 49

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

Here's a try push of the patch rebased on ESR52:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=db6f3c2e8492b6309cb3207fd0ddf71849955e5d&selectedJob=119786938

I have tested this build locally and verified that it fixes the bug in ESR; the CDM works as expected if the Firefox profile is inside a path which contains a Windows junction point, and in the current ESR52 build which doesn't have this fix the CDM crashes.

Comment 50

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

Attachment: ESR52 Rebase - Reland 6f93b270d1e3

MozReview-Commit-ID: CLdzAzsAUVP

Comment 51

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

Patch rebased, required minor edits to make the code build with WinXP compatibility.

Comment 52

[Gerry Chang [:gchang]]

Hi Florin, can we have some QA's help to verify this on ESR52.3 once the build is ready?

Comment 53

[[SV Manager] Florin Mezei, QA (:FlorinMezei)]

Moving over to Andrei so they have this in their verification list.

Comment 54

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr52/rev/d71000abc9bf

Comment 55

[Iulia Cristescu, QA [:JuliaC] (away, please needinfo? [e-mail])]

Managed to reproduce the initial issue on 55.0a1 (2017-03-12). I can confirm the bug is verified fixed on 55.0 build3 (20170803103124) and on 52.3.0esr (20170802111520) using Windows10 x64, Ubuntu 16.04 x64 and Mac OS X 10.11.6.