1630757 - Page contents erased when following a link that uses an external protocol

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect, P1)

Description

[James Abbatiello]

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:[e-mail]">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.

Comment 1

[James Abbatiello]

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

Comment 2

[BugBot [:suhaib / :marco/ :calixte]]

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

Comment 3

[Paul Bone [:pbone]]

Ouch, thanks for the bug report.

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

Comment 4

[Firefox Bug Husbandry Bot]

Resetting severity to default of --.

Comment 5

[Paul Bone [:pbone]]

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.

Comment 6

[James Abbatiello]

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.

Comment 7

[Paul Bone [:pbone]]

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.