[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
Open web leads, was there any further discussion of this? -Nick On Sun, Oct 4, 2009 at 8:33 PM, Alex faab...@mozilla.com wrote: That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? I figured I should jump into the thread since I can give some perspective on the UI from another vendor. I'm a principal designer on Firefox, and this is a feature that I'm really passionate about. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. I completely agree with the user being able to give the Web app various privileges in one shot, as opposed to having to provide permissions individually, like access to a certain amount of offline storage, local file type registration, ability to produce notifications, etc (although we will likely allow users to revoke permissions to Web apps individually). I'm concerned that the notion of installing a Web app is going to be difficult for a lot of people to wrap their head around. This somewhat implies that the Web app is going to served locally (like how Zimbra Desktop currently deploys with Mozilla's Prism). So in terms of the Firefox UI, we haven't decided on the best way to describe the action of giving a Web app additional desktop-like privileges. While we will likely have an explicit menu item, we are also considering granting these privileges implicitly when the user takes an action like dragging a tab into their OS X Dock, or Windows quick launch bar. We also may grant the Web app certain privileges in Firefox 4 when it is dragged to the left of the home tab, and now exists in a persistent state that we are referring to as an app tab. I've also been considering the value of adding an additional item to the Windows Start Menu and OS X Applications folder called Add Web Application, which would generate appropriate shortcuts, and grant the Web app additional privileges. I think conceptually this works well since the interface is placed alongside other desktop apps, however this is a bit more aggressive than Firefox usually behaves. While UA defined semantics and behaviors are of course outside of the standardization process of the API, I think the Web as a whole would benefit if we coordinated to deploy a reasonably similar interface for this functionality. -Alex Faaborg On Oct 2, 4:23 pm, Jeremy Orlow jor...@chromium.org wrote: That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? On Fri, Oct 2, 2009 at 4:11 PM, Ben Goodger (Google) b...@chromium.org wrote: This relates somewhat to how we'd like people to install web applications. For that we figured a site would publish a manifest in some format (there was some talk about something like the extensions manifest) that specifies all kinds of appy things a site can do, like large icons, protocol schemes and mime types it can handle and the URLs for each, etc etc. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. -Ben On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/02. .. I'll try to take a look at the thread some time soon. Ben and/or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
I didn't see any, but we had discussed a couple of possible ways to get there at an earlier meeting. The first was to perhaps use AppCache manifests to declare this sort of metadata. You might have some sort of header in the manifest that describes the page as persistently bless-able (much like Ben's description), followed by the list of requested permissions. UA's would fetch the AppCache, detect that it corresponds to a blessable app and handle the process of granting privs enumerated in the manifest. It'd be up to the UA to find some way to offer the ability to bless the app/page in it's UI, but in the case of Chromium you could imagine this all getting integrated into a process by which you bless an app and it asks for perms like: * app-mode desktop shortcut * location * persistent storage that's not subject to cache clearing Another way to skin the cat might be to lean on the extensions system in Chromium to build an extension automatically or for a page to reference an extension to offer. Installing the extensions might then be the way things get blessed, but that sort of seems like a question of semantics and implementation. The first way seems somewhat easier to eventually standardize and could possibly be implemented as the second under the covers. Regards On Tue, Oct 20, 2009 at 5:36 PM, Nick Baum nickb...@chromium.org wrote: Open web leads, was there any further discussion of this? -Nick On Sun, Oct 4, 2009 at 8:33 PM, Alex faab...@mozilla.com wrote: That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? I figured I should jump into the thread since I can give some perspective on the UI from another vendor. I'm a principal designer on Firefox, and this is a feature that I'm really passionate about. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. I completely agree with the user being able to give the Web app various privileges in one shot, as opposed to having to provide permissions individually, like access to a certain amount of offline storage, local file type registration, ability to produce notifications, etc (although we will likely allow users to revoke permissions to Web apps individually). I'm concerned that the notion of installing a Web app is going to be difficult for a lot of people to wrap their head around. This somewhat implies that the Web app is going to served locally (like how Zimbra Desktop currently deploys with Mozilla's Prism). So in terms of the Firefox UI, we haven't decided on the best way to describe the action of giving a Web app additional desktop-like privileges. While we will likely have an explicit menu item, we are also considering granting these privileges implicitly when the user takes an action like dragging a tab into their OS X Dock, or Windows quick launch bar. We also may grant the Web app certain privileges in Firefox 4 when it is dragged to the left of the home tab, and now exists in a persistent state that we are referring to as an app tab. I've also been considering the value of adding an additional item to the Windows Start Menu and OS X Applications folder called Add Web Application, which would generate appropriate shortcuts, and grant the Web app additional privileges. I think conceptually this works well since the interface is placed alongside other desktop apps, however this is a bit more aggressive than Firefox usually behaves. While UA defined semantics and behaviors are of course outside of the standardization process of the API, I think the Web as a whole would benefit if we coordinated to deploy a reasonably similar interface for this functionality. -Alex Faaborg On Oct 2, 4:23 pm, Jeremy Orlow jor...@chromium.org wrote: That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? On Fri, Oct 2, 2009 at 4:11 PM, Ben Goodger (Google) b...@chromium.orgwrote: This relates somewhat to how we'd like people to install web applications. For that we figured a site would publish a manifest in some format (there was some talk about something like the extensions manifest) that specifies all kinds of appy things a site can do, like large icons, protocol schemes and mime types it can handle and the URLs for each, etc etc. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. -Ben On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote:
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
On Tue, Oct 20, 2009 at 6:35 PM, Alex Russell slightly...@google.com wrote: The first was to perhaps use AppCache manifests to declare this sort of metadata. You might have some sort of header in the manifest that describes the page as persistently bless-able (much like Ben's description), followed by the list of requested permissions. UA's would fetch the AppCache, detect that it corresponds to a blessable app and handle the process of granting privs enumerated in the manifest. It'd be up to the UA to find some way to offer the ability to bless the app/page in it's UI, but in the case of Chromium you could imagine this all getting integrated into a process by which you bless an app and it asks for perms like: * app-mode desktop shortcut * location * persistent storage that's not subject to cache clearing There is a problem with leaning on app cache. We cannot grant extended permissions to resources served over plain-old HTTP because of MITM. The resources could be intercepted and malicious third parties could gain the extra permissions. This is what led to the current signed-package design of the Chromium extension system. If you really want to serve resources live (not have to package an application), then you could restrict extra permissions to apps that are served over SSL. Or perhaps extend appcache to allow signatures for each resource. Or maybe we continue to insist that we don't need or want elevated permissions for any kinds of apps. - a --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? I figured I should jump into the thread since I can provide some perspective on the UI from another vendor. I'm a principal designer on Firefox and this is a feature that I'm really passionate about. The UA would expose some way to activate all of this functionality for a site in one shot... I totally agree that users should be able to give Web apps additional privileges in one shot, as opposed to having to give them permission to do things like use offline storage, register to handle local files, and produce notifications individually (although we will likely allow users to revoke specific permissions). then a menu item in the browser might activate that the user could use to activate it. We are considering a menu item as well, however we haven't determined the best way to describe the action. I'm concerned that the term install has connotations that the Web app will actually be served locally (like how Zimbra desktop deploys with Mozilla's Prism), and a lot of users may have difficulty wrapping their head around what it literally means to install a Web app. We are also looking into granting these additional app privileges implicitly through actions that the user takes, like dragging a tab into the OS X dock or Windows quick launch bar. Additionally in Firefox 4 if the user drags a tab to the left our new Home Tab they will be able to create a small persistent tab (called an app tab) that will be automatically granted these additional privileges. A third option that I've been thinking about is adding a new item to the Windows start menu and OS X applications folder named Add Web Application. I think this works reasonably well conceptually since the app being created will ultimately be accessible next to the rest of the user's desktop applications. However, presenting UI outside of the browser is a little more aggressive than Firefox usually behaves. While UA interfaces are of course well outside of the scope of the standardization process for APIs, I think the Web as a whole would benefit if we coordinated to present a somewhat similar interface for this feature, at least in terms of terminology, any symbols used, etc. -Alex Faaborg On Oct 2, 4:23 pm, Jeremy Orlow jor...@chromium.org wrote: That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? On Fri, Oct 2, 2009 at 4:11 PM, Ben Goodger (Google) b...@chromium.orgwrote: This relates somewhat to how we'd like people to install web applications. For that we figured a site would publish a manifest in some format (there was some talk about something like the extensions manifest) that specifies all kinds of appy things a site can do, like large icons, protocol schemes and mime types it can handle and the URLs for each, etc etc. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. -Ben On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/02 ... I'll try to take a look at the thread some time soon. Ben and/ or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? I figured I should jump into the thread since I can give some perspective on the UI from another vendor. I'm a principal designer on Firefox, and this is a feature that I'm really passionate about. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. I completely agree with the user being able to give the Web app various privileges in one shot, as opposed to having to provide permissions individually, like access to a certain amount of offline storage, local file type registration, ability to produce notifications, etc (although we will likely allow users to revoke permissions to Web apps individually). I'm concerned that the notion of installing a Web app is going to be difficult for a lot of people to wrap their head around. This somewhat implies that the Web app is going to served locally (like how Zimbra Desktop currently deploys with Mozilla's Prism). So in terms of the Firefox UI, we haven't decided on the best way to describe the action of giving a Web app additional desktop-like privileges. While we will likely have an explicit menu item, we are also considering granting these privileges implicitly when the user takes an action like dragging a tab into their OS X Dock, or Windows quick launch bar. We also may grant the Web app certain privileges in Firefox 4 when it is dragged to the left of the home tab, and now exists in a persistent state that we are referring to as an app tab. I've also been considering the value of adding an additional item to the Windows Start Menu and OS X Applications folder called Add Web Application, which would generate appropriate shortcuts, and grant the Web app additional privileges. I think conceptually this works well since the interface is placed alongside other desktop apps, however this is a bit more aggressive than Firefox usually behaves. While UA defined semantics and behaviors are of course outside of the standardization process of the API, I think the Web as a whole would benefit if we coordinated to deploy a reasonably similar interface for this functionality. -Alex Faaborg On Oct 2, 4:23 pm, Jeremy Orlow jor...@chromium.org wrote: That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? On Fri, Oct 2, 2009 at 4:11 PM, Ben Goodger (Google) b...@chromium.orgwrote: This relates somewhat to how we'd like people to install web applications. For that we figured a site would publish a manifest in some format (there was some talk about something like the extensions manifest) that specifies all kinds of appy things a site can do, like large icons, protocol schemes and mime types it can handle and the URLs for each, etc etc. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. -Ben On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/02... I'll try to take a look at the thread some time soon. Ben and/or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
BTW I think this API (and the associated registerContentHandler) aren't that great... imagine a feed reader that wants to handle feed types and feed protocol links... do they need to call these functions one per protocol scheme and per feed content type (there are several), showing a UI for each? This sort of thing seems better handled through some kind of manifest. -Ben On Thu, Oct 1, 2009 at 8:06 PM, Darin Fisher da...@chromium.org wrote: I've added this to my list for review by the group. -Darin On Thu, Oct 1, 2009 at 1:36 PM, Brian Rakowski br...@chromium.org wrote: You should talk with the open web leads (darin, ifette, dglazkov, slightlyoff) for help on floating this out there. On Thu, Oct 1, 2009 at 1:12 PM, Nick Baum nickb...@chromium.org wrote: I've never done this, but I'm happy to learn. I got an intro to how to do it a few weeks back re:some extensions APIs. Where do I send the email? I'll send out a draft here beforehand. -Nick On Thu, Oct 1, 2009 at 2:41 PM, Brad Green (大面包) b...@google.com wrote: API: How does the page know it's registered? If Gmail notices you have Chrome and this isn't set, it might put a big promo on your inbox page. However, if it's already set, if would of course want to hide this. I understand your point now. It is something that should be brought up in whatwg and discussed. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
I totally agree. I envision it being something much more like RSS feeds. In my mind, it should always advertise itself to the browser and then the browser should decide how to advertise it to the user. Requiring scripts to initiate things seems silly to me. Is this API even part of any standard? Maybe we should bring this up on WhatWG? On Fri, Oct 2, 2009 at 2:43 PM, Ben Goodger (Google) b...@chromium.orgwrote: BTW I think this API (and the associated registerContentHandler) aren't that great... imagine a feed reader that wants to handle feed types and feed protocol links... do they need to call these functions one per protocol scheme and per feed content type (there are several), showing a UI for each? This sort of thing seems better handled through some kind of manifest. -Ben On Thu, Oct 1, 2009 at 8:06 PM, Darin Fisher da...@chromium.org wrote: I've added this to my list for review by the group. -Darin On Thu, Oct 1, 2009 at 1:36 PM, Brian Rakowski br...@chromium.org wrote: You should talk with the open web leads (darin, ifette, dglazkov, slightlyoff) for help on floating this out there. On Thu, Oct 1, 2009 at 1:12 PM, Nick Baum nickb...@chromium.org wrote: I've never done this, but I'm happy to learn. I got an intro to how to do it a few weeks back re:some extensions APIs. Where do I send the email? I'll send out a draft here beforehand. -Nick On Thu, Oct 1, 2009 at 2:41 PM, Brad Green (大面包) b...@google.com wrote: API: How does the page know it's registered? If Gmail notices you have Chrome and this isn't set, it might put a big promo on your inbox page. However, if it's already set, if would of course want to hide this. I understand your point now. It is something that should be brought up in whatwg and discussed. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023084.html I'll try to take a look at the thread some time soon. Ben and/or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
I had included the link to the specification in the design document: http://www.w3.org/TR/html5/browsers.html#dom-navigator-registerprotocolhandler -brad On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: I totally agree. I envision it being something much more like RSS feeds. In my mind, it should always advertise itself to the browser and then the browser should decide how to advertise it to the user. Requiring scripts to initiate things seems silly to me. Is this API even part of any standard? Maybe we should bring this up on WhatWG? On Fri, Oct 2, 2009 at 2:43 PM, Ben Goodger (Google) b...@chromium.org wrote: BTW I think this API (and the associated registerContentHandler) aren't that great... imagine a feed reader that wants to handle feed types and feed protocol links... do they need to call these functions one per protocol scheme and per feed content type (there are several), showing a UI for each? This sort of thing seems better handled through some kind of manifest. -Ben On Thu, Oct 1, 2009 at 8:06 PM, Darin Fisher da...@chromium.org wrote: I've added this to my list for review by the group. -Darin On Thu, Oct 1, 2009 at 1:36 PM, Brian Rakowski br...@chromium.org wrote: You should talk with the open web leads (darin, ifette, dglazkov, slightlyoff) for help on floating this out there. On Thu, Oct 1, 2009 at 1:12 PM, Nick Baum nickb...@chromium.org wrote: I've never done this, but I'm happy to learn. I got an intro to how to do it a few weeks back re:some extensions APIs. Where do I send the email? I'll send out a draft here beforehand. -Nick On Thu, Oct 1, 2009 at 2:41 PM, Brad Green (大面包) b...@google.com wrote: API: How does the page know it's registered? If Gmail notices you have Chrome and this isn't set, it might put a big promo on your inbox page. However, if it's already set, if would of course want to hide this. I understand your point now. It is something that should be brought up in whatwg and discussed. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
This relates somewhat to how we'd like people to install web applications. For that we figured a site would publish a manifest in some format (there was some talk about something like the extensions manifest) that specifies all kinds of appy things a site can do, like large icons, protocol schemes and mime types it can handle and the URLs for each, etc etc. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. -Ben On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023084.html I'll try to take a look at the thread some time soon. Ben and/or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? On Fri, Oct 2, 2009 at 4:11 PM, Ben Goodger (Google) b...@chromium.orgwrote: This relates somewhat to how we'd like people to install web applications. For that we figured a site would publish a manifest in some format (there was some talk about something like the extensions manifest) that specifies all kinds of appy things a site can do, like large icons, protocol schemes and mime types it can handle and the URLs for each, etc etc. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. -Ben On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023084.html I'll try to take a look at the thread some time soon. Ben and/or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
I don't think Hixie was a huge fan of it iirc ;-) He didn't like the idea of installing webapps... though that's just a UA defined semantic. -Ben On Fri, Oct 2, 2009 at 4:23 PM, Jeremy Orlow jor...@chromium.org wrote: That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? On Fri, Oct 2, 2009 at 4:11 PM, Ben Goodger (Google) b...@chromium.org wrote: This relates somewhat to how we'd like people to install web applications. For that we figured a site would publish a manifest in some format (there was some talk about something like the extensions manifest) that specifies all kinds of appy things a site can do, like large icons, protocol schemes and mime types it can handle and the URLs for each, etc etc. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. -Ben On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023084.html I'll try to take a look at the thread some time soon. Ben and/or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
BTW this is something that we want to pursue independently of whether or not it's in HTML5... we already have app frames/app shortcuts, we would like to streamline this some. If someone wants to work with other vendors to come up with a standardized version great, so long as the UA controls the UX and can extend the feature set in a compatible way. -Ben On Fri, Oct 2, 2009 at 4:29 PM, Ben Goodger (Google) b...@chromium.org wrote: I don't think Hixie was a huge fan of it iirc ;-) He didn't like the idea of installing webapps... though that's just a UA defined semantic. -Ben On Fri, Oct 2, 2009 at 4:23 PM, Jeremy Orlow jor...@chromium.org wrote: That seems like a good plan. Has anyone ever tried formalizing it and floating it around to other vendors? On Fri, Oct 2, 2009 at 4:11 PM, Ben Goodger (Google) b...@chromium.org wrote: This relates somewhat to how we'd like people to install web applications. For that we figured a site would publish a manifest in some format (there was some talk about something like the extensions manifest) that specifies all kinds of appy things a site can do, like large icons, protocol schemes and mime types it can handle and the URLs for each, etc etc. The UA would expose some way to activate all of this functionality for a site in one shot... e.g. if the site published the data via some kind of link tag then a menu item in the browser might activate that the user could use to activate it. -Ben On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting pkast...@google.com wrote: On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow jor...@chromium.org wrote: Is this API even part of any standard? Maybe we should bring this up on WhatWG? The thread title is a clue that these are specced in HTML5 :) Not really. People abuse the term HTML5. Good example: WebSockets, WebDatabase, LocalStorage, Workers, and many of the other APIs we associate with HTML5 are not in that spec. Anyhow, apparently this was discussed very recently and I somehow missed the discussion: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/023084.html I'll try to take a look at the thread some time soon. Ben and/or other UI guys, maybe you should too. Now is the time to make noise if we think this is a bad API. J --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
I've never done this, but I'm happy to learn. I got an intro to how to do it a few weeks back re:some extensions APIs. Where do I send the email? I'll send out a draft here beforehand. -Nick On Thu, Oct 1, 2009 at 2:41 PM, Brad Green (大面包) b...@google.com wrote: API: How does the page know it's registered? If Gmail notices you have Chrome and this isn't set, it might put a big promo on your inbox page. However, if it's already set, if would of course want to hide this. I understand your point now. It is something that should be brought up in whatwg and discussed. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
You should talk with the open web leads (darin, ifette, dglazkov, slightlyoff) for help on floating this out there. On Thu, Oct 1, 2009 at 1:12 PM, Nick Baum nickb...@chromium.org wrote: I've never done this, but I'm happy to learn. I got an intro to how to do it a few weeks back re:some extensions APIs. Where do I send the email? I'll send out a draft here beforehand. -Nick On Thu, Oct 1, 2009 at 2:41 PM, Brad Green (大面包) b...@google.com wrote: API: How does the page know it's registered? If Gmail notices you have Chrome and this isn't set, it might put a big promo on your inbox page. However, if it's already set, if would of course want to hide this. I understand your point now. It is something that should be brought up in whatwg and discussed. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
I've added this to my list for review by the group.-Darin On Thu, Oct 1, 2009 at 1:36 PM, Brian Rakowski br...@chromium.org wrote: You should talk with the open web leads (darin, ifette, dglazkov, slightlyoff) for help on floating this out there. On Thu, Oct 1, 2009 at 1:12 PM, Nick Baum nickb...@chromium.org wrote: I've never done this, but I'm happy to learn. I got an intro to how to do it a few weeks back re:some extensions APIs. Where do I send the email? I'll send out a draft here beforehand. -Nick On Thu, Oct 1, 2009 at 2:41 PM, Brad Green (大面包) b...@google.com wrote: API: How does the page know it's registered? If Gmail notices you have Chrome and this isn't set, it might put a big promo on your inbox page. However, if it's already set, if would of course want to hide this. I understand your point now. It is something that should be brought up in whatwg and discussed. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
Thanks for everyone's comments. I'm replying to Nick's message since he had them rather collected and enumerated. UI: I prefer the infobar, as per the arguments above. I don't think this will happen frequently enough to be annoying. This seems to be the consensus. UI: Should there be user UI to manage this that doesn't require knowing a magic about:protocols url? More than happy to have one if the UI gurus have something in mind, I was actively attempting to not change any UI element. API: Is there an API to unregister from a protocol? No, as spec'd a webapp only announces it's availability by calling registerProtocolHandler when loaded. The UA must provide a mechanism for removing/announcing registration. API: How does the page know it's registered? Why would it need to know? There's nothing it can change. We should probably have a separate API for this, so sites can display a more prominent call to action when they're not registered. Beyond the infobar (which should be hidden on return navigations if the user has previously declined,but always available from about:protocols), what do you have in mind? Not having a means of suppressing this will make the site annoying. Misc: Should there be some way for native apps to register as protocol handlers? (say iTunes for mp3s, outlook for mailto, etc). Or does the OS provide this? The OS provides hooks for some protocols. I mentioned this in the tail end of the script; I'm not sure how happy users would be to see Chrome populating their registry with protocol handlers. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: Uber Page Info Window (Was: Re: [chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API)
I'd like to suggest early on that it's done in HTML for the usual reasons. (And also that there are the usual negatives. Just wanna plant the seed.) In particular, a meta-page page would allow the typical operations on subresource links (click to view; media playing would work in-browser; right-click to download) and our HTML-based extensions would integrate better (no need to be stuck in an extra tab on the side with jarringly different UI compared to native controls). On Mon, Sep 28, 2009 at 8:00 PM, Robert Sesek rse...@chromium.org wrote: For reference: http://code.google.com/p/chromium/issues/detail?id=5973 I'd be interested in helping out with this on the Mac side. I filed a Camino bug a couple of years ago about something similar. Safari has a helpful tool in Window -- Activity that allows you to download all resources of a page (including XHR and others loaded through JS). DevTools does something similar, but compared to Safari's interface it's slower and harder to find things (the entries in the list take up more vertical space). rsesek / @chromium.org On Fri, Sep 25, 2009 at 10:25 PM, Ben Goodger (Google) b...@chromium.org wrote: BTW I should note what I mean by Uber Page Info Window. For some time, we've talked about improving the page info window in Chrome. Right now it shows only the security information for a SSL page. In the future we'd like to extend this to show other information. The idea is there'd be a few tabs showing things like: - general page info in addition to security info - web capabilities/permissions used by the page, along with the ability to control these, including the effect of any active blacklist - media attached to the page, which a convenient way to download - eventually an additional surface for extensions to add tabs/features based on content-script scanning of the page The idea anyway is for any web capability there'd be a toggle in here. We also envisage some kind of app/extension page where one can visit the properties/capabilities for an individual installed app/extension too. Anyway any time the notion of site-specific capability control comes up, the response from the UX team tends to be uber page info window. It's on our list, we just have been busy with other stuff. I mocked this some years ago in Firefox as a bottom bar http://web.archive.org/web/20051220182808/wiki.mozilla.org/Firefox:Info_Window but I am not advocating that approach necessarily. -Ben On Fri, Sep 25, 2009 at 7:13 PM, Ben Goodger (Google) b...@chromium.org wrote: On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow jor...@chromium.org wrote: I had the same thoughts. Does Firefox not implement anything like this? Another question that this brings up: how could a user un-register something even if the web site doesn't do anything to make it possible? In other words, we might need some piece of UI to remove registrations even beyond having an API for it. Uber page info dialog. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: Uber Page Info Window (Was: Re: [chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API)
Good point on HTML. Why not instead make DevTools better/faster/do-what-you-want-them-to-do? :DG On Tue, Sep 29, 2009 at 9:08 AM, Evan Martin e...@chromium.org wrote: I'd like to suggest early on that it's done in HTML for the usual reasons. (And also that there are the usual negatives. Just wanna plant the seed.) In particular, a meta-page page would allow the typical operations on subresource links (click to view; media playing would work in-browser; right-click to download) and our HTML-based extensions would integrate better (no need to be stuck in an extra tab on the side with jarringly different UI compared to native controls). On Mon, Sep 28, 2009 at 8:00 PM, Robert Sesek rse...@chromium.org wrote: For reference: http://code.google.com/p/chromium/issues/detail?id=5973 I'd be interested in helping out with this on the Mac side. I filed a Camino bug a couple of years ago about something similar. Safari has a helpful tool in Window -- Activity that allows you to download all resources of a page (including XHR and others loaded through JS). DevTools does something similar, but compared to Safari's interface it's slower and harder to find things (the entries in the list take up more vertical space). rsesek / @chromium.org On Fri, Sep 25, 2009 at 10:25 PM, Ben Goodger (Google) b...@chromium.org wrote: BTW I should note what I mean by Uber Page Info Window. For some time, we've talked about improving the page info window in Chrome. Right now it shows only the security information for a SSL page. In the future we'd like to extend this to show other information. The idea is there'd be a few tabs showing things like: - general page info in addition to security info - web capabilities/permissions used by the page, along with the ability to control these, including the effect of any active blacklist - media attached to the page, which a convenient way to download - eventually an additional surface for extensions to add tabs/features based on content-script scanning of the page The idea anyway is for any web capability there'd be a toggle in here. We also envisage some kind of app/extension page where one can visit the properties/capabilities for an individual installed app/extension too. Anyway any time the notion of site-specific capability control comes up, the response from the UX team tends to be uber page info window. It's on our list, we just have been busy with other stuff. I mocked this some years ago in Firefox as a bottom bar http://web.archive.org/web/20051220182808/wiki.mozilla.org/Firefox:Info_Window but I am not advocating that approach necessarily. -Ben On Fri, Sep 25, 2009 at 7:13 PM, Ben Goodger (Google) b...@chromium.org wrote: On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow jor...@chromium.org wrote: I had the same thoughts. Does Firefox not implement anything like this? Another question that this brings up: how could a user un-register something even if the web site doesn't do anything to make it possible? In other words, we might need some piece of UI to remove registrations even beyond having an API for it. Uber page info dialog. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: Uber Page Info Window (Was: Re: [chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API)
Depends if we want it to feel webby or dialoggy. Unsure yet. Good case for either way. Will keep it in mind. -Ben On Tue, Sep 29, 2009 at 9:08 AM, Evan Martin e...@chromium.org wrote: I'd like to suggest early on that it's done in HTML for the usual reasons. (And also that there are the usual negatives. Just wanna plant the seed.) In particular, a meta-page page would allow the typical operations on subresource links (click to view; media playing would work in-browser; right-click to download) and our HTML-based extensions would integrate better (no need to be stuck in an extra tab on the side with jarringly different UI compared to native controls). On Mon, Sep 28, 2009 at 8:00 PM, Robert Sesek rse...@chromium.org wrote: For reference: http://code.google.com/p/chromium/issues/detail?id=5973 I'd be interested in helping out with this on the Mac side. I filed a Camino bug a couple of years ago about something similar. Safari has a helpful tool in Window -- Activity that allows you to download all resources of a page (including XHR and others loaded through JS). DevTools does something similar, but compared to Safari's interface it's slower and harder to find things (the entries in the list take up more vertical space). rsesek / @chromium.org On Fri, Sep 25, 2009 at 10:25 PM, Ben Goodger (Google) b...@chromium.org wrote: BTW I should note what I mean by Uber Page Info Window. For some time, we've talked about improving the page info window in Chrome. Right now it shows only the security information for a SSL page. In the future we'd like to extend this to show other information. The idea is there'd be a few tabs showing things like: - general page info in addition to security info - web capabilities/permissions used by the page, along with the ability to control these, including the effect of any active blacklist - media attached to the page, which a convenient way to download - eventually an additional surface for extensions to add tabs/features based on content-script scanning of the page The idea anyway is for any web capability there'd be a toggle in here. We also envisage some kind of app/extension page where one can visit the properties/capabilities for an individual installed app/extension too. Anyway any time the notion of site-specific capability control comes up, the response from the UX team tends to be uber page info window. It's on our list, we just have been busy with other stuff. I mocked this some years ago in Firefox as a bottom bar http://web.archive.org/web/20051220182808/wiki.mozilla.org/Firefox:Info_Window but I am not advocating that approach necessarily. -Ben On Fri, Sep 25, 2009 at 7:13 PM, Ben Goodger (Google) b...@chromium.org wrote: On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow jor...@chromium.org wrote: I had the same thoughts. Does Firefox not implement anything like this? Another question that this brings up: how could a user un-register something even if the web site doesn't do anything to make it possible? In other words, we might need some piece of UI to remove registrations even beyond having an API for it. Uber page info dialog. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
Thanks for the response, comments inline. On Tue, Sep 29, 2009 at 12:44 AM, brg b...@chromium.org wrote: Thanks for everyone's comments. I'm replying to Nick's message since he had them rather collected and enumerated. UI: I prefer the infobar, as per the arguments above. I don't think this will happen frequently enough to be annoying. This seems to be the consensus. UI: Should there be user UI to manage this that doesn't require knowing a magic about:protocols url? More than happy to have one if the UI gurus have something in mind, I was actively attempting to not change any UI element. My guess is we'll need this, but good Chrome-y design attitude :) API: Is there an API to unregister from a protocol? No, as spec'd a webapp only announces it's availability by calling registerProtocolHandler when loaded. The UA must provide a mechanism for removing/announcing registration. If the app is providing in-page UI to set this, they might want to provide corresponding UI to un-set it. API: How does the page know it's registered? Why would it need to know? There's nothing it can change. If Gmail notices you have Chrome and this isn't set, it might put a big promo on your inbox page. However, if it's already set, if would of course want to hide this. We should probably have a separate API for this, so sites can display a more prominent call to action when they're not registered. Beyond the infobar (which should be hidden on return navigations if the user has previously declined,but always available from about:protocols), what do you have in mind? Not having a means of suppressing this will make the site annoying. See Gmail example. BTW, I think the infobar should be yes, not now, never. Misc: Should there be some way for native apps to register as protocol handlers? (say iTunes for mp3s, outlook for mailto, etc). Or does the OS provide this? The OS provides hooks for some protocols. I mentioned this in the tail end of the script; I'm not sure how happy users would be to see Chrome populating their registry with protocol handlers. Fair enough. This seems to work on PC today, but not on Mac for some reason. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
I think Ben meant that the javascript would have to come from a user-click (just like for popups), which I totally support. For what it's worth, I think it will be better for the page to provide in-context discovery of this (in Gmail settings, for example), rather than force the user to discover an out-of-page UI. I really don't see this happening very often, so I'm not particularly worried about it being annoying. -Nick On Sat, Sep 26, 2009 at 12:19 PM, Linus Upson li...@google.com wrote: Yes. Please do not add more ways for script to instigate out-of-page UI. It is all evil. Linus On Fri, Sep 25, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.orgwrote: We should only allow this UI to be invoked from a user gesture. -Ben On Fri, Sep 25, 2009 at 12:41 PM, Jeremy Orlow jor...@chromium.org wrote: What's to keep sites from spamming you? What if they spam you and then later you decide you want to install it anyway? I guess I misunderstood the model of this feature. Seeing the bit about the rss feeds made me think that an app would use this to advertise that you could install it. I didn't realize that we were assuming the API would only be called after a user action. To be honest, I much prefer the rss feed way of thinking about it. I'm not a UI guy, though. :-) On Fri, Sep 25, 2009 at 12:32 PM, Ben Goodger (Google) b...@chromium.org wrote: As a result, I think we should have a dialog here. It's similar to what Firefox does, too. -Ben On Fri, Sep 25, 2009 at 12:31 PM, Brian Rakowski br...@chromium.org wrote: In general, we've been operating under the assumption that a user-initiated gesture (click here to make gmail your mailto handler) results in a dialog. Non-user-initiated (site intitiated) results in an infobar. If you've denied the infobar this in the past, the site will have to get you to click on something in its UI to prompt you for this again. On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting pkast...@google.com wrote: On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow jor...@chromium.org wrote: If you click no on an info bar, then how would you later change your mind? I don't know. Maybe at that point the icon appears in the address bar. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: Uber Page Info Window (Was: Re: [chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API)
I agree that this comes up often enough that it's probably worth doing. The opportunities for extensions that you mention are also interesting. I don't see how this would make it into 4.0, but maybe something to prioritize for 5.0? Out of curiosity, you've historically been opposed to any kind of granular per-page prefs. What's changed? -Nick On Fri, Sep 25, 2009 at 7:25 PM, Ben Goodger (Google) b...@chromium.orgwrote: BTW I should note what I mean by Uber Page Info Window. For some time, we've talked about improving the page info window in Chrome. Right now it shows only the security information for a SSL page. In the future we'd like to extend this to show other information. The idea is there'd be a few tabs showing things like: - general page info in addition to security info - web capabilities/permissions used by the page, along with the ability to control these, including the effect of any active blacklist - media attached to the page, which a convenient way to download - eventually an additional surface for extensions to add tabs/features based on content-script scanning of the page The idea anyway is for any web capability there'd be a toggle in here. We also envisage some kind of app/extension page where one can visit the properties/capabilities for an individual installed app/extension too. Anyway any time the notion of site-specific capability control comes up, the response from the UX team tends to be uber page info window. It's on our list, we just have been busy with other stuff. I mocked this some years ago in Firefox as a bottom bar http://web.archive.org/web/20051220182808/wiki.mozilla.org/Firefox:Info_Window but I am not advocating that approach necessarily. -Ben On Fri, Sep 25, 2009 at 7:13 PM, Ben Goodger (Google) b...@chromium.org wrote: On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow jor...@chromium.org wrote: I had the same thoughts. Does Firefox not implement anything like this? Another question that this brings up: how could a user un-register something even if the web site doesn't do anything to make it possible? In other words, we might need some piece of UI to remove registrations even beyond having an API for it. Uber page info dialog. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
I was agreeing with Ben, I thought. - in-page discovery ui - script can't initiate out-of-page ui - only user actions can bring up out-of-page ui Linus On Mon, Sep 28, 2009 at 5:44 PM, Nick Baum nickb...@chromium.org wrote: I think Ben meant that the javascript would have to come from a user-click (just like for popups), which I totally support. For what it's worth, I think it will be better for the page to provide in-context discovery of this (in Gmail settings, for example), rather than force the user to discover an out-of-page UI. I really don't see this happening very often, so I'm not particularly worried about it being annoying. -Nick On Sat, Sep 26, 2009 at 12:19 PM, Linus Upson li...@google.com wrote: Yes. Please do not add more ways for script to instigate out-of-page UI. It is all evil. Linus On Fri, Sep 25, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.orgwrote: We should only allow this UI to be invoked from a user gesture. -Ben On Fri, Sep 25, 2009 at 12:41 PM, Jeremy Orlow jor...@chromium.org wrote: What's to keep sites from spamming you? What if they spam you and then later you decide you want to install it anyway? I guess I misunderstood the model of this feature. Seeing the bit about the rss feeds made me think that an app would use this to advertise that you could install it. I didn't realize that we were assuming the API would only be called after a user action. To be honest, I much prefer the rss feed way of thinking about it. I'm not a UI guy, though. :-) On Fri, Sep 25, 2009 at 12:32 PM, Ben Goodger (Google) b...@chromium.org wrote: As a result, I think we should have a dialog here. It's similar to what Firefox does, too. -Ben On Fri, Sep 25, 2009 at 12:31 PM, Brian Rakowski br...@chromium.org wrote: In general, we've been operating under the assumption that a user-initiated gesture (click here to make gmail your mailto handler) results in a dialog. Non-user-initiated (site intitiated) results in an infobar. If you've denied the infobar this in the past, the site will have to get you to click on something in its UI to prompt you for this again. On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting pkast...@google.com wrote: On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow jor...@chromium.org wrote: If you click no on an info bar, then how would you later change your mind? I don't know. Maybe at that point the icon appears in the address bar. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Re: Uber Page Info Window (Was: Re: [chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API)
For reference: http://code.google.com/p/chromium/issues/detail?id=5973 I'd be interested in helping out with this on the Mac side. I filed a Camino bug https://bugzilla.mozilla.org/show_bug.cgi?id=297376 a couple of years ago about something similar. Safari has a helpful tool in Window -- Activity that allows you to download all resources of a page (including XHR and others loaded through JS). DevTools does something similar, but compared to Safari's interface it's slower and harder to find things (the entries in the list take up more vertical space). rsesek / @chromium.org On Fri, Sep 25, 2009 at 10:25 PM, Ben Goodger (Google) b...@chromium.orgwrote: BTW I should note what I mean by Uber Page Info Window. For some time, we've talked about improving the page info window in Chrome. Right now it shows only the security information for a SSL page. In the future we'd like to extend this to show other information. The idea is there'd be a few tabs showing things like: - general page info in addition to security info - web capabilities/permissions used by the page, along with the ability to control these, including the effect of any active blacklist - media attached to the page, which a convenient way to download - eventually an additional surface for extensions to add tabs/features based on content-script scanning of the page The idea anyway is for any web capability there'd be a toggle in here. We also envisage some kind of app/extension page where one can visit the properties/capabilities for an individual installed app/extension too. Anyway any time the notion of site-specific capability control comes up, the response from the UX team tends to be uber page info window. It's on our list, we just have been busy with other stuff. I mocked this some years ago in Firefox as a bottom bar http://web.archive.org/web/20051220182808/wiki.mozilla.org/Firefox:Info_Window but I am not advocating that approach necessarily. -Ben On Fri, Sep 25, 2009 at 7:13 PM, Ben Goodger (Google) b...@chromium.org wrote: On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow jor...@chromium.org wrote: I had the same thoughts. Does Firefox not implement anything like this? Another question that this brings up: how could a user un-register something even if the web site doesn't do anything to make it possible? In other words, we might need some piece of UI to remove registrations even beyond having an API for it. Uber page info dialog. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
Yes, I think we're on the same page: you don't mean that the user has to click some UI element out-of-page (as the original proposal suggested), but that the script that triggers the out-of-page UI has to originate from a user action. -Nick On Mon, Sep 28, 2009 at 7:02 PM, Linus Upson li...@google.com wrote: I was agreeing with Ben, I thought. - in-page discovery ui - script can't initiate out-of-page ui - only user actions can bring up out-of-page ui Linus On Mon, Sep 28, 2009 at 5:44 PM, Nick Baum nickb...@chromium.org wrote: I think Ben meant that the javascript would have to come from a user-click (just like for popups), which I totally support. For what it's worth, I think it will be better for the page to provide in-context discovery of this (in Gmail settings, for example), rather than force the user to discover an out-of-page UI. I really don't see this happening very often, so I'm not particularly worried about it being annoying. -Nick On Sat, Sep 26, 2009 at 12:19 PM, Linus Upson li...@google.com wrote: Yes. Please do not add more ways for script to instigate out-of-page UI. It is all evil. Linus On Fri, Sep 25, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.org wrote: We should only allow this UI to be invoked from a user gesture. -Ben On Fri, Sep 25, 2009 at 12:41 PM, Jeremy Orlow jor...@chromium.org wrote: What's to keep sites from spamming you? What if they spam you and then later you decide you want to install it anyway? I guess I misunderstood the model of this feature. Seeing the bit about the rss feeds made me think that an app would use this to advertise that you could install it. I didn't realize that we were assuming the API would only be called after a user action. To be honest, I much prefer the rss feed way of thinking about it. I'm not a UI guy, though. :-) On Fri, Sep 25, 2009 at 12:32 PM, Ben Goodger (Google) b...@chromium.org wrote: As a result, I think we should have a dialog here. It's similar to what Firefox does, too. -Ben On Fri, Sep 25, 2009 at 12:31 PM, Brian Rakowski br...@chromium.org wrote: In general, we've been operating under the assumption that a user-initiated gesture (click here to make gmail your mailto handler) results in a dialog. Non-user-initiated (site intitiated) results in an infobar. If you've denied the infobar this in the past, the site will have to get you to click on something in its UI to prompt you for this again. On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting pkast...@google.com wrote: On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow jor...@chromium.org wrote: If you click no on an info bar, then how would you later change your mind? I don't know. Maybe at that point the icon appears in the address bar. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
I really like this feature. Some comments inside the doc. Is registerContentHandler also in the works? --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
Yes. Please do not add more ways for script to instigate out-of-page UI. It is all evil. Linus On Fri, Sep 25, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.orgwrote: We should only allow this UI to be invoked from a user gesture. -Ben On Fri, Sep 25, 2009 at 12:41 PM, Jeremy Orlow jor...@chromium.org wrote: What's to keep sites from spamming you? What if they spam you and then later you decide you want to install it anyway? I guess I misunderstood the model of this feature. Seeing the bit about the rss feeds made me think that an app would use this to advertise that you could install it. I didn't realize that we were assuming the API would only be called after a user action. To be honest, I much prefer the rss feed way of thinking about it. I'm not a UI guy, though. :-) On Fri, Sep 25, 2009 at 12:32 PM, Ben Goodger (Google) b...@chromium.org wrote: As a result, I think we should have a dialog here. It's similar to what Firefox does, too. -Ben On Fri, Sep 25, 2009 at 12:31 PM, Brian Rakowski br...@chromium.org wrote: In general, we've been operating under the assumption that a user-initiated gesture (click here to make gmail your mailto handler) results in a dialog. Non-user-initiated (site intitiated) results in an infobar. If you've denied the infobar this in the past, the site will have to get you to click on something in its UI to prompt you for this again. On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting pkast...@google.com wrote: On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow jor...@chromium.org wrote: If you click no on an info bar, then how would you later change your mind? I don't know. Maybe at that point the icon appears in the address bar. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
I'm concerned that the page actions style Omnibox icon is not sufficient notification for users that this capability exists. I'll add this to the list of features for UI team to create mocks for. On Thu, Sep 24, 2009 at 12:51 PM, b...@chromium.org wrote: I've shared a document with you: [HTML5] registerProtocolHandler API http://docs.google.com/Doc?docid=0AVgZ1iILHLkdZGQ0bjd6cTVfMGdqZmpiNGZrhl=eninvite=CI6z8vgG It's not an attachment -- it's stored online at Google Docs. To open this document, just click the link above. This is a design document for the worked needed to resolve http://crbug.com/11359 beyond the webkit implementation. Please feel free to comment inline or in this thread. I look forward to your critics and suggestions. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
On Fri, Sep 25, 2009 at 11:33 AM, Brian Rakowski br...@chromium.org wrote: I'm concerned that the page actions style Omnibox icon is not sufficient notification for users that this capability exists. I'll add this to the list of features for UI team to create mocks for. I agree, I think I'd prefer an infobar for this. (/cue Glen hating on infobars) PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
If you click no on an info bar, then how would you later change your mind? I really liked the proposal because it'd just always be there. Much like the RSS feed UI. It seems like we can either just keep adding infobars or make an investment in training users what these icons mean. On Fri, Sep 25, 2009 at 11:36 AM, Peter Kasting pkast...@google.com wrote: On Fri, Sep 25, 2009 at 11:33 AM, Brian Rakowski br...@chromium.orgwrote: I'm concerned that the page actions style Omnibox icon is not sufficient notification for users that this capability exists. I'll add this to the list of features for UI team to create mocks for. I agree, I think I'd prefer an infobar for this. (/cue Glen hating on infobars) PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow jor...@chromium.org wrote: If you click no on an info bar, then how would you later change your mind? I don't know. Maybe at that point the icon appears in the address bar. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
In general, we've been operating under the assumption that a user-initiated gesture (click here to make gmail your mailto handler) results in a dialog. Non-user-initiated (site intitiated) results in an infobar. If you've denied the infobar this in the past, the site will have to get you to click on something in its UI to prompt you for this again. On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting pkast...@google.com wrote: On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow jor...@chromium.orgwrote: If you click no on an info bar, then how would you later change your mind? I don't know. Maybe at that point the icon appears in the address bar. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
As a result, I think we should have a dialog here. It's similar to what Firefox does, too. -Ben On Fri, Sep 25, 2009 at 12:31 PM, Brian Rakowski br...@chromium.org wrote: In general, we've been operating under the assumption that a user-initiated gesture (click here to make gmail your mailto handler) results in a dialog. Non-user-initiated (site intitiated) results in an infobar. If you've denied the infobar this in the past, the site will have to get you to click on something in its UI to prompt you for this again. On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting pkast...@google.comwrote: On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow jor...@chromium.orgwrote: If you click no on an info bar, then how would you later change your mind? I don't know. Maybe at that point the icon appears in the address bar. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
What's to keep sites from spamming you? What if they spam you and then later you decide you want to install it anyway? I guess I misunderstood the model of this feature. Seeing the bit about the rss feeds made me think that an app would use this to advertise that you could install it. I didn't realize that we were assuming the API would only be called after a user action. To be honest, I much prefer the rss feed way of thinking about it. I'm not a UI guy, though. :-) On Fri, Sep 25, 2009 at 12:32 PM, Ben Goodger (Google) b...@chromium.orgwrote: As a result, I think we should have a dialog here. It's similar to what Firefox does, too. -Ben On Fri, Sep 25, 2009 at 12:31 PM, Brian Rakowski br...@chromium.orgwrote: In general, we've been operating under the assumption that a user-initiated gesture (click here to make gmail your mailto handler) results in a dialog. Non-user-initiated (site intitiated) results in an infobar. If you've denied the infobar this in the past, the site will have to get you to click on something in its UI to prompt you for this again. On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting pkast...@google.comwrote: On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow jor...@chromium.orgwrote: If you click no on an info bar, then how would you later change your mind? I don't know. Maybe at that point the icon appears in the address bar. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
We should only allow this UI to be invoked from a user gesture. -Ben On Fri, Sep 25, 2009 at 12:41 PM, Jeremy Orlow jor...@chromium.org wrote: What's to keep sites from spamming you? What if they spam you and then later you decide you want to install it anyway? I guess I misunderstood the model of this feature. Seeing the bit about the rss feeds made me think that an app would use this to advertise that you could install it. I didn't realize that we were assuming the API would only be called after a user action. To be honest, I much prefer the rss feed way of thinking about it. I'm not a UI guy, though. :-) On Fri, Sep 25, 2009 at 12:32 PM, Ben Goodger (Google) b...@chromium.org wrote: As a result, I think we should have a dialog here. It's similar to what Firefox does, too. -Ben On Fri, Sep 25, 2009 at 12:31 PM, Brian Rakowski br...@chromium.org wrote: In general, we've been operating under the assumption that a user-initiated gesture (click here to make gmail your mailto handler) results in a dialog. Non-user-initiated (site intitiated) results in an infobar. If you've denied the infobar this in the past, the site will have to get you to click on something in its UI to prompt you for this again. On Fri, Sep 25, 2009 at 12:14 PM, Peter Kasting pkast...@google.com wrote: On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow jor...@chromium.org wrote: If you click no on an info bar, then how would you later change your mind? I don't know. Maybe at that point the icon appears in the address bar. PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
On Fri, Sep 25, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.orgwrote: We should only allow this UI to be invoked from a user gesture. How does Gmail trigger this today? Do they have a button in the Settings you have to click? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
First of all, thanks for putting together this proposal, great to see progress on this! A few comments: - UI: I prefer the infobar, as per the arguments above. I don't think this will happen frequently enough to be annoying. - UI: Should there be user UI to manage this that doesn't require knowing a magic about:protocols url? - API: Is there an API to unregister from a protocol? - API: How does the page know it's registered? We should probably have a separate API for this, so sites can display a more prominent call to action when they're not registered. - Misc: Should there be some way for native apps to register as protocol handlers? (say iTunes for mp3s, outlook for mailto, etc). Or does the OS provide this? Cheers, -Nick On Fri, Sep 25, 2009 at 12:45 PM, Peter Kasting pkast...@google.com wrote: On Fri, Sep 25, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.orgwrote: We should only allow this UI to be invoked from a user gesture. How does Gmail trigger this today? Do they have a button in the Settings you have to click? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
On Fri, Sep 25, 2009 at 5:30 PM, Nick Baum nickb...@chromium.org wrote: First of all, thanks for putting together this proposal, great to see progress on this! A few comments: - UI: I prefer the infobar, as per the arguments above. I don't think this will happen frequently enough to be annoying. - UI: Should there be user UI to manage this that doesn't require knowing a magic about:protocols url? - API: Is there an API to unregister from a protocol? - API: How does the page know it's registered? We should probably have a separate API for this, so sites can display a more prominent call to action when they're not registered. I had the same thoughts. Does Firefox not implement anything like this? Another question that this brings up: how could a user un-register something even if the web site doesn't do anything to make it possible? In other words, we might need some piece of UI to remove registrations even beyond having an API for it. - Misc: Should there be some way for native apps to register as protocol handlers? (say iTunes for mp3s, outlook for mailto, etc). Or does the OS provide this? Cheers, -Nick On Fri, Sep 25, 2009 at 12:45 PM, Peter Kasting pkast...@google.comwrote: On Fri, Sep 25, 2009 at 12:44 PM, Ben Goodger (Google) b...@chromium.orgwrote: We should only allow this UI to be invoked from a user gesture. How does Gmail trigger this today? Do they have a button in the Settings you have to click? PK --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow jor...@chromium.org wrote: I had the same thoughts. Does Firefox not implement anything like this? Another question that this brings up: how could a user un-register something even if the web site doesn't do anything to make it possible? In other words, we might need some piece of UI to remove registrations even beyond having an API for it. Uber page info dialog. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
Uber Page Info Window (Was: Re: [chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API)
BTW I should note what I mean by Uber Page Info Window. For some time, we've talked about improving the page info window in Chrome. Right now it shows only the security information for a SSL page. In the future we'd like to extend this to show other information. The idea is there'd be a few tabs showing things like: - general page info in addition to security info - web capabilities/permissions used by the page, along with the ability to control these, including the effect of any active blacklist - media attached to the page, which a convenient way to download - eventually an additional surface for extensions to add tabs/features based on content-script scanning of the page The idea anyway is for any web capability there'd be a toggle in here. We also envisage some kind of app/extension page where one can visit the properties/capabilities for an individual installed app/extension too. Anyway any time the notion of site-specific capability control comes up, the response from the UX team tends to be uber page info window. It's on our list, we just have been busy with other stuff. I mocked this some years ago in Firefox as a bottom bar http://web.archive.org/web/20051220182808/wiki.mozilla.org/Firefox:Info_Window but I am not advocating that approach necessarily. -Ben On Fri, Sep 25, 2009 at 7:13 PM, Ben Goodger (Google) b...@chromium.org wrote: On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow jor...@chromium.org wrote: I had the same thoughts. Does Firefox not implement anything like this? Another question that this brings up: how could a user un-register something even if the web site doesn't do anything to make it possible? In other words, we might need some piece of UI to remove registrations even beyond having an API for it. Uber page info dialog. -Ben --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API
Thanks for taking on this feature! Some comments: ChromeClientChromium will implement the runJavaScriptRegisterProtocolHandler method in the ChromeClientImpl class in webkit/glue/chrome_client_impl.h. Are you sure you need to add this method to ChromeClientChromium? That interface is only to be used when the method doesn't exist on ChromeClient. Only supporting a whitelist of schemes sounds best to me. What does Firefox allow? Before you venture too far into the implementation, I'd like to see what the proposed WebKit API changes will be. This would be a good thing to add to your design doc. Thanks, -Darin On Thu, Sep 24, 2009 at 12:51 PM, b...@chromium.org wrote: I've shared a document with you: [HTML5] registerProtocolHandler API http://docs.google.com/Doc?docid=0AVgZ1iILHLkdZGQ0bjd6cTVfMGdqZmpiNGZrhl=eninvite=CI6z8vgG It's not an attachment -- it's stored online at Google Docs. To open this document, just click the link above. This is a design document for the worked needed to resolve http://crbug.com/11359 beyond the webkit implementation. Please feel free to comment inline or in this thread. I look forward to your critics and suggestions. --~--~-~--~~~---~--~~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~--~~~~--~~--~--~---
