Closed Bug 1602726 Opened 1 year ago Closed 11 months ago

Firefox 71 und Firefox 68.3.0esr do not open File-Links e.g. PDF, DOCX, XLSX ... in a Windows Server 2012R2/Citrix Environment as a normal User

Categories

(Firefox :: File Handling, defect, P1)

68 Branch
defect

Tracking

()

RESOLVED FIXED
Firefox 74
Tracking Status
firefox-esr68 72+ fixed
firefox71 + wontfix
firefox72 --- wontfix
firefox73 + verified
firefox74 + verified

People

(Reporter: Peter.Geier, Assigned: toshi)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [enterprise])

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

After Update Firefox ESR 68.2.0 to 68.3.0 running on Windows Server 2012R2/Citrix Envorinment as a normal User we can´t open HTML File-Links.

Actual results:

A Click to MS Word 2016 HTML-Link open a Dialog Window to start with Standard Program but Winword ist not starting.
Same for Excel, Powerpoint, Adobe Reader and so on.

Expected results:

Start the correct Program via MimeType.

As an Admin via RDP-Session there is no Problem. It Works fine.

Component: Untriaged → File Handling

Same Problem with Windows Server 2008 R2 and Published Citrix Apps

Toshi, is it likely this is the same issue as bug 1601905? It looks similar and I can't think of any other changes we landed on ESR to do with file opening...

Flags: needinfo?(tkikuchi)

[Tracking Requested - why for this release]:
Regression in 68, we may need a point release for this. Toshi is diagnosing.

Blocks: 1588975
Status: UNCONFIRMED → NEW
Ever confirmed: true

Would this also affect users on 71 release?

(In reply to :Gijs (he/him) from comment #2)

Toshi, is it likely this is the same issue as bug 1601905? It looks similar and I can't think of any other changes we landed on ESR to do with file opening...

I agree this is a regression from Bug 1588975. If so, yes, this affects 71 release. I'm not sure this is the same as Bug 1601905. Probably a different issue.

Since we don't have Citrix Environment, I'm now preparing ESR68 build without my patch. Peter and Roger, once it's ready, is it possible to install it and see the issue is solved or not?

Flags: needinfo?(tkikuchi)
Flags: needinfo?(roger.thomas)
Flags: needinfo?(Peter.Geier)

Here's the latest mozilla-esr68 without Bug 1588975. Could you try this and see the issue still happens or not?
https://treeherder.mozilla.org/#/jobs?repo=try&revision=ece685b93dee95e7d8a5f785df950c2b9de5fb04&selectedJob=280956418

Full x64 binaries:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/bvey-1BBSTKpsKYe7GWCwA/runs/0/artifacts/public/build/target.zip

Installer of x64:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/bvey-1BBSTKpsKYe7GWCwA/runs/0/artifacts/public/build/install/sea/target.installer.exe

My hypothesis right now is firefox.exe virtualized by Citrix fails to communicate with explorer.exe. A fix would be to fall back to the original ShellExecute if that communication fails.

I have used your installer x64 Version.
Problem is now fixed :-))
Works fine.
Thank you for yor fast response.
Today is my last day in office in 2019.
I will be back on third January.
If you have further questions, please ask to Thomas Roger.

Peter Geier / Munich

Flags: needinfo?(Peter.Geier)

My tests with the x64 installer were also successful.

Flags: needinfo?(roger.thomas)

Just to inform you:

Maybe my problem is also related to this bug?

We use these preferences to start Word-templates from Firefox-Browser.

capability.policy.policynames = LocalFileLinks
capability.policy.LocalFileLinks.sites = [several internal websites]
capability.policy.LocalFileLinks.checkloaduri.enabled = allAccess

We use a workaround with pointing first on a LNK-file, which itself pointing on the actual Word-template.
Example:
Word-template is here:
-> Z:\public\msoffice\letter_template.dotm
LNK-file we link to from our internal websites:
-> Z:\public\msoffice\weblinks\letter_template.lnk

The lnk-file just link directly to the .dotm-file.

Some of these Word-templates have startup macros (e.g. an user form for getting input from the user). This worked for years. Since the last FF-update to 68.3.0esr these startup-macros does not work anymore. The template opens and you can start the macros manually, but not automatically - which is very important for the user.

  1. When you right click the .dotm-file and select New from the context menu, does the startup macro run?
  2. When you right click the .dotm-file and select Open from the context menu, does the startup macro run?
Flags: needinfo?(RiemerMalte)
No longer blocks: 1588975
Keywords: regression
Regressed by: 1588975

(In reply to Masatoshi Kimura [:emk] from comment #11)

  1. When you right click the .dotm-file and select New from the context menu, does the startup macro run?
    Yes, we create such templates that macros run via event "Document_new"
  1. When you right click the .dotm-file and select Open from the context menu, does the startup macro run?
    No, we can not use "Document_open" for our templates. But it seems to be that with this event there is no problem.

Malte

Flags: needinfo?(RiemerMalte)

Hi Malte, Thank you reporting an issue. Your issue sounds like Bug 1597963.

ESR68.3.0esr has another regression that a downloaded file is opened with "open" verb instead of the default verb. This means Firefox opens a .dotm file instead of creating a new document based on the .dotm. When this happens, you will see the title bar says "letter_template.dotm - Word" instead of "Document1 - Word". That's why macros are not executed.

Bug 1597963 has been fixed in Nightly and uplifted to ESR. If you can verify the fix on Nightly, that would be great. Sorry for inconvenience. If you issue is not fixed in the latest Nightly, could you please file a new bug?

(In reply to roger.thomas from comment #9)

My tests with the x64 installer were also successful.

Thanks for verifying the bits quickly, Peter and Roger! At least we're 100% sure what is a regressing fix.

Roger, I want to ask you to do one more test on the original ESR. As :Gijs mentioned earlier, there is another regression, Bug 1601905. I want to make sure this issue is not a dup of Bug 1601905.

To verify that, can you save a file first, and then open it from Firefox's download library? If the issue still happens, this is not Bug 1601905. Then I'll start prototyping a fix and probably ask you to verify it.

Flags: needinfo?(roger.thomas)

(In reply to Toshihito Kikuchi [:toshi] from comment #13)

Hi Malte, Thank you reporting an issue. Your issue sounds like Bug 1597963.

ESR68.3.0esr has another regression that a downloaded file is opened with "open" verb instead of the default verb. This means Firefox opens a .dotm file instead of creating a new document based on the .dotm. When this happens, you will see the title bar says "letter_template.dotm - Word" instead of "Document1 - Word". That's why macros are not executed.

Bug 1597963 has been fixed in Nightly and uplifted to ESR. If you can verify the fix on Nightly, that would be great. Sorry for inconvenience. If you issue is not fixed in the latest Nightly, could you please file a new bug?

Hi Toshihito,
that's it! Thanks for your tip. I installed the nightly version 73.0a1 and everything works! So Bug-1597963 could have been the reason.
Thanks to the community - now I can sleep well again ;-)
Malte

(In reply to Toshihito Kikuchi [:toshi] from comment #14)

(In reply to roger.thomas from comment #9)

My tests with the x64 installer were also successful.

Thanks for verifying the bits quickly, Peter and Roger! At least we're 100% sure what is a regressing fix.

Roger, I want to ask you to do one more test on the original ESR. As :Gijs mentioned earlier, there is another regression, Bug 1601905. I want to make sure this issue is not a dup of Bug 1601905.

To verify that, can you save a file first, and then open it from Firefox's download library? If the issue still happens, this is not Bug 1601905. Then I'll start prototyping a fix and probably ask you to verify it.

With Firefox 68.2 ESR, pdf files with and without spaces can be opened with the default pdf viewer. With Version 68.3 no Files opened, they only saved to %username%\appdata\local\temp\

Flags: needinfo?(roger.thomas)

(In reply to roger.thomas from comment #16)

With Firefox 68.2 ESR, pdf files with and without spaces can be opened with the default pdf viewer. With Version 68.3 no Files opened, they only saved to %username%\appdata\local\temp\

Thank you for checking that. I'm assuming %username% on your end does not include any whitespaces.

Once a prototype for this issue is ready, I'll update this bug.

Assignee: nobody → tkikuchi

If we land a fix in the next week, there still may be time to uplift for 72 and 68.4esr.

Duplicate of this bug: 1604626

A prototype is ready to test. I added a simple fallbak logic and logging code to Browser Console.

Installer of x64 (Submitted job):

https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/MywFRdAuTwCviJCsUmZAZA/runs/0/artifacts/public/build/install/sea/target.installer.exe

Roger, could you try the following steps with this prototype?

  1. Install a prototype and run it from client
  2. Press Ctrl+Shift+J to open Browser Console
  3. Reproduce the issue (I hope the fallback logic solves the issue this time...)
  4. Regardless of the result, copy output on Browser Console

If the logging code works correctly, you'll see messages on Browser Console like below. Please copy-and-paste it here so that we can see what happens with Citrix.

GetSystemMetrics(SM_REMOTESESSION) - 1
WTSQuerySessionInformationA - 2
CoCreateInstance(CLSID_ShellWindows) - 00000000
IShellWindows::FindWindowSW - 00000000
IDispatch::QueryInterface(IID_IServiceProvider) - 00000000
IServiceProvider::QueryService(SID_STopLevelBrowser) - 00000000
IShellBrowser::QueryActiveShellView(SID_STopLevelBrowser) - 00000000
IShellView::GetItemObject() - 00000000
IDispatch::QueryInterface(IID_IShellFolderViewDual) - 00000000
IShellFolderViewDual::get_Application() - 00000000
IDispatch::QueryInterface(IID_IShellDispatch2) - 00000000
IShellDispatch2::ShellExecute() - 00000000
Flags: needinfo?(roger.thomas)

Hi Toshi, the pdf File opened in PDF Viewer

XHRGEThttps://blocklists.settings.services.mozilla.com/v1/blocklist/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/68.4.0/Firefox/20191217200913/WINNT_x86_64-msvc/en-US/default/Windows_NT%206.1/default/default/1/1/new/
[HTTP/1.1 200 Connection established 1530ms]

JsonSchemaValidator.jsm: Ignoring parameter "https://www.s-ncc.de/kunden/fi/nccreg.nsf" - origin was expected but received full URL. JsonSchemaValidator.jsm:236
JsonSchemaValidator.jsm: Ignoring parameter "https://www.s-ncc.de/leser/index.htm" - origin was expected but received full URL. JsonSchemaValidator.jsm:236
uncaught exception: 2147746065 SessionStore.jsm:1325:22
Unknown category for SetEventRecordingEnabled: fxmonitor
Key event not available on some keyboard layouts: key=“i” modifiers=“accel,alt,shift” id=“key_browserToolbox” browser.xul
uncaught exception: 2147746132 2
GetSystemMetrics(SM_REMOTESESSION) - 1
WTSQuerySessionInformationA - 1
CoCreateInstance(CLSID_ShellWindows) - 80040154

I tested it with this link: https://checkmk.com/download/Marco_Reale_Check_MK_Beginner_guide.pdf

Flags: needinfo?(roger.thomas)

Thank you for sharing the result! Knowing CoCreateInstance failed with REGDB_E_CLASSNOTREG (= 80040154) is big progress.

(In reply to Masatoshi Kimura [:emk] from comment #22)

https://searchfox.org/mozilla-central/rev/6305f6935f496b3a302c7afcc579399a4217729c/widget/windows/ShellHeaderOnlyUtils.h#56
Should dwClsContext be CLSCTX_ALL (that is, should it contain CLSCTX_REMOTE_SERVER)?

Maybe, but I'm not sure. In my understanding, firefox.exe is running on the server. Getting REGDB_E_CLASSNOTREG seems to mean the Citrix server does not register shell. At the same time, a downloaded file should be stored in the server. Communication between firefox and shell will not be cross-machine. All is my hypothesis, though.

Luckily I had a chance to test this scenario on Microsoft RemoteApp. I could reproduce the issue, but interestingly, the failure was IShellWindows::FindWindowSW returned S_FALSE. Good news is in both cases we get an error code.

Neither WTSQuerySessionInformationA nor GetSystemMetrics(SM_REMOTESESSION) is useful because it returns the same in a normal RDP session.

However we detect the situation, we don't know a perfect solution if a user opens Skype for Business (or anything which does not support the PreferSystem32Images policy) in Citrix or RemoteApp. We should ask Microsoft whether there is a nice way to deal with it. In the meantime I'm thinking to add a fallback simply when ShellExecuteByExplorer returns an error.

Priority: -- → P1
Duplicate of this bug: 1605472

checked on Firefox 68.2.0 ESR - works properly. Opens files.
checked on Firefox 68.3.0 ESR and 71 (wrrrrr... I had to edit my compatibility.ini profile file to return to 68.2.0esr from 68.3.0/71) - doesn't work. No action after clicking opening file with associated app.

HOW TO EDIT THIS BEHAVIOUR WITH about:config? Security bugs fixed in 68.3.0esr but I cannot work with this version with standard conf.

BTW. I use Windows 8.1, not Server 2012. My bug is marked as duplication of this bug.

It turned out that ShellExecuteByExplorer does not work on VDI such as Citrix
or Microsoft RemoteApp. This patch adds a fallback to the original launching
code if ShellExecuteByExplorer fails. This will be a temporary solution until
we find out a way to solve both interop issues PreferSystem32Images and VDI.

I think that fallback to ShellExecuteEx should be forever. Please read about ReactOS. Firefox should work also on ReactOS. It is really need use of ShellExecuteByExplorer or PreferSystem32Images if ShellExecuteEx function is good enough?

Additionally Firefox uses GetVersion/GetVersionEx instead of testing features. Please see source code. Checking version of Windows is very bad practice. Firefox shall be open also for emulators (Wine) and alternative systems (ReactOS).

Why? Do we have to change browser?

Flags: needinfo?(jcristau)
Flags: needinfo?(jcristau)

After research: this bug does not apply only to citrix and remote app.

Applies to all Windows with a changed default "shell" (progman) and Windows with removed or not-launched shell (most KIOSK mode configurations without EXPLORER shell).

Changed or removed default shell (main explorer.exe process) means:

  • the explorer.exe is still present in system and can be used to manual browsing catalogs but not start as shell.
  • IShellWindows::FindWindowSW etc. methods may not work due to undocumented behaviour of this feature (undocumented communication between OS and explorer.exe),
  • WinExec, CreateProcess, ShellExecuteEx still works.

For testing, it is probably sufficient to kill explorer.exe in taskmgr.exe and then download a PDF / DOCX and trying to open it (with shutdowned explorer.exe).

After googling, the ShellExecuteByExplorer has long history of bugs... in the past. Due to use "new API functions" added in Vista, Windows 7 and Windows 8 (not fully documented).

Running unelevated process doesn't need to use new not fully documented shell functions. It can be done like here:
https://www.codeproject.com/Articles/16796/Riding-the-Vista-UAC-elevator-up-and-down
Running with lower privileges doesn't force user to click the UAC.

BTW. Can I please link to download compiled version (unofficial) of win32 Firefox 68.3.0/68.4.0 ESR with corrected this bug (with D58054 solution)?

(In reply to Mozira from comment #30)

Running unelevated process doesn't need to use new not fully documented shell functions. It can be done like here:
https://www.codeproject.com/Articles/16796/Riding-the-Vista-UAC-elevator-up-and-down

It does not work with non-admin users, so it's useless for our purpose.

(In reply to Masatoshi Kimura [:emk] from comment #31)

(In reply to Mozira from comment #30)

Running unelevated process doesn't need to use new not fully documented shell functions. It can be done like here:
https://www.codeproject.com/Articles/16796/Riding-the-Vista-UAC-elevator-up-and-down

It does not work with non-admin users, so it's useless for our purpose.

If non admin user then the firefox process is not run woth privileged node and here can be used... ShellExecuteEx?

@Toshi, which version should I download for Windows 8.1 32-bit? Where I find msi or exe files?

Flags: needinfo?(tkikuchi)

Thank you @Tochi.

The win32 Firefox looks to work correctly (including opening of PDF / ODT files) :-)

Whiteboard: [enterprise]
Duplicate of this bug: 1605469
Pushed by ccoroiu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/32803329a548
Fall back to ShellExecuteEx if ShellExecuteByExplorer fails.  r=aklotz
Status: NEW → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 74

In which firefox-esr68 version the bug will be fixed?

Please nominate this for Beta and ESR68 approval when you get a chance.

Flags: needinfo?(tkikuchi)

Comment on attachment 9117380 [details]
Bug 1602726 - Fall back to ShellExecuteEx if ShellExecuteByExplorer fails. r=aklotz

Beta/Release Uplift Approval Request

  • User impact if declined: If explorer.exe is not available in a user's environment, Firefox fails to open a downloaded file. This is a regression from Bug 1588975. The affected environment includes VDI such as Microsoft RemoteApp and Citrix.
  • 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): The risk is low because the fix is to add a fallback to the original logic (use ShellExecuteEx) if a new logic fails.
  • String changes made/needed: None
Flags: needinfo?(tkikuchi)
Attachment #9117380 - Flags: approval-mozilla-beta?

Comment on attachment 9117380 [details]
Bug 1602726 - Fall back to ShellExecuteEx if ShellExecuteByExplorer fails. r=aklotz

Falls back to the old logic to avoid a regression from bug 1588975 causing issues in Citrix environments. Approved for 73.0b3.

Attachment #9117380 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Flags: qe-verify+

Comment on attachment 9117380 [details]
Bug 1602726 - Fall back to ShellExecuteEx if ShellExecuteByExplorer fails. r=aklotz

ESR Uplift Approval Request

  • If this is not a sec:{high,crit} bug, please state case for ESR consideration: This is a regression from Bug 1588975, which was uplifted to ESR. The affected environment includes VDI such as Microsoft RemoteApp and Citrix. Those environments are used by enterprise customers.
  • User impact if declined: If explorer.exe is not available in a user's environment, Firefox fails to open a downloaded file.
  • Fix Landed on Version: 74.0a1
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): The risk is low because the fix is to add a fallback to the original logic (use ShellExecuteEx) if a new logic fails.
  • String or UUID changes made by this patch: None
Attachment #9117380 - Flags: approval-mozilla-esr68?
QA Whiteboard: [qa-triaged]

Hi guys, unfortunately we can not successfully reproduce and verify this issue because we are lacking the exact environment on which it was reproducible.

Peter or Mozira, could you look over if you have some time and verify that it has been fixed and working correctly? Thank you!

Flags: qe-verify+
Flags: needinfo?(bugzil.la)
Flags: needinfo?(Peter.Geier)

Hi Catalin,
I need download links for fixed 68esr and fixed 7x Version.

Flags: needinfo?(Peter.Geier)

68esr seems to be not yet fixed, but you can verify on 73.0b3 (https://archive.mozilla.org/pub/firefox/candidates/73.0b3-candidates/build1/) and 74.0a1 (https://archive.mozilla.org/pub/firefox/nightly/2020/01/2020-01-10-09-50-23-mozilla-central/).

Thank you! Please let me know if you need anything else.

Hi Catalin,

both Versions works fine, seems to be fixed :-)

Please inform me about fixing 68esr Version.
We only use this version on Citrix.
It will be important, because esr 68.4.1 includes a critical fix an we use aktual 68.2.0.
Thanks a lot.

Sure thing Peter! Thanks to you too for verifying them.

Comment on attachment 9117380 [details]
Bug 1602726 - Fall back to ShellExecuteEx if ShellExecuteByExplorer fails. r=aklotz

Thanks for the Nightly and Beta verification. Approved for 68.5esr.

Attachment #9117380 - Flags: approval-mozilla-esr68? → approval-mozilla-esr68+

I returned to Firefox 68.4.0.

Firefox 68.4.1 and 68.4.0 - I attach screenshots of behaviour. New behaviour in 68.4.1 is unacceptable. Please see screens.

Flags: needinfo?(ryanvm)
Flags: needinfo?(catalin.sasca)
Flags: needinfo?(bugzil.la)
Attached image bugzilla.png

Screens. Good behaviour in 68.4.0. Wrong behaviour in FF 68.4.1!!!

Links in Thunderbird 68.4.1 also not working.

Please leave status flags alone.

For what it's worth there's no relevant change between firefox 68.4.0 and 68.4.1.

Thus why FF Nightly 68.4.0 (compilation above) works and FF 68.4.1 Official not?

Flags: needinfo?(jcristau)

Please try kill Explorer.exe and then try both versions.

(In reply to Mozira from comment #58)

Thus why FF Nightly 68.4.0 (compilation above)

You tried what's called a "trypush" build (comment #35); not the official/real 68.4.0 build. This build was set up by a developer so you could test if things worked. It included 2 patches - the one on this bug, and the one on bug 1601905.

works and FF 68.4.1 Official not?

The official fx 68.4.1 build doesn't have the patch from this bug, it only has the patch from bug 1601905. This bug was marked as fixed on ESR because the 68.5 release will include the fix from this bug. This is normal procedure - bugs are labeled fixed on branches that have the code, even if no official release has happened with that code yet.

Mr. @Gijs, thank you for clarifying the situation.

I thought version FF 68.4.1esr includes all 68.4.0 Nightly fixes. So I'll wait for version 68.5.0esr and test official 68.5.0. :-)
Forgive me for not knowing your procedures.
I will inform how 68.5.0 works due to thisbug. When the release of 68.5.0esr is planned? (I'm on Nightly update channel now...)

@Toshi's version works correctly (68.4.0 Nightly).

Flags: needinfo?(ryanvm)
Flags: needinfo?(jcristau)
Flags: needinfo?(catalin.sasca)

Links in Thunderbird 68.4.1 also not working.

TB 68.4.1 doesn't have this patch.

Another way to reproduce:

start Firefox under a different user account like:

C:\WINDOWS\system32\cmd.exe /c C:\WINDOWS\system32\runas.exe /savecred /profile /user:TestAccount "C:\Program Files\Firefox Nightly\firefox.exe -nosplash -no-remote"

And yes: Firefox Nightly 74.0a1 works fine
And yes: Thunderbird 68.4.1 is broken (start as above)

Official Firefox 68.4.2esr properly opens PDFs/ODTs for me.

Hmm, will this be a problem for Thunderbird? https://searchfox.org/mozilla-central/rev/cfd1cc461f1efe0d66c2fdc17c024a203d5a2fd8/xpcom/io/nsLocalFileWin.cpp#90

rv = winMediator->GetMostRecentWindow(u"navigator:browser",

(In reply to Magnus Melin [:mkmelin] from comment #67)

Hmm, will this be a problem for Thunderbird? https://searchfox.org/mozilla-central/rev/cfd1cc461f1efe0d66c2fdc17c024a203d5a2fd8/xpcom/io/nsLocalFileWin.cpp#90

rv = winMediator->GetMostRecentWindow(u"navigator:browser",

GetMostRecentNavigatorHWND is not a new function. I removed it as https://hg.mozilla.org/mozilla-central/rev/d20b7b5518c6, and now I reverted it back.

See Also: → 1608012

Hi guys,

I am working for a company that replaces the windows shell, and dont have explorer.exe running in the background when firefox are running.

From the comments it sounds like this issue should have been fixed but i cannot get it to work on any versions of firefox. I have tried all versions mentioned in this thread and still we are having issues getting firefox to launch applications without the explorer shell running.

The links that we are trying to run is the following:

steam://connect/ipaddress
esportal://arg/arg

the behavior is working as exected when running firefox normally but as soon as windows explorer is killed via task manager nothing happens when clicking the launch button in firefox.

this is the console error output when attempting without explorer.exe running : https://gyazo.com/7006fdce2ffb5a73236aac6d10001fca

am i missing something, should this not work in the current nightly build 75.0a1?

if not can anyone give a link to a version where this is working.

The issue is easy to replicate just kill windows explorer and the above links will fail after working fine when it is running.

(In reply to Koenig from comment #69)

The links that we are trying to run is the following:

steam://connect/ipaddress
esportal://arg/arg
...
as soon as windows explorer is killed via task manager nothing happens when clicking the launch button in firefox.

this is the console error output when attempting without explorer.exe running : https://gyazo.com/7006fdce2ffb5a73236aac6d10001fca

The issue is easy to replicate just kill windows explorer and the above links will fail after working fine when it is running.

Please can you file a new bug and CC me and :toshi and leave a comment here?

For reference, I suspect https://searchfox.org/mozilla-central/rev/a4be2fbe9bd4f405c91cc16e4e3a80400f5a9301/uriloader/exthandler/win/nsMIMEInfoWin.cpp#270-275 is failing (which is asking the shell to validate URLs). This code is specific to launching URIs, and this bug is about files, not URIs.

Flags: needinfo?(kenneth)

(In reply to :Gijs (he/him) from comment #70)

(In reply to Koenig from comment #69)

The links that we are trying to run is the following:

steam://connect/ipaddress
esportal://arg/arg
...
as soon as windows explorer is killed via task manager nothing happens when clicking the launch button in firefox.

this is the console error output when attempting without explorer.exe running : https://gyazo.com/7006fdce2ffb5a73236aac6d10001fca

The issue is easy to replicate just kill windows explorer and the above links will fail after working fine when it is running.

Please can you file a new bug and CC me and :toshi and leave a comment here?

For reference, I suspect https://searchfox.org/mozilla-central/rev/a4be2fbe9bd4f405c91cc16e4e3a80400f5a9301/uriloader/exthandler/win/nsMIMEInfoWin.cpp#270-275 is failing (which is asking the shell to validate URLs). This code is specific to launching URIs, and this bug is about files, not URIs.

Hi, thank you for the reply.

Im new to this forum, so dont really know how to CC :)

I have created a new bug submission that can be found here :

https://bugzilla.mozilla.org/show_bug.cgi?id=1615370

Flags: needinfo?(kenneth)

With shell replacement Firefox 68.5.0 also works for me, but thunderbird 68.5.0 doesn't open links starting from version 68.3.1. Version 68.5.0esr of Thunderbird is probably affected by other problem because Thunderbird 68.3.0 doesn't open attachments (like here) but opened links! In 68.3.1 links stopped to work. It means, there was other modification of code.

Duplicate of this bug: 1605308
You need to log in before you can comment on or make changes to this bug.