1750572 - Firefox manual proxy settings overwrite proxy.onRequest {type: "direct"} response

Status: RESOLVED INVALID

(WebExtensions :: Request Handling, defect)

Description

[firefox4ever]

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

Steps to reproduce:

1. Set firefox proxy settings to any valid proxy (for example socks://127.0.0.1:9150)
2. Addon in proxy.onRequest must return direct connection response:

{
    type: "direct"
}

Actual results:

All requests go through socks proxy 127.0.0.1:9150 instead of direct connection.

Expected results:

All requests must go through direct connection.

System Windows 10, all latest firefox versions are affected (release, beta, esr)

Comment 1

[Luca Greco [:rpl] [:luca] [:lgreco]]

From what I recall this is the expected behavior, the explicit user choice made by overriding explicitly the Firefox proxy settings gets a higher priority of the one managed by the extensions through the browser.proxy.onRequest API event.

The extension can use browser.proxy.settings API (https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/proxy/settings) to check if the manual proxy is being used (as well as monitoring those settings for changes using onChanged API event).

Setting dev-docs-needed to update the docs to point out more clearly the expected behavior when the user has explicitly configured the proxy manually.

Comment 2

[firefox4ever]

Direct connection is a direct connection - it does not fallback to firefox settings.
If this is feature not a bug, but this is definitely a bad design.

And what is the sense of such proxy api, if add-on can't change proxy options (choosing a direct connection) for specified request?
Add-on can check if manual proxy is used, but add-on MUST NOT change firefox settings.
Also with such behavior type: "direct" is the same as returning the an empty object - fallback to current firefox settings.

Typical example when this feature is needed - proxy per container add-on. When default settings set to manual proxy for security reasons (all third party add-on requests must go through proxy set in firefox settings) and only one container must go using direct connection.

Comment 3

[Rob Wu [:robwu]]

The implementation treats DIRECT as "whatever are the default proxy settings": https://searchfox.org/mozilla-central/rev/72c7cef167829b6f1e24cae216fa261934c455fc/toolkit/components/extensions/ProxyChannelFilter.jsm#223-225

There is also logic that treats null (which is distinct from undefined) as DIRECT regardless of the default proxy settings: https://searchfox.org/mozilla-central/rev/72c7cef167829b6f1e24cae216fa261934c455fc/toolkit/components/extensions/ProxyChannelFilter.jsm#380-383,417-423

That behavior is not documented though.

Comment 4

[firefox4ever]

So if I want to to a direct connection from my addon, I have to return null not {type: "direct"}, right?
Or it's impossible to use direct connection in add-on if proxy settings was set to manual proxy?

Comment 5

[firefox4ever]

So what is the right return from the listener for this situations:

• when current firefox settings must be used
• when direct connection must be used

As I understand for the first variant null must be returned, for the second - undefined. If it's right, I can't understand meaning on the {type: "direct"} response

Comment 6

[firefox4ever]

(In reply to Rob Wu [:robwu] from comment #3)

The implementation treats DIRECT as "whatever are the default proxy settings": https://searchfox.org/mozilla-central/rev/72c7cef167829b6f1e24cae216fa261934c455fc/toolkit/components/extensions/ProxyChannelFilter.jsm#223-225

There is also logic that treats null (which is distinct from undefined) as DIRECT regardless of the default proxy settings: https://searchfox.org/mozilla-central/rev/72c7cef167829b6f1e24cae216fa261934c455fc/toolkit/components/extensions/ProxyChannelFilter.jsm#380-383,417-423

That behavior is not documented though.

Thank you for your response!

I have one more question. Will this undocumented behavior stay as-is or will be changed in the nearest future?

P.S. But I still don't understand why such type of response was named DIRECT, because it has nothing with a direct connection :(

Comment 7

[Rob Wu [:robwu]]

(In reply to firefox4ever from comment #6)

I have one more question. Will this undocumented behavior stay as-is or will be changed in the nearest future?

We have put a dev-doc-needed keyword on this bug, because we intended to document this fallover logic.

P.S. But I still don't understand why such type of response was named DIRECT, because it has nothing with a direct connection :(

Extensions usually use proxy.onRequest to define a custom proxy, and use "DIRECT" with the intention to not use the extension-specific proxy. Usually, the default behavior is to make a direct request. Sometimes the user configures the default proxy, because that is the desired or even only way to get some connection at all.

Comment 8

[firefox4ever]

(In reply to Rob Wu [:robwu] from comment #7)

(In reply to firefox4ever from comment #6)
Extensions usually use proxy.onRequest to define a custom proxy, and use "DIRECT" with the intention to not use the extension-specific proxy. Usually, the default behavior is to make a direct request. Sometimes the user configures the default proxy, because that is the desired or even only way to get some connection at all.

Understand.

So returning underfined or {type: "direct"} is to fallback to firefox setting. Null is for the real direct (no proxy) connection. Right?

Comment 9

[Richard Bloor]

Documentation updated in Clarify proxy.ProxyInfo type direct #12126.

Comment 10

[Rob Wu [:robwu]]

Thanks!

Comment 12

[Luke Crouch [:groovecoder]]

Re-visiting this and https://bugzilla.mozilla.org/show_bug.cgi?id=1750561#c4 ... how does an extension return a proxy object to say:

"Try this proxy ONLY. If it fails, don't fail over at all: Just drop the request."