[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API

[Aaron Boodman]

On Tue, Oct 20, 2009 at 6:35 PM, Alex Russell  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

[Alex Russell]

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  wrote:
> Open web leads, was there any further discussion of this?
> -Nick
>
> On Sun, Oct 4, 2009 at 8:33 PM, Alex  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  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  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)
>> > 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  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, 

[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API

[Nick Baum]

Open web leads, was there any further discussion of this?
-Nick

On Sun, Oct 4, 2009 at 8:33 PM, Alex  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  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  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)  >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  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 
> wrote:
> > > > On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting 
> > > wrote:
> >
> > > >> On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow 
> > > 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

[Alex]

> 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  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  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) 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  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  wrote:
> > > On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting 
> > wrote:
>
> > >> On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow 
> > 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

[Alex Faaborg]

 > 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  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)  
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  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  
 wrote:
 > > > On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting  

 > > wrote:
 >
 > > >> On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow  

 > > 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

[Ben Goodger (Google)]

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)  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  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) 
>> 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  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  wrote:
>>> > On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting 
>>> > wrote:
>>> >>
>>> >> On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow 
>>> >> 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

[Ben Goodger (Google)]

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  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) 
> 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  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  wrote:
>> > On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting 
>> > wrote:
>> >>
>> >> On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow 
>> >> 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

[Jeremy Orlow]

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) 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  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  wrote:
> > On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting 
> wrote:
> >>
> >> On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow 
> 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

[Ben Goodger (Google)]

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  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  wrote:
> On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting  wrote:
>>
>> On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow  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

[brg]

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  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) 
> 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  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 
>> > 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 
>> >> 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 (大面包) 
>> >>> 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

[Jeremy Orlow]

On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting  wrote:

> On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow  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

[Peter Kasting]

On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow  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

[Jeremy Orlow]

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) 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  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 
> 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 
> 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 (大面包) 
> 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

[Ben Goodger (Google)]

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  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  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  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 (大面包)  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

[Darin Fisher]

I've added this to my list for review by the group.-Darin

On Thu, Oct 1, 2009 at 1:36 PM, Brian Rakowski  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  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 (大面包)  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

[Brian Rakowski]

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  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 (大面包)  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

[Nick Baum]

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 (大面包)  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

[Nick Baum]

Thanks for the response, comments inline.

On Tue, Sep 29, 2009 at 12:44 AM, brg  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
-~--~~~~--~~--~--~---

Re: Uber Page Info Window (Was: Re: [chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API)

[Ben Goodger (Google)]

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  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  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) 
>> 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) 
>>> wrote:
>>> > On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow 
>>> > 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)

[Dimitri Glazkov]

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  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  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) 
>> 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) 
>>> wrote:
>>> > On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow 
>>> > 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)

[Evan Martin]

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  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) 
> 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) 
>> wrote:
>> > On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow 
>> > 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

[brg]

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
-~--~~~~--~~--~--~---

[chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API

[Nick Baum]

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  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  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  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) >> > 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 
 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 >>> >
 >> 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)

[Robert Sesek]

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) 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) 
> wrote:
> > On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow 
> 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

[Linus Upson]

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  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  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) 
>> 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 
>>> 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 
>>> >> 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 >> >
>>> >>> wrote:
>>> 
>>>  On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow >> >
>>>  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)

[Nick Baum]

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) 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) 
> wrote:
> > On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow 
> 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

[Nick Baum]

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  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) 
> 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 
>> 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 
>> >> 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 
>> >>> wrote:
>> 
>>  On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow 
>>  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

[Linus Upson]

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) 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 
> 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)  >
> > 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 
> >> 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 
> >>> wrote:
> 
>  On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow 
>  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

[Yaar Schnitman]

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

[Darin Fisher]

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,  wrote:

>
> I've shared a document with you:
>
> [HTML5] registerProtocolHandler API
>
> http://docs.google.com/Doc?docid=0AVgZ1iILHLkdZGQ0bjd6cTVfMGdqZmpiNGZr&hl=en&invite=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
-~--~~~~--~~--~--~---

Uber Page Info Window (Was: Re: [chromium-dev] Re: [DESIGN DOC] registerProtocolHandler HTML5 API)

[Ben Goodger (Google)]

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)  wrote:
> On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow  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

[Ben Goodger (Google)]

On Fri, Sep 25, 2009 at 6:13 PM, Jeremy Orlow  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

[Jeremy Orlow]

On Fri, Sep 25, 2009 at 5:30 PM, Nick Baum  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 wrote:
>
>> On Fri, Sep 25, 2009 at 12:44 PM, Ben Goodger (Google) 
>> wrote:
>>
>>> 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

[Nick Baum]

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  wrote:

> On Fri, Sep 25, 2009 at 12:44 PM, Ben Goodger (Google) 
> wrote:
>
>> 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

[Peter Kasting]

On Fri, Sep 25, 2009 at 12:44 PM, Ben Goodger (Google) wrote:

> 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

[Ben Goodger (Google)]

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  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) 
> 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 
>> 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 
>>> wrote:

 On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow 
 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

[Jeremy Orlow]

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) 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 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 wrote:
>>
>>> On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow 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

[Ben Goodger (Google)]

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  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 wrote:
>
>> On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow 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

[Brian Rakowski]

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  wrote:

> On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow 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

[Peter Kasting]

On Fri, Sep 25, 2009 at 12:08 PM, Jeremy Orlow  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

[Jeremy Orlow]

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  wrote:

> On Fri, Sep 25, 2009 at 11:33 AM, Brian Rakowski 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

[Peter Kasting]

On Fri, Sep 25, 2009 at 11:33 AM, Brian Rakowski  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

[Brian Rakowski]

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,  wrote:

>
> I've shared a document with you:
>
> [HTML5] registerProtocolHandler API
>
> http://docs.google.com/Doc?docid=0AVgZ1iILHLkdZGQ0bjd6cTVfMGdqZmpiNGZr&hl=en&invite=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
-~--~~~~--~~--~--~---