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

Steps to reproduce:

With the following config options:

capability.policy.localfilelinks.checkloaduri.enabled allAccess
capability.policy.localfilelinks.sites https://mydomain
capability.policy.policynames localfilelinks

Clicking a link to a local file, for example to file:///c:/document.docx and selecting 'open with ...'

Actual results:

It downloaded document.docx to the temporary downloads directory and opened the file at that new location in the document editor program

Expected results:

It opened c:/document.docx in the document editor program.

Until the latest update to firefox 96 this was the observed behavior.
If this the new behavior is intended, it would be nice to have a config option to revert it.

The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Same issue here with any file extension firefox cannot open by itself.

This is an important feature for us as it saves us a lot of time.

Mike, how important do you think this is?

If somebody could run mozregression to figure out where in Firefox 96 this broke, that would probably be a useful step towards figuring out what the next steps might be.

Ican reproduce the issue in Nightly98 Windows10.
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=2f723b6e625b4498f17e95b73f26292d6730ef9b&tochange=2f718538b94c8509d7dc37a15c96b0da716f18d2

This is definitely important. There are still enterprises that depend on this behavior.

[Tracking Requested - why for this release]: regression in 96 affecting at least some enterprise users

For what it is worth, I didn't find any other bugs filed with policynames or localfilelinks mentioned in the first comment.

https://hg.mozilla.org/mozilla-central/rev/5537bab64655

Comment on attachment 9259779 [details]
Bug 1750042 - local files that trip the 'what do you want to do with this file' dialog should open from their initial location, r?mhowell,mtigley,mkaply

Beta/Release Uplift Approval Request

• User impact if declined: Local files don't open the way they should (create additional copies)
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: No
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: See comment 0. Make sure the filetype in question is set to "always ask" in the Firefox settings.

Alternatively, I believe you can also reproduce (without setting the policy prefs) by just opening a directory listing inside Firefox (e.g. opening file:///C:/Users/<username>/Downloads/) and then clicking a link to a filetype that is set to "always ask"

• List of other uplifts needed: n/a
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Fairly straightforward patch that adds back functionality accidentally removed during a refactor, and adds an automated test so we don't regress it again. Plus we still have some beta runway.
• String changes made/needed: None

Comment on attachment 9259779 [details]
Bug 1750042 - local files that trip the 'what do you want to do with this file' dialog should open from their initial location, r?mhowell,mtigley,mkaply

Approved for 97.0b7.

https://hg.mozilla.org/releases/mozilla-beta/rev/5457a9293dbb

I have managed to reproduce this issue in Firefox v96.0.2 on Windows 10, using the following steps:

1. Download a docx sample file
2. Copy it to C drive
3. Lunch browser and load file:///C:/
4. click the docx file
5. Open with: 3rd party app (Libre Office in my case)
   Expected: the file is opened by Libre Office from its initial location
   Actual: the file is downloaded in the Temp folder and opened by Libre Office

I have managed to verify the fix in Beta v97.0b7 and Nightly v98.0a1, using the same steps above, and also on Ubuntu 20.04.3 LTS and Mac OS 10.11.6 with similar steps.