Porting Proxy Extensions Between Chrome and Firefox
Firefox and Chrome expose similarly named extension APIs with different configuration models. Port the routing policy, not just the namespace.
Renaming chrome to browser is not a complete port of a proxy extension.
Chrome's fixed-server configuration uses a mode and rules object. Firefox exposes its own global proxy settings interface and a per-request proxy.onRequest API. Similar names do not make their input objects interchangeable.
Start with the policy you want to express: one fixed endpoint, a PAC configuration, or a route selected separately for each request. Then use the interface documented for each browser.
Firefox's per-request listener can return proxy information from extension code. It requires the proxy permission and the appropriate host access for intercepted requests. That is a different design from copying a Chrome fixed-server settings object and hoping the browser recognizes every field.
Check the supported Firefox version and manifest requirements as well. Old examples using proxy.register() describe an earlier API and should not be the foundation of a current extension.
Keep shared policy data separate from browser-specific adaptation. Tests and diagnostics should show the route selected for a destination in each browser, including a deliberate direct result. A valid manifest and a non-throwing API call are only the beginning.