breakage with extensions connecting to localhost

[aspiers]

Description

At least three extensions which want to open websockets connections to servers on localhost don't work, with connection errors shown on the extension consoles.

Steps to Reproduce

1. Install and set up Atomic Chrome or Edit with Emacs, so that servers are listening for connections on some localhost port.
2. Try to edit a <textarea> field
3. Observe lack of functionality, and errors such as WebSocket connection to 'ws://localhost:64292/' failed and net::ERR_BLOCKED_BY_CLIENT in the extension console logs, as described in Doesn't work with Brave: WebSocket connection to localhost fails danhper/atomic-chrome#36 and Doesn't work on Brave: net::ERR_BLOCKED_BY_CLIENT stsquad/emacs_chrome#179 respectively.

Actual result:

See danhper/atomic-chrome#36 and stsquad/emacs_chrome#179 for exact results.

Expected result:

No connection errors, and extensions work perfectly.

Reproduces how often:

100% reproducible

Brave version (brave://version info)

This was on Brave version 1.21.73 Chromium: 89.0.4389.72 (Official Build) (64-bit).

I have also tested on Google Chrome version 89.0.4389.72 (Official Build) (64-bit) and both extensions work perfectly.

Version/Channel Information:

Only tried with 1.21.73 so far.

Other Additional Information:

• Does the issue resolve itself when disabling Brave Shields? No
• Does the issue resolve itself when disabling Brave Rewards? No
• Is the issue reproducible on the latest version of Chrome? No, Chrome 89 works perfectly

[aspiers]

I have just tested with a third extension GhostText which works in the same way, and witnessed exactly the same results, i.e. Brave is broken and Chrome is not.

[ryanbr]

Related to this: #15004

[aspiers]

Thanks @ryanbr, that's really good to know. Just to confirm: I tried testing with shields down and it didn't help. Is that because the block is happening within the extension rather than within the (unshielded) webpage I'm trying to use the extension on?

[aspiers]

As confirmed on stsquad/emacs_chrome#179 this is also a problem with regular HTTP connections, not just websockets. I've updated the title and description accordingly.

[ryanbr]

Not ideal, but turning off ads & trackers in shields globally (via brave://settings/shields) should help with an extension. For a website, it can be tuned more for a per-site basis. @aspiers

[aspiers]

Thanks for the info! Is there any way to turn it off for just an extension?

[ryanbr]

Not currently

[nickform]

I am being affected by what seems to be this issue but for sites (not extensions) and have two questions. First, what is the rationale behind the policy to block requests to localhost? Second, what is the workflow to workaround this on a per-site basis as referred to by @ryanbr ? Thanks for reading.

[khwerhahn]

My Websockets also fail. They work both in Firefox and Chrome. Agree with @nickform on the reason that is the case on localhost.

[ShivanKaul]

@aspiers or anyone else, could you confirm if Shields down or turning off adblocking in general helped with extensions connecting to locahost?

[aspiers]

Sorry I can't; I stopped using Brave a while back.

[ShivanKaul]

I went through the extensions listed here:

1. https://github.com/danhper/atomic-chrome/ doesn't have a valid Chrome Web Store link any more.
2. https://github.com/stsquad/emacs_chrome/ doesn't have a valid Chrome Web Store link any more.
3. https://ghosttext.fregante.com/ works correctly on Brave on the troubleshooting page: https://ghosttext.fregante.com/troubleshooting/

We have been blocking localhost connections using adblock, and adblock doesn't apply to extensions unless you manually turn on brave://flags/#brave-extension-network-blocking. So this is definitely unexpected behaviour, but given that I'm unable to repro, I'm going to close this out. Please let us know if you run into any other extensions that don't work on Brave because of localhost connection issues.