New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 51 users
Status: Archived
Owner: ----
Closed: Mar 2017
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

issue 333943

Sign in to add a comment
add extension and app support for registerProtocolHandler and registerContentHandler
Project Member Reported by, Jun 14 2011 Back to list
With Chrome 13, we're now shipping initial support for registerProtocolHandler.  When used, it infobars the user to enable.  We should add declarative support for this to the manifest so that the handler is registered at install time and doesn't require an infobar.

For hosted apps, this should require that the handler URL pattern is in the app's extent.  For packaged apps, we should require that the app have host permission.

See  bug 11359  for details.  Note registerContentHandler hasn't yet landed.

Comment 1 by, Jun 15 2011
Note that as an alternative to registerContentHandler we currently support a way for NaCl plugins to register themselves as handlers for MIME types (see r80888)
Comment 2 by, Jun 28 2011
Status: Started
Comment 3 by, Jun 28 2011
Imperative support is not here yet; I think it's tracked in bug 73710:

Uncaught TypeError: Object #<Navigator> has no method 'registerProtocolHandler'

Support currently exists for reading it from Preferences e.g. chrome/test/data/profiles/custom_handlers/Default/Preferences (but I don't see an infobar). Are there currently any other ways to register protocol handlers?
Comment 4 by, Jun 28 2011
benwells came by to talk about this.

Clarification: imperative support doesn't work on Linux.

There are potential sync issues. Some months ago folks decided that protocol handlers should *not* be synced. But if we sync an app which registers a protocol handler, presto, that protocol handler is synced.
I don't see any reason why we shouldn't sync it for apps/extensions.
Per abarth's feedback, we don't really need to have host permissions for packaged apps or extensions, so let's skip that requirement.
Comment 7 by, Jun 29 2011
Suppose one day I find my mailto: links start being redirected, and I dislike it. With a hosted app it'd obvious by the destination, but with extensions/packaged apps, any of them could be the culprit (having auto-updated).

The only way to figure out which one is to visit the somewhat obscure settings page for protocol handlers, where we display the "title" of the handler (we should make this match the name of the extension). But removing it here probably doesn't persist -- the next time the extension is loaded, it loads its handlers. Somehow, I the user have to figure out to disable the extension.
Comment 8 by, Jul 19 2011
Labels: -Mstone-14 Mstone-15
Pushing this back while sync decisions are still unresolved.
Comment 9 by, Aug 16 2011
Labels: -Mstone-15 Mstone-16
Comment 10 by, Oct 24 2011
Labels: -Mstone-16 MovedFrom-16 Mstone-17
Comment 11 by, Nov 8 2011
Labels: -Mstone-17
Owner: ----
Status: Available
 Issue 75015  has been merged into this issue.
Any chance of allowing apps to run registerProtocolHandler without the web+ prefix requirement? Without the same-domain requirement, as well.

I'd be fine as an author having my app register a prefix and point it to an http/https site.
Project Member Comment 14 by, Mar 10 2013
Labels: -Area-Internals -Feature-Apps -Feature-Extensions Cr-Platform-Extensions Cr-Platform-Apps Cr-Internals
Hello guys,

I think it's good if chrome allows registerContentHandler() in Packaged Apps.

Packaged Apps can work offline, user can invoke Packaged Apps in a normal webpage hyperlink would be useful.
Cc: a deleted user
Cc: -a deleted user
I asked a related question here

as you can see, in order to interop between normal webpage and packaged-app-only functions, you need to create *two* extensions, which is confusing.
Labels: Cr-Platform-Apps-Core
Comment 20 by, Nov 18 2013
  I've been working on ChromeOS built-in HelpApp. It used to be a component extension so we had hard-coded urls like chrome-extension://<help_app_id>/<article_id> in chromium code base which can be easily opened when offline (either by user clicking or a call to chrome::Navigate). Now we're replacing the component extension into a component packaged app. So those urls are not valid anymore.
  ProtocolHandler would be a solution to our problem. It'll be great if we can register some protocol like web+helpapp:<article_id> . Our app then render articles according to the given article id. 
  I think this feature would come in handy for third party app developers as well.

I don't think this is the right solution.  We have a way for apps to handle URL requests that they own.  Please start a thread with miket and sergeygs to get more information (not in this bug, although perhaps someone could include a link to the docs).
Blocking: chromium:333943
 Issue 347116  has been merged into this issue.
Comment 24 by, Nov 1 2014
Since there is already url_handlers and file_handlers available for chrome app manifests, it would be logical to extend this to allow also for say, protocol_handlers
Project Member Comment 27 by, Mar 9 2017
Labels: Hotlist-Recharge-Cold
Status: Untriaged
This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

For more details visit - Your friendly Sheriffbot
Status: Archived
Sign in to add a comment