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

Steps to reproduce:

1. Create a file on local disk containing a link that uses an external protocol (irc:, mailto:, sip:, etc.). For example: <a href="sip:user@example.net">sip</a>
2. Open that page in Firefox using a file:// URI
3. Click the link

I'm also experiencing this when the page is loaded from http://www.example.com (instead of file://) and the localfilelinks policy is set to include http://www.example.com in the whitelist. See http://kb.mozillazine.org/Links_to_local_pages_don%27t_work

Actual results:

The external program opens.
The current page contents are erased, leaving you with a blank page.

Expected results:

The external program opens.
The page contents are left unmodified.

I bisected this using mozregression-gui to:
app_name: firefox
build_date: 2020-02-13 05:08:04.318000
build_file: ....mozilla\mozregression\persist\b158903288bb-shippable--autoland--target.zip
build_type: integration
build_url: https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/NizPhVCNT16lQ2gtJ-NFew/runs/0/artifacts/public%2Fbuild%2Ftarget.zip
changeset: b158903288bb2968dff9e587a3a8ca67f7435e37
pushlog_url: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=b0e84820d231a3b5a47f2ea72c384828d91f4c49&tochange=b158903288bb2968dff9e587a3a8ca67f7435e37
repo_name: autoland
repo_url: https://hg.mozilla.org/integration/autoland
task_id: NizPhVCNT16lQ2gtJ-NFew

https://hg.mozilla.org/integration/autoland/rev/b158903288bb2968dff9e587a3a8ca67f7435e37
Bug 1603006

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Ouch, thanks for the bug report.

Leaving the NI flag on it until I can confirm and accept the bug.

Resetting severity to default of --.

So far I havn't been able to reproduce this. Can you tell me what OS/Platform this is? Have you tried with a fresh profile? Any other clues?

Thanks.

I'm on Windows 10, 64-bit builds of Firefox. I can reproduce with an empty profile using firefox -no-remote -profile c:\empty_profile (where I've manually confirmed that c:\empty_profile does not exist before starting). And it shows up via mozregression-gui which is configured to start with a blank profile.

I just retested and I can reproduce with im:, irc:, ircs:, mms:, sip:, tel:, or webcal:, but not with mailto:, news:, or nntp:. I could have sworn it was reproducing with mailto: previously but perhaps I was mistaken.

Maybe this has something to do with what protocols are registered with Windows in, e.g. HKCR\irc? I do have keys for all of the protocols that I can reproduce with listed above. I also have a key for HKCR\mailto but perhaps that is handled internally by Firefox as a special case.

Thanks James, I've managed to reproduce this.

I also found that mailto: was working okay but irc: wasn't. I tested.

WIndows 10, Firefox 75: broken.
WIndows 10, Firefox 77: Works.
Linux, Firefox 75: Broken
Linux, Firefox 77: Works.

So it was that I was trying mailto: earlier and that always worked for me. But irc: is definitely broken. Anyway it's fixed already, mozregression says that I fixed this in Bug 1597154.

[Tracking Requested - why for this release]: This has already been fixed in beta when fixing a different bug, but it's still a problem for release.