Bug 1688774 - Enable "Connection Settings" dialog to Accept file:// and npipe:// proxy

[wwtraveler]

Accept file:// and npipe:// URIs in SOCKS Host field of the Connection Settings dialog

When a user enters a file:///path/to/socket or npipe:///./pipe/name URI into the "SOCKS Host" field in Firefox's Connection Settings dialog and clicks OK, the dialog fails to accept the value. The OK button does nothing because the validation in the beforeaccept event handler rejects the URI because the / characters in the scheme are treated as invalid hostname characters.

The underlying SOCKS implementation already fully supports Unix domain sockets (file://) on Unix and named pipes (npipe://) on Windows — the problem was only in the dialog validation, not in the actual SOCKS connection code.

In browser/components/preferences/dialogs/connection.js line 131, the beforeAccept handler validates the SOCKS host using Services.io.isValidHostname():

} else if (!Services.io.isValidHostname(proxyPref.value)) {

Services.io.isValidHostname() returns false for file:///path/to/socket because the / characters in the URI scheme aren't valid hostname characters according to the DNS hostname validation rules. This triggers event.preventDefault() which blocks the OK button.

The SOCKS implementation already supports these URIs:

• nsSOCKSIOLayer.cpp: SetLocalProxyPath() (line 121) handles file:// paths on both Unix and Windows, setting aProxyAddr->raw.family = AF_UNIX / AF_LOCAL
• nsSOCKSIOLayer.cpp: IsLocalProxy() (line 115) checks IsHostLocalTarget() which returns true when the host starts with file:
• nsSOCKSSocketProvider.cpp: OpenTCPSocket() (line 43) checks StringBeginsWith(proxyHost, "file://") and sets family = AF_LOCAL for Unix domain sockets

The dialog validation just wasn't aware of these URI schemes.

Before (line 131):

} else if (!Services.io.isValidHostname(proxyPref.value)) {

After (line 131):

} else if (
  !Services.io.isValidHostname(proxyPref.value) &&
  !(prefName === "socks" && (proxyPref.value.startsWith("file://") || proxyPref.value.startsWith("npipe://")))
) {

The change adds a SOCKS-specific check: if the field is the SOCKS field (prefName === "socks") and the value starts with file:// or npipe://, it is considered valid even if isValidHostname() returns false.

Added a new test_socks_file_uri() test that verifies:

1. file:///var/run/socks5.sock is accepted for SOCKS
2. npipe:///./pipe/socks is accepted for SOCKS (Windows named pipes)
3. Regular SOCKS hostnames like localhost still work

Platform	URI Scheme	Description
Unix/Linux	file:///path/to/socket	Unix domain socket
Both	file:///path/to/socket	Works on all platforms

• The underlying SOCKS implementation for file:// was added in previous patches (see nsSOCKSIOLayer.cpp line 156 for AF_UNIX and nsSOCKSSocketProvider.cpp line 50 for the file:// check)

• npipe:// support mirrors the Windows named pipe implementation

• This is not a new feature, but rather fixing the dialog to accept what the SOCKS code already understands

• Added test_socks_file_uri() in browser_connection_valid_hostname.js with three test cases:

  1. file:///var/run/socks5.sock -- accepted
  2. npipe:///./pipe/socks -- accepted
  3. localhost -- still works (regression check)

• Manual testing:

  1. Open about:networking#socks or about:preferences#general
  2. Scroll to "Connection Settings"
  3. Select "Manual proxy configuration"
  4. Enter file:///var/run/socks5.sock in the SOCKS Host field
  5. Click OK -- dialog accepts the value

• ./mach try fuzzy -q "browser_connection_valid_hostname"

• ./mach test --headless browser/components/preferences/tests/networking/browser_connection_valid_hostname.js

[firefoxci-taskcluster]

No Taskcluster jobs started for this pull request

The allowPullRequests configuration for this repository (in .taskcluster.yml on the default branch) does not allow starting tasks for this pull request.

[github-actions]

(Automated Close) Please do not file pull requests here, see https://firefox-source-docs.mozilla.org/contributing/how_to_submit_a_patch.html