User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36

Steps to reproduce:

This only applies to Windows 10 Anniversary Update or later (i.e. a Windows version where the "PreferSystem32Images" mitigation policy has an affect).

1. Install Firefox release or nightly.
2. Install Skype for Business from the Windows Store.
3. Run Firefox. Go to the address bar, paste https://www.dropbox.com/s/aptwoke9ntvwddm/test.ocsmeet?dl=0 and press enter. Alternatively, visit this bug page and download the attached test.ocsmeet file.
4. On the web page, click Download > Direct download
5. Firefox will display a window asking you whether to open or save the file. Select "Open with" and ensure "Skype for Business" is selected in the combo box. Then click OK.
6. On the "

Actual results:

I am shown the message box:

lync.exe - Entry Point Not Found
The procedure entry point InitializeCriticalSection could not be located in the dynamic link library C:\Program Files (x86)\Microsoft Office\root\Office16\RtmMvrAs.dll.
OK

Expected results:

Skype for Business starts. Note that the test.ocsmeet file is not valid - but you should at least be asked to sign in.

Change the status for beta to have the same as nightly and release.
For more information, please visit auto_nag documentation.

Hi,

I've tested the issue in Windows 10 using following FF versions: release 70.0, beta 71.0b3, Nightly 72.0a1 (2019-10-21). Also I've checked in release 69.0 build.
Results: Only on release 70.0 the issue cannot be reproduced => on all others builds the issue will occur.
Afterwards, I've run a mozregression ensuring that isn't a regression.
Further, I will add a component, if isn't the proper one please fell free to change it.

Thanks.

Bugbug thinks this bug is a regression, but please revert this change in case of error.

I can also replicate this bug with release 68.2.0esr 64bit.
This is especially a problem for enterprise ESR users who got the automatic update from ESR 60 to ESR 68 recently.

I'm aware of quite similiar bug 1567614, which got fixed in 68.0.2esr.
Last time, it was procedure entry point in RtmMvrSplitter.dll, this time it is RtmMvrAs.dll.
From the users perspective, these two bugs look quite the same.

Aaron, I suspect you're best placed to look into this - is this a concrete consequence of the same problem identified in bug 1573469, ie do we need to make the changes referenced in https://bugzilla.mozilla.org/show_bug.cgi?id=1573469#c16 here?

If that's the code path that is happening, then yes.

(FWIW I have moved to the GeckoView team)

I confirmed the repro on Nightly + Windows 10 1903. I also verified replacing ShellExecuteExW in nsLocalFile::Launch with ShellExecuteByExplorer fixed the issue. I'll look into more scenarios and submit a patch if all look good.

The priority flag is not set for this bug.
:Gijs, could you have a look please?

For more information, please visit auto_nag documentation.

[Tracking Requested - why for this release]:
Given the number of dupes for bug 1567614 I think we should try to address this before 71 ships.

[Tracking Requested - why for this release]:
I would really appreciate, if it would be fixed for ESR 68, also.

The launcher process turns on the PreferSystem32Images mitigation policy for
the browser process. Since the mitigation policy is inherited, a process launched
by the browser process also has PreferSystem32Images. If an application which
does not support PreferSystem32Images, such as Skype for Business, is launched
via a hyperlink, a custom uri, or a downloaded file, it would fail to launch.

Bug 1567614 fixed this issue by introducing mozilla::ShellExecuteByExplorer to
nsMIMEInfoWin::LoadUriInternal. This patch introduces
mozilla::ShellExecuteByExplorer to two more places.

1. xul!nsLocalFile::Launch
   This is invoked when a user opens a file from the Download Library, or a user
   opens a downloaded file with the default application without saving it.

2. xul!nsMIMEInfoWin::LaunchWithFile
   This is invoked when a user opens a downloaded file with a custom application
   (configured in about:preference) without saving it.

Why does this patch change worker.js?

The mochitest dom/tests/browser/browser_test_new_window_from_content.js failed
if it was executed after dom/serviceworkers/test/browser_download.js in the
same batch. This was because browser_download.js launched Notepad to open
fake_download.bin.txt, preventing a new window from being opened in the
foreground in browser_test_new_window_from_content.js.

The test browser_download.js can verify downloaded data without opening an
associated application. So this patch adds the content-type to the response
header in order not to open Notepad on Windows.

https://hg.mozilla.org/mozilla-central/rev/abcbfdf1a1ef

Can we uplift this to 71 and ESR?

Verified - fixed on latest Nightly 72.0a1 (Build id: 20191115095319) using Windows 10.

(In reply to Mike Kaply [:mkaply] from comment #15)

Can we uplift this to 71 and ESR?

+ni

FWIW, there's also reports in bug 1567614 that the fix in 70 for protocol handling is incomplete.

Comment on attachment 9107891 [details]
Bug 1588975 - Replace ShellExecuteExW with mozilla::ShellExecuteByExplorer. r=aklotz

Beta/Release Uplift Approval Request

• User impact if declined: Some applications which do not support PreferSystem32Images policy, such as Skype for Business, fail to start from Firefox via a downloaded file or Download Library.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch replaces ShellExecuteExW with IShellDispatch2.ShellExecute to launch an application via Windows shell. This approach is the same as we did in Bug 1567614 before. We apply this approach to a couple of scenarios we missed.
• String changes made/needed: None

D52567 will not fit ESR68. I'll upload another patch.

The launcher process turns on the PreferSystem32Images mitigation policy for
the browser process. Since the mitigation policy is inherited, a process launched
by the browser process also has PreferSystem32Images. If an application which
does not support PreferSystem32Images, such as Skype for Business, is launched
via a hyperlink, a custom uri, or a downloaded file, it would fail to launch.

Bug 1567614 fixed this issue by introducing mozilla::ShellExecuteByExplorer to
nsMIMEInfoWin::LoadUriInternal. This patch introduces
mozilla::ShellExecuteByExplorer to two more places.

1. xul!nsLocalFile::Launch
   This is invoked when a user opens a file from the Download Library, or a user
   opens a downloaded file with the default application without saving it.

2. xul!nsMIMEInfoWin::LaunchWithFile
   This is invoked when a user opens a downloaded file with a custom application
   (configured in about:preference) without saving it.

Why does this patch change worker.js?

The mochitest dom/tests/browser/browser_test_new_window_from_content.js failed
if it was executed after dom/serviceworkers/test/browser_download.js in the
same batch. This was because browser_download.js launched Notepad to open
fake_download.bin.txt, preventing a new window from being opened in the
foreground in browser_test_new_window_from_content.js.

The test browser_download.js can verify downloaded data without opening an
associated application. So this patch adds the content-type to the response
header in order not to open Notepad on Windows.

Comment on attachment 9109162 [details]
Bug 1588975 - Replace ShellExecuteExW with mozilla::ShellExecuteByExplorer. r=aklotz

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: With this issue, Skype for Business cannot launch from Firefox via a downloaded .ocsmeet (Lync meeting) file. This should be a common scenario for Skype for Business users. Moreover, this issue blocks not only Skype for Business but also any applications which do not support PreferSystem32Images policy.
• User impact if declined: Applications which do not support PreferSystem32Images policy fail to start from Firefox via a downloaded file or Download Library. The error popup is displayed instead.
• Fix Landed on Version: 72.0a1
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): This patch replaces ShellExecuteExW with IShellDispatch2.ShellExecute to launch an application via Windows shell. This approach is the same as we did in Bug 1567614 before. We apply this approach to a couple of scenarios we missed.
• String or UUID changes made by this patch: None

Comment on attachment 9107891 [details]
Bug 1588975 - Replace ShellExecuteExW with mozilla::ShellExecuteByExplorer. r=aklotz

P1 and fix verified by QA on nightly, uplift approved for 71 beta 11, thanks.

https://hg.mozilla.org/releases/mozilla-beta/rev/61750ab393d0

Verified - fixed on latest Beta 71.0b11 (Build id: 20191118154140) using Windows 10.

Comment on attachment 9109162 [details]
Bug 1588975 - Replace ShellExecuteExW with mozilla::ShellExecuteByExplorer. r=aklotz

Fixes a regression causing Skype for Business to be unable to launch when invoked via Firefox. Approved for 68.3esr.

https://hg.mozilla.org/releases/mozilla-esr68/rev/1cc2971e671a

Verified - fixed on latest ESR 68.3.0esr (Build id: 20191120025450) using Windows 10.

FYI, we have another regression mentioned on the list that appears related to this:

https://mail.mozilla.org/pipermail/enterprise/2019-December/002052.html

I'm having them open a bug.

(In reply to Mike Kaply [:mkaply] from comment #28)

FYI, we have another regression mentioned on the list that appears related to this:

https://mail.mozilla.org/pipermail/enterprise/2019-December/002052.html

I'm having them open a bug.

Since the default verb of .dotm is New, I guess the startup macro is a AutoNew macro and this is a dupe of bug 1597963 that will be fixed in 72/68.4.0esr.