Bugzilla

Comment 1

•

4 years ago

Same Problem with Windows Server 2008 R2 and Published Citrix Apps

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

Comment 2

•

4 years ago

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)

Jim Mathies [:jimm]

Comment 3

•

4 years ago

[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

status-firefox72: --- → affected

status-firefox73: --- → affected

status-firefox-esr68: --- → affected

tracking-firefox-esr68: --- → ?

Ever confirmed: true

Comment 4

•

4 years ago

Possible regressor: bug 1588975

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

Comment 5

•

4 years ago

Would this also affect users on 71 release?

Assignee

Comment 6

•

4 years ago

(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)

Assignee

Comment 7

•

4 years ago

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.

Peter.Geier

Reporter

Comment 8

•

4 years ago

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)

Pascal Chevrel:pascalc (PTO until April 26)

Comment 9

•

4 years ago

My tests with the x64 installer were also successful.

Flags: needinfo?(roger.thomas)

Updated

•

4 years ago

status-firefox71: --- → affected

tracking-firefox71: --- → +

Malte

Comment 10

•

4 years ago

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.

Masatoshi Kimura [:emk]

Comment 11

•

4 years ago

•

Edited

When you right click the .dotm-file and select New from the context menu, does the startup macro run?
When you right click the .dotm-file and select Open from the context menu, does the startup macro run?

Flags: needinfo?(RiemerMalte)

Gingerbread Man

Updated

•

4 years ago

No longer blocks: 1588975

Keywords: regression

Regressed by: 1588975

BMO Automation

Updated

•

4 years ago

Has Regression Range: --- → yes

Malte

Comment 12

•

4 years ago

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

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"

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)

Assignee

Comment 13

•

4 years ago

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?

Assignee

Comment 14

•

4 years ago

(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)

Malte

Comment 15

•

4 years ago

(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

Comment 16

•

4 years ago

(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)

Assignee

Comment 17

•

4 years ago

(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.

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

Assignee

Updated

•

4 years ago

Assignee: nobody → tkikuchi

Comment 18

•

4 years ago

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

status-firefox71: affected → wontfix

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

Assignee

Comment 20

•

4 years ago

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

Installer of x64 (Submitted job):

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

Install a prototype and run it from client
Press Ctrl+Shift+J to open Browser Console
Reproduce the issue (I hope the fallback logic solves the issue this time...)
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)

Comment 21

•

4 years ago

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)

Masatoshi Kimura [:emk]

Comment 22

•

4 years ago

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)?

Marco Bonardo [:mak] (Away Apr 25 - May 5)

Assignee

Comment 23

•

4 years ago

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.

•

4 years ago

status-firefox72: affected → wontfix

Julien Cristau [:jcristau]

Comment 29

•

4 years ago

Why? Do we have to change browser?

Flags: needinfo?(jcristau)

Updated

•

4 years ago

Flags: needinfo?(jcristau)

Comment 30

•

4 years ago

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)?

Masatoshi Kimura [:emk]

Comment 31

•

4 years ago

(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.

Comment 32

•

4 years ago

(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?

Assignee

Comment 33

•

4 years ago

(In reply to Mozira from comment #30)

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)?

Here it is.

Submitted job:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=a3062338c656260afc7559519bcfb0f279845648&selectedJob=283221177
x64 installer:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/SPTygn80QKGLQfehJ3CDWw/runs/0/artifacts/public/build/install/sea/target.installer.exe
Full x64 binaries:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/SPTygn80QKGLQfehJ3CDWw/runs/0/artifacts/public/build/target.zip

Comment 34

•

4 years ago

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

Flags: needinfo?(tkikuchi)

Assignee

Comment 35

•

4 years ago

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

Flags: needinfo?(tkikuchi)

https://hg.mozilla.org/mozilla-central/rev/32803329a548

Comment 36

•

4 years ago

Thank you @Tochi.

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

Devin Reams

Updated

•

4 years ago

Whiteboard: [enterprise]

Pulsebot

Comment 38

•

4 years ago

Pushed by ccoroiu@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/32803329a548
Fall back to ShellExecuteEx if ShellExecuteByExplorer fails.  r=aklotz

Andreea Pavel [:apavel]

Comment 39

•

4 years ago

bugherder

Status: NEW → RESOLVED

Closed: 4 years ago

status-firefox74: --- → fixed

Resolution: --- → FIXED

Target Milestone: --- → Firefox 74

Ryan VanderMeulen [:RyanVM]

Updated

•

4 years ago

tracking-firefox73: --- → +

tracking-firefox74: --- → +

•

4 years ago

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+

Ryan VanderMeulen [:RyanVM]

Updated

•

4 years ago

Flags: qe-verify+

Narcis Beleuzu [:NarcisB]

Comment 44

•

4 years ago

bugherder uplift

https://hg.mozilla.org/releases/mozilla-beta/rev/dcd448e696e1

status-firefox73: affected → fixed

Camelia Badau [:cbadau], Desktop QA

Assignee

Comment 45

•

4 years ago

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?

Updated

•

4 years ago

QA Whiteboard: [qa-triaged]

Catalin Sasca, Desktop QA [:csasca]

Comment 46

•

4 years ago

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)

Peter.Geier

Reporter

Comment 47

•

4 years ago

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

Flags: needinfo?(Peter.Geier)

Catalin Sasca, Desktop QA [:csasca]

Comment 48

•

4 years ago

Comment 54

•

4 years ago

Attached image bugzilla.png — Details

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

Comment 55

•

4 years ago

Links in Thunderbird 68.4.1 also not working.

Julien Cristau [:jcristau]

Updated

•

4 years ago

status-firefox73: verified → ?

status-firefox74: verified → ?

status-firefox-esr68: fixed → ---

Comment 56

•

4 years ago

Please leave status flags alone.

status-firefox73: ? → verified

status-firefox74: ? → verified

status-firefox-esr68: --- → fixed

Julien Cristau [:jcristau]

Comment 57

•

4 years ago

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

Comment 58

•

4 years ago

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

Flags: needinfo?(jcristau)

Comment 59

•

4 years ago

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

Comment 60

•

4 years ago

(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.

Comment 61

•

4 years ago

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).

Ryan VanderMeulen [:RyanVM]

Updated

•

4 years ago

Flags: needinfo?(ryanvm)

Flags: needinfo?(jcristau)

Flags: needinfo?(catalin.sasca)

Jorg K (CEST = GMT+2)

Comment 62

•

4 years ago

Links in Thunderbird 68.4.1 also not working.

TB 68.4.1 doesn't have this patch.

V.Bartels

Comment 63

•

4 years ago

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)

Comment hidden (advocacy)

Comment 65

•

4 years ago

uplift

Landed on FIREFOX_ESR_68_4_X_RELBRANCH for 68.4.2.
https://hg.mozilla.org/releases/mozilla-esr68/rev/20ab1567df2b04f11625bac2ce8fe2984c4c08eb

tracking-firefox-esr68: 73+ → 72+

Comment 66

•

4 years ago

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

Magnus Melin [:mkmelin]

Comment 67

•

4 years ago

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",

Assignee

Comment 68

•

4 years ago

(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.

Updated

•

4 years ago

Comment 69

•

4 years ago

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.

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

Comment 70

•

4 years ago

(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)

Koenig

Comment 71

•

4 years ago

(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 :

Flags: needinfo?(kenneth)