onRequest is using ChannelWrapper.matches which is not matching ftp. This is verified, investigating more.

ChannelWrapper is used throughout webext APIs and it requires a channel to support weakref.
FTPChannel did not, thus ftp requests did not go through proxy.onRequest.

Bug 1525447 regressed proxy.register so ftp urls will not work. The regression starts with 67.

Tracking 68 as this is blocking bug 1545411 which targets 68. Too late to fix in 67 as we already built RC2, so marking as wontfix for 67. Shane if you feel that this should be a dot release driver post 67 or a strong candidate for a ride-along, please tell me, thanks.

Pascal: Can we make this a ride-along for 67? I'm not sure how to mark the bug for that.

I'm going to have to request uplift to 68 since it's landing on 69.

https://hg.mozilla.org/mozilla-central/rev/c50b4c90d56a

Comment on attachment 9065543 [details]
Bug 1552248 support ftp channel in proxy api

Beta/Release Uplift Approval Request

• User impact if declined: ftp requests no longer go through the proxy api
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce: The automated tests should be enough, but you can produce a simple extension based on the test added in the patch to test that ftp will proxy. You'll need access to an ftp proxy server.
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The running code change here simply adds the nsISupportsWeakReference interface to the ftp channel. This enables an ftp request to be used within the extension ChannelWrapper, allowing the request to work again in proxy and some limited webrequest APIs (which was also broke when we introduced ChannelWrapper).
• String changes made/needed: none

Comment on attachment 9065543 [details]
Bug 1552248 support ftp channel in proxy api

approved for 68.0b4.

https://hg.mozilla.org/releases/mozilla-beta/rev/8e0d5b9e2749

Considering that Firefox 67 is only on release for just over a week (before being replaced with 68), it's probably safe to assume that this won't be considered for a ride-along on 67 any more. This is already reflected in the bug flags, so removing the ni.