Closed Bug 1310427 Opened 8 years ago Closed 7 years ago

protocol handlers (for mailto etc)

Categories

(WebExtensions :: Untriaged, defect)

50 Branch
defect
Not set
normal

Tracking

(firefox54 fixed)

RESOLVED FIXED
mozilla54
Tracking Status
firefox54 --- fixed
webextensions +

People

(Reporter: noitidart, Assigned: mixedpuppy)

References

(Depends on 1 open bug)

Details

(Keywords: dev-doc-complete, Whiteboard: triaged)

Attachments

(2 files)

Hi all, I know there have been requests to the Firefox addon devs on what you need to port to webext.

I have a featured addon - https://addons.mozilla.org/en-US/firefox/addon/mailtowebmails/

It lists all the handlers for a protocol (mailto:) and allows installing more and changing the active handler.

I plan to use native messaging to get the system software like Outlook, Apple mail, and offer to the users to install that.

Right now with webext, if i want to install a mailto handler say for example to "hotmail.com". I have to first open hotmail.com tab and inject content script, as registering webmail protocol handler needs same domain. From webext I need to get around that (as in bootstrap) - https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler
Component: Untriaged → WebExtensions: Untriaged
Product: Firefox → Toolkit
Whiteboard: [design-decision-needed] triaged
I think this is a dupe of bug 1271553.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
Yep looks like it, thanks!
Since bug 1271533 has grown into a large conversation around handling protocols, I'm reopening this bug to deal specifically with the simple case of handling protocols, such as what nav.registerProtocolHandler [RPH] provides.

However, rather than supporting the navigator api this will implement the internal hooks used by RPH.  This allows us to ensure that the protocol handler is unregistered if the addon is disabled or uninstalled.  The user experience will be the same.

- permission dialog may/will have the protocol handler listed, rather than a prompt during registration
- user will have to choose that protocol handler in the standard dialog same as with RPH (nothing we have to do in this patch to get this)
- user has the option to make it default and avoid being asked again (nothing we have to do in this patch to get this)

This will allow an addon to register a page that handles a protocol.  That page may do additional processing then redirect if that is desired.

I will move the patch I've attached to bug 1271533 to this bug.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Summary: WebExtension Expermeint feature request - protocol handlers (for mailto etc) → protocol handlers (for mailto etc)
Argh.  Above comment is supposed to say bug 1271553
Assignee: nobody → mixedpuppy
webextensions: --- → +
Comment on attachment 8833708 [details]
Bug 1310427 support protocol handlers,

https://reviewboard.mozilla.org/r/109888/#review114282

::: toolkit/components/extensions/ext-handlers.js:9
(Diff revision 1)
> +  if (!extension.permissions.has("protocol_handler")) {
> +    return;
> +  }

We don't normally have both a manifest property and a permission. The manifest property serves as the permission.

::: toolkit/components/extensions/ext-handlers.js:20
(Diff revision 1)
> +    let eps = Cc["@mozilla.org/uriloader/external-protocol-service;1"]
> +                .getService(Ci.nsIExternalProtocolService);

Please use `defineLazyServiceGetter` for this.

::: toolkit/components/extensions/ext-handlers.js:25
(Diff revision 1)
> +    let hs = Cc["@mozilla.org/uriloader/handler-service;1"]
> +               .getService(Ci.nsIHandlerService);

And this.

::: toolkit/components/extensions/ext-handlers.js:36
(Diff revision 1)
> +
> +extensions.on("shutdown", (type, extension) => {
> +  if (!handlers.has(extension)) {
> +    return;
> +  }
> +  for (let handlerConfig of handlers.get(extension)) {

I'm pretty sure we don't want to do any of this at app shutdown.

::: toolkit/components/extensions/ext-handlers.js:43
(Diff revision 1)
> +                .getService(Ci.nsIExternalProtocolService);
> +    let protoInfo = eps.getProtocolHandlerInfo(handlerConfig.protocol);
> +    let appHandlers = protoInfo.possibleApplicationHandlers;
> +    for (let i = 0; i < appHandlers.length; i++) {
> +      try {
> +        let handler = appHandlers.queryElementAt(i, Ci.nsIWebHandlerApp);

let handler = appHandlers.queryElementAt(i, Ci.nsISupports);
    if (handler instanceof Ci.nsIWebHandlerApp) {
      ...

::: toolkit/components/extensions/ext-handlers.js:44
(Diff revision 1)
> +    let protoInfo = eps.getProtocolHandlerInfo(handlerConfig.protocol);
> +    let appHandlers = protoInfo.possibleApplicationHandlers;
> +    for (let i = 0; i < appHandlers.length; i++) {
> +      try {
> +        let handler = appHandlers.queryElementAt(i, Ci.nsIWebHandlerApp);
> +        if (handler && handler.uriTemplate == handlerConfig.uriTemplate) {

s/==/===/

::: toolkit/components/extensions/ext-handlers.js:46
(Diff revision 1)
> +    for (let i = 0; i < appHandlers.length; i++) {
> +      try {
> +        let handler = appHandlers.queryElementAt(i, Ci.nsIWebHandlerApp);
> +        if (handler && handler.uriTemplate == handlerConfig.uriTemplate) {
> +          appHandlers.removeElementAt(i);
> +          if (protoInfo.preferredApplicationHandler == handler) {

s/==/===/

::: toolkit/components/extensions/ext-handlers.js:52
(Diff revision 1)
> +            protoInfo.preferredApplicationHandler = null;
> +            protoInfo.alwaysAskBeforeHandling = true;
> +          }
> +          break;
> +        }
> +      } catch (e) { continue; }

Please don't eat arbitrary errors.

::: toolkit/components/extensions/ext-handlers.js:56
(Diff revision 1)
> +        }
> +      } catch (e) { continue; }
> +    }
> +    let hs = Cc["@mozilla.org/uriloader/handler-service;1"]
> +               .getService(Ci.nsIHandlerService);
> +    hs.store(protoInfo);

We should only be doing this when we remove an element.

::: toolkit/components/extensions/schemas/extension_handler.json:21
(Diff revision 1)
> +        }]
> +      },
> +      {
> +        "$extend": "WebExtensionManifest",
> +        "properties": {
> +          "handlers": {

"handlers" is a weird name for this. Handlers for what?

::: toolkit/components/extensions/schemas/extension_handler.json:27
(Diff revision 1)
> +                "name": {"type": "string"},
> +                "protocol": {"type": "string"},
> +                "uriTemplate": {"type": "string"}

Please add descriptions for these properties, and the manifest property itself.

::: toolkit/components/extensions/test/mochitest/mochitest-common.ini:69
(Diff revision 1)
>  [test_ext_exclude_include_globs.html]
>  [test_ext_i18n_css.html]
>  [test_ext_generate.html]
>  [test_ext_notifications.html]
>  [test_ext_permission_xhr.html]
> +[test_ext_rph.html]

Please give this a less cryptic name.

::: toolkit/components/extensions/test/mochitest/test_ext_rph.html:63
(Diff revision 1)
> +    const {classes: Cc, interfaces: Ci, utils: Cu, results: Cr} = Components;
> +
> +    const protoSvc = Cc["@mozilla.org/uriloader/external-protocol-service;1"]
> +                       .getService(Ci.nsIExternalProtocolService);
> +    let protoInfo = protoSvc.getProtocolHandlerInfo("foo");
> +    sendAsyncMessage("preferredAction", protoInfo.preferredAction == protoInfo.useHelperApp);

You can use `assert.equal(...)` (and so forth) here.

::: toolkit/components/extensions/test/mochitest/test_ext_rph.html:78
(Diff revision 1)
> +  ok(yield chromeScript.promiseOneMessage("preferredAction"), "using a helper application is the preferred action");
> +  ok(yield chromeScript.promiseOneMessage("preferredApplicationHandler"), "no preferred handler is set");
> +  is(yield chromeScript.promiseOneMessage("handlers"), 1, "one handler is set");
> +  ok(yield chromeScript.promiseOneMessage("isWebHandler"), "the handler is a web handler");
> +  is(yield chromeScript.promiseOneMessage("uriTemplate"), `${handlerUrl}?val=%s`, "correct url template");

Can we just send an object with all of these properties rather than a bunch of separate messages?

Incidentally, doing it this way is pretty racy. The chrome script code doesn't buffer messages, so if you don't call `promiseOneMessage` before the message arrives, it gets lost.

::: toolkit/components/extensions/test/mochitest/test_ext_rph.html:106
(Diff revision 1)
> +  });
> +
> +  ok(yield chromeScript.promiseOneMessage("preferredApplicationHandler"), "no preferred handler is set");
> +  is(yield chromeScript.promiseOneMessage("handlers"), 0, "no handler is set");
> +  chromeScript.destroy();
> +});

We should try to test that we don't unset the default handler when the app restarts.
Attachment #8833708 - Flags: review?(kmaglione+bmo)
Comment on attachment 8833708 [details]
Bug 1310427 support protocol handlers,

https://reviewboard.mozilla.org/r/109888/#review114282

> We should try to test that we don't unset the default handler when the app restarts.

It only gets unset if the addon is disabled/uninstalled and it's handler was default.  At that point the user will have to pick a new default via the dialog if they use protocol again.
Drive-by comment: this seems like something that warrants a permission prompt.  Since it uses a manifest property instead of a permission, you need to modify `ExtensionData.userPermissions()` and choose a name that won't conflict with any "real" permission names, then add an appropriate string to browser.properties.
FYI, the FoxyProxy legacy addon installs its own proxy: protocol handler, so its port to WebExtensions will require this support. Clicking a hyperlink on a page with the proxy: URL enables users to auto-configure proxies with a single-click (after confirming the change in a gBrowser.getNotificationBox())
Whiteboard: [design-decision-needed] triaged → triaged
Comment on attachment 8833708 [details]
Bug 1310427 support protocol handlers,

https://reviewboard.mozilla.org/r/109888/#review115678

::: toolkit/components/extensions/Extension.jsm:389
(Diff revision 5)
> +    if (Array.isArray(this.manifest.protocol_handlers)) {
> +      result.permissions.push("protocolHandlers");
> +    }

Hrm. So, normally we'd call call this permission "manifest:protocol_handlers", which is how the `hasPermission` method handles it. But property files treat ":" the same way they treat "=", so that won't work.

But if we're going to go this route, I'd rather add all manifest keys that act as permissions to the permissions list rather than doing the check in `hasPermission`, and then have the permissions UI code do whatever mangling is necessary to get the right string bundle key.

::: toolkit/components/extensions/ext-protocolHandlers.js:18
(Diff revision 5)
> +const whitelist = ["bitcoin", "geo", "im", "irc", "ircs", "magnet", "mailto",
> +                   "mms", "news", "nntp", "sip", "sms", "smsto", "ssh", "tel",
> +                   "urn", "webcal", "wtai", "xmpp"];

Please use a `Set` for this.

::: toolkit/components/extensions/ext-protocolHandlers.js:38
(Diff revision 5)
> +    if (!whitelist.includes(handlerConfig.protocol) &&
> +        !handlerConfig.protocol.startsWith("web+") &&
> +        !handlerConfig.protocol.startsWith("ext+")) {
> +      Cu.reportError("Unable to register non-whitelisted protocol scheme.");

We should handle this in the schema instead, so the reported error is easier to identify.

::: toolkit/components/extensions/schemas/extension_protocol_handlers.json:1
(Diff revision 5)
> +// Copyright (c) 2012 The Chromium Authors. All rights reserved.
> +// Use of this source code is governed by a BSD-style license that can be
> +// found in the LICENSE file.

Please remove.
Attachment #8833708 - Flags: review?(kmaglione+bmo)
Bah, mozreview. Close this time, just a couple of concerns about validation and permission handling.
(In reply to Kris Maglione [:kmag] from comment #14)
> ::: toolkit/components/extensions/Extension.jsm:389
> (Diff revision 5)
> > +    if (Array.isArray(this.manifest.protocol_handlers)) {
> > +      result.permissions.push("protocolHandlers");
> > +    }
> 
> Hrm. So, normally we'd call call this permission
> "manifest:protocol_handlers", which is how the `hasPermission` method
> handles it. But property files treat ":" the same way they treat "=", so
> that won't work.
> 
> But if we're going to go this route, I'd rather add all manifest keys that
> act as permissions to the permissions list rather than doing the check in
> `hasPermission`, and then have the permissions UI code do whatever mangling
> is necessary to get the right string bundle key.

This feels like a separate bug, can we do a followup on the permissions system for that?
Flags: needinfo?(kmaglione+bmo)
(In reply to Shane Caraveo (:mixedpuppy) from comment #16)
> This feels like a separate bug, can we do a followup on the permissions
> system for that?

I'd rather not land this with it adding an artificial "protocolHandlers" permission, especially if we're also adding a locale string for it at the same time.
Flags: needinfo?(kmaglione+bmo)
Comment on attachment 8833708 [details]
Bug 1310427 support protocol handlers,

https://reviewboard.mozilla.org/r/109888/#review116154

::: toolkit/components/extensions/ext-protocolHandlers.js:33
(Diff revision 6)
> +/* eslint-disable mozilla/balanced-listeners */
> +extensions.on("manifest_protocol_handlers", (type, directive, extension, manifest) => {
> +  for (let handlerConfig of manifest.protocol_handlers) {
> +    handlerConfig.uriTemplate = extension.baseURI.resolve(handlerConfig.uriTemplate);
> +    let url = new URL(handlerConfig.uriTemplate);
> +    if (!["http:", "https:", "moz-extension:"].includes(url.protocol)) {

This should also be validated in the schema. You might need to add a new format checker for it. Possibly `choices: [ExtensionUrl, httpUrl]` or something like that.

::: toolkit/components/extensions/schemas/extension_protocol_handlers.json:25
(Diff revision 6)
> +                "mms", "news", "nntp", "sip", "sms", "smsto", "ssh", "tel",
> +                "urn", "webcal", "wtai", "xmpp"
> +              ]
> +            }, {
> +              "type": "string",
> +              "pattern": "^(ext|web)\\+.*"

s/\.\$/[a-z0-9.+-]+$/
Attachment #8833708 - Flags: review?(kmaglione+bmo)
(In reply to Kris Maglione [:kmag] from comment #18)
> (In reply to Shane Caraveo (:mixedpuppy) from comment #16)
> > This feels like a separate bug, can we do a followup on the permissions
> > system for that?
> 
> I'd rather not land this with it adding an artificial "protocolHandlers"
> permission, especially if we're also adding a locale string for it at the
> same time.

I've had second thoughts on having the permission at all.  The user will have to a) install an addon, b) click on a link with the protocol, c) select the addon in a dialog to handle the protocol, and possibly c2) select it to be default.

Because of step c, it feels unnecessary to deal with the permission hurdle right now.  If we add a way to make a default protocol, then we will definitely need to deal with the permission, in which case an explicit permission (as was originally done) may be better.
Comment on attachment 8833708 [details]
Bug 1310427 support protocol handlers,

https://reviewboard.mozilla.org/r/109888/#review115678

> Hrm. So, normally we'd call call this permission "manifest:protocol_handlers", which is how the `hasPermission` method handles it. But property files treat ":" the same way they treat "=", so that won't work.
> 
> But if we're going to go this route, I'd rather add all manifest keys that act as permissions to the permissions list rather than doing the check in `hasPermission`, and then have the permissions UI code do whatever mangling is necessary to get the right string bundle key.

Skipping on a permission per comment in bug.
See Also: → 1342133
Comment on attachment 8833708 [details]
Bug 1310427 support protocol handlers,

https://reviewboard.mozilla.org/r/109888/#review116626

r=me with issues fixed.

::: toolkit/components/extensions/schemas/extension_protocol_handlers.json:30
(Diff revision 8)
> +              "pattern": "^(ext|web)\\+[a-z0-9.+-]+$"
> +            }]
> +          },
> +          "uriTemplate": {
> +            "description": "The URL of the handler, as a string. This string should include \"%s\" as a placeholder which will be replaced with the escaped URL of the document to be handled. This URL might be a true URL, or it could be a phone number, email address, or so forth.",
> +            "type": "string",

"type" and "choices" are mutually exclusive.

::: toolkit/components/extensions/schemas/manifest.json:230
(Diff revision 8)
>        },
>        {
> +        "id": "HttpURL",
> +        "type": "string",
> +        "format": "url",
> +        "pattern": "^(https?)://.*$",

No need for parens.

::: toolkit/components/extensions/schemas/manifest.json:231
(Diff revision 8)
>        {
> +        "id": "HttpURL",
> +        "type": "string",
> +        "format": "url",
> +        "pattern": "^(https?)://.*$",
> +        "preprocess": "localize"

This should be on the property itself, not the base type.

::: toolkit/components/extensions/test/mochitest/test_ext_protocolHandlers.html:26
(Diff revision 8)
> +    manifest: {
> +      "protocol_handlers": [
> +        {
> +          "protocol": "ext+foo",
> +          "name": "a foo protocol handler",
> +          "uriTemplate": "foo.html?val=%s",

Need to test that this works with http: and https: URLs too.

::: toolkit/components/extensions/test/mochitest/test_ext_protocolHandlers.html:137
(Diff revision 8)
> +  let loaded = yield extension.startup().then(() => {
> +    extension.unload();
> +    return true;
> +  }).catch(() => {
> +    return false;
> +  });

`yield Assert.rejects(extension.startup(), ...)`

::: toolkit/components/extensions/test/mochitest/test_ext_protocolHandlers.html:151
(Diff revision 8)
> +          "protocol": "http",
> +          "name": "take over the http protocol",

This should be a valid protocol so we're actually testing the `uriTemplate`. Would be good to also test the error message.

::: toolkit/components/extensions/test/mochitest/test_ext_protocolHandlers.html:160
(Diff revision 8)
> +  let loaded = yield extension.startup().then(() => {
> +    extension.unload();
> +    return true;
> +  }).catch(() => {
> +    return false;
> +  });
> +  ok(!loaded, "unable to register restricted handler uriTemplate");

Same here.
Attachment #8833708 - Flags: review?(kmaglione+bmo) → review+
Depends on: 1342577
Pushed by archaeopteryx@coole-files.de:
https://hg.mozilla.org/integration/autoland/rev/975fd16eef79
support protocol handlers: disable test on Android (bug 1342577). r=test-disabling-to-fix-orange-as-requested-by-developer
https://hg.mozilla.org/mozilla-central/rev/704db7ae2d85
https://hg.mozilla.org/mozilla-central/rev/975fd16eef79
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla54
Keywords: dev-doc-needed
-> https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/protocol_handlers

Please let me know if we need anything else.
Flags: needinfo?(mixedpuppy)
WTF. I just read the documentation and I should have commented on the patch.

I need this for a gopher extension, and gopher isn't one of the whitelisted protocols. Why is that? Why do we have a whitelist at all?

Can a followup patch be made to at least whitelist "gopher" as well?
For that matter, FoxyProxy also needs proxy:. So this list is going to fail from the beginning.
(In reply to Will Bamberg [:wbamberg] from comment #29)
> ->
> https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/
> protocol_handlers
> 
> Please let me know if we need anything else.

It's missing that you can also use protocols such as web+foo: and ext+foo:.  nav.registerProtocolHandler supports web+foo, we should document the preference for addons to use ext+foo.
Flags: needinfo?(mixedpuppy)
For others reading and commenting now, please comment on new bugs or other bugs related to protocol handlers.

This bug is about supporting nav.registerProtocolHandler (RPH) in a fashion that works well for extensions.  

RPH is limited to a list of protocols and documented that way.  Since this shares the same backend as RPH, we enforce the same limitations.

If you're addon is using RPH you're already forced into the same whitelist.  If you're addon is implementing protocols another way, then this mechanism likely wont work for you anyway (regardless of whitelist).
(In reply to Shane Caraveo (:mixedpuppy) from comment #32)
> 
> It's missing that you can also use protocols such as web+foo: and ext+foo:. 
> nav.registerProtocolHandler supports web+foo, we should document the
> preference for addons to use ext+foo.

Thanks Shane, I've made that change.
Then this is essentially useless for me to reimplement OverbiteFF if there's going to be no mechanism for defining additional schemes (it uses "gopher://" URLs). If all this does is inherit the limitations of navigator.registerProtocolHandler, then I predict pretty much no one is going to use this for webextensions either. About the only extension use case this covers is Chatzilla because it does at least have IRC.

Similarly, FoxyProxy above needs "proxy:" and there are several Telnet extensions that implement "telnet://". This won't help them either.

If this is preferred, I can open a bug to discuss whitelisting additional schemes, but without that I have no use for this myself.
This is just sugar-coating nav.registerProtocolHandler

There is a separate ticket for adding more advanced programmable custom protocol handler WebExtension API:
https://bugzilla.mozilla.org/show_bug.cgi?id=1271553

I feel that use cases that are not covered by default behavior of registerProtocolHandler should be described there.
(In reply to Cameron Kaiser [:spectre] from comment #35)
> If this is preferred, I can open a bug to discuss whitelisting additional
> schemes, but without that I have no use for this myself.

If the UX that RPH has is fine for your use cases, add a bug for the protocols you want whitelisted and they can be considered.
(In reply to Cameron Kaiser [:spectre] from comment #35)
> Then this is essentially useless for me to reimplement OverbiteFF if there's
> going to be no mechanism for defining additional schemes (it uses "gopher://" URLs).

That's the least of it. A WebExtension can't open a socket, so you can't implement an application layer protocol as a WebExtension. You can redirect to a (http:) gopher proxy; otherwise RIP, OverbiteFF. 

In re the scheme name: `navigator.registerProtocolHandler` has (had?) both a blacklist and a whitelist, but only the blacklist is active by default. That is, any website can still do this in FF52:

`window.navigator.registerProtocolHandler("gopher", location.origin + "/mn/gopher/%s", "gopher: protocol handler");`

The manifest whitelist is an additional constraint imposed on WebExtensions. Had Shane followed Chrome's lead then WebExtensions would register handlers the same way as websites, but without the cross-site restriction. Even then you'd only be able to redirect gopher: to a web proxy.
(In reply to Nancy Grossman from comment #38)
> The manifest whitelist is an additional constraint imposed on WebExtensions.
> Had Shane followed Chrome's lead then WebExtensions would register handlers
> the same way as websites, but without the cross-site restriction. Even then
> you'd only be able to redirect gopher: to a web proxy.

It's not an additional constraint.  As I said earlier, it's the same constraint documented for registerProtocolHandler here:

https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler

as well as here:

https://html.spec.whatwg.org/multipage/webappapis.html#dom-navigator-registerprotocolhandler

The whatwg spec also has an interesting comment specifically about gopher.

As I also stated in comment 37, add a bug if you want another protocol allowed and I'll ask someone (in security) to evaluate whether it is an issue.

Addons are free to add a website as the handler.  Per the schema for the api, both extension urls and http urls are allowed, so there is no cross-site restriction.  For example, an addon can add a web handler for mailto.
(In reply to Shane Caraveo (:mixedpuppy) from comment #39)
> It's not an additional constraint.

I couldn't have been clearer, Shane: Any website can register `gopher` as a protocol, no WebExtension can do that, and the reason is your manifest check. So yes, the manifest imposes an additional constraint on WebExtensions. I wonder why you didn't try it yourself before you replied.
(In reply to Nancy Grossman from comment #40)
> (In reply to Shane Caraveo (:mixedpuppy) from comment #39)
> > It's not an additional constraint.
> 
> I couldn't have been clearer, Shane: Any website can register `gopher` as a
> protocol, no WebExtension can do that, and the reason is your manifest
> check. So yes, the manifest imposes an additional constraint on
> WebExtensions. I wonder why you didn't try it yourself before you replied.

You're welcome to provide an explanation why the nav.rph implementation is correct and the docs on that api are wrong (because one or the other is indeed wrong).  That would help inform decisions around making changes.
(In reply to Nancy Grossman from comment #38)
> Even then
> you'd only be able to redirect gopher: to a web proxy.

True, and clearly suboptimal, but using a proxy was indeed how the Overbite extension for Chrome worked. Obviously resurrecting that approach would merely be a stopgap until the networking case was fixed (that's bug 1247628), but that's something I can live with for an interim period. However, I can't implement *any* sort of extension without a protocol handler.
Currently though you *can* register `gopher` as a protocol handler from a website. So, extension sends user to website, website tries to register a handler page for `gopher:` as above, fails on Chrome, succeeds (if permitted) on Firefox. All `gopher:` links then redirect to the website's handler, or the extension can redirect the request somewhere else in a blocking `webRequest.onBeforeRequest` listener if you want to support 2+ proxies. More like an app than an extension, really.
Something like that is what I envision at least temporarily, but I still want it to be as close as possible to what it is now (right now OverbiteFF actually implements nsIChannel, so it's a first-class citizen -- I won't get that anymore, but direct socket access through a protocol handler would still be the best I could get under the circumstances). I suspect I'm hardly the only extension author in that boat.

Besides, being able to register from a website remotely but not through WX locally doesn't really make any sense.
I haven't heard word if the spec is going to be changed. I'd be happy to submit the trivial patch to whitelist gopher, but not if it's not going to be accepted before the spec is updated.
I attempted to write a proxy-based version of OverbiteFF as a stopgap (comment 44 and comment 45); neither hooking the omnibox nor hooking onBeforeNavigate was able to intercept the protocol before the browser did. Trivial patch to whitelist gopher (to be consistent with what navigator.registerProtocolHandler supports now) coming up. Without this, I can't convert to WebExtensions.
(FTR, I just tried on nightly, and this URL - http://gopher.floodgap.com/gopher/proxy.html - does indeed properly register itself as a Gopher protocol handler.)
Attachment #8891203 - Flags: review?(mixedpuppy) → review+
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Lack of coffee.  Cameron, please create a new bug, attach the patch there and r? me.  I'm fine accepting this in that case.
Flags: needinfo?(spectre)
Done (bug 1385357).
Flags: needinfo?(spectre)
See Also: → 1451983
See Also: → 1356397
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.