New issue
Advanced search Search tips

Issue 883274 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 64100
Owner: ----
Closed: Dec 14
Cc:
Components:
EstimatedDays: ----
NextAction: 2018-12-14
OS: Linux , Windows , Chrome , Mac
Pri: 2
Type: Feature



Sign in to add a comment

Extensions API should implement manifest.json/protocol_handlers

Reported by li...@protocol.ai, Sep 12

Issue description

UserAgent: Mozilla/5.0 (X11; Linux x86_64; rv:62.0) Gecko/20100101 Firefox/62.0

Steps to reproduce the problem:
The UX for registering redirect-based support for a new protocol via browser extension  is quite  bad right now.

Take a look at a simplified flow:
1. user installs extension to support protocol `foo://`, but it is not enough to open `foo://bar`
2. user needs to manually visit an arbitrary website (extension can open it on install, but people hate popups and close them before they load)
3. website calls `navigator.registerProtocolHandler` to register itself as redirect-based handler for the `foo://` protocol
4. browser displays [permission prompt](https://www.w3.org/TR/2013/CR-html5-20130806/images/sample-content-handler-registration.png)
5. user needs to manually accept website for handling  URLs with new protocol
6. finally, if all the above went ok, user can open `foo://bar`

What is the expected behavior?
Installation of extension should be equal to registering protocol handler. There is no reason to bother users with additional steps. 

Prior art for solving this exists, Firefox supports registering redirect-based protocol handlers via a key in extension's  manifest.json:

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/manifest.json/protocol_handlers

What went wrong?
User has to not only install browser extension but also go over elaborate steps to enable protocol handler via navigator.registerProtocolHandler. This is a bad UX and blocks further adoption of custom  protocol schemes.

A related comment can be found at: 
https://github.com/arewedistributedyet/arewedistributedyet/issues/23#issuecomment-412892777

Did this work before? N/A 

Chrome version: <Copy from: 'about:version'>  Channel: n/a
OS Version: 
Flash Version: 

This is a part of http://arewedistributedyet.com endeavor:

registerProtocolHandler's support for decentralized protocols is tracked in:
https://bugs.chromium.org/p/chromium/issues/detail?id=651311

safelisting DWeb protocols in HTML Spec is tracked in:
https://github.com/whatwg/html/issues/3935

Intent to Implement and Ship: Additional safelisted schemes for "registerProtocolHandler":
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/29sFh4tTdcs
 
Components: Platform>Extensions
Labels: Needs-Milestone
Labels: OS-Chrome OS-Mac OS-Windows
Cc: swarnasree.mukkala@chromium.org
Labels: Target-73 Triaged-ET FoundIn-72 M-73 FoundIn-71 FoundIn-70 FoundIn-73
Status: Untriaged (was: Unconfirmed)
Thanks for filing the issue...

As per comment#0 it seems to be a feature request, hence marking it as untraige and requesting someone from the dev team to look into the issue.
Cc: rdevlin....@chromium.org
NextAction: 2018-12-14
Is this significantly different from issue 64100?  Or can we merge it in?
The only difference here is that this issue is more actionable: it suggests implementation of API that already exists in Firefox. 
I'd merge 64100 into this one instead. 
We typically merge into either the first filed or the issue with the most context.  These have about the same level of context (though I agree this has an actionable proposal), but the other is far older.

What about merging into 64100, and carrying over the proposal as a comment?
The NextAction date has arrived: 2018-12-14
Mergedinto: 64100
Status: Duplicate (was: Untriaged)

Sign in to add a comment