[webkit-dev] Removing HTML notifications from WebKit (Was: Web Notifications API)

[Aaron Boodman]

Hello again,

I'd like to revise my proposal on deprecating HTML notifications in
Chrome extensions: I would like to make the feature runtime-enabled,
and leave it enabled for Chrome extensions until there is a suitable
replacement. Once we have a replacement, we can follow the deprecation
plan I sketched earlier.

It sounds like the Chrome web platform team is more OK with the idea
of removing it from web content. Having the runtime switch would make
it easy to implement both policies.

I understand that having this code is a tax on the WebKit project, but
it seems pretty small compared to other things that have been left in
for other clients.

- a

On Mon, Feb 13, 2012 at 11:23 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>
> This plan sounds reasonable to me. No disruption of Chrome extensions in the short term, but we would better align with each other and with standards in the longer term.
>
> Jon?
>
> Regards,
> Maciej
>
> On Feb 9, 2012, at 2:48 PM, Aaron Boodman wrote:
>
>> On Wed, Feb 8, 2012 at 7:50 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>>
>>> On Feb 8, 2012, at 6:15 PM, Aaron Boodman wrote:
>>>
>>>> On Wed, Feb 8, 2012 at 4:58 PM, Jon Lee <jonlee at apple.com> wrote:
>>>>> 2. Remove HTML notifications.
>>>>>
>>>>> It has been removed from the spec, and we don't intend on ever supporting
>>>>> HTML notifications. I brought this issue up before; is there an update on
>>>>> this front from any other platforms?
>>>>
>>>> HTML notifications are a pretty popular feature in Chrome's extension
>>>> system. As of a few months ago:
>>>>
>>>> * 614 extensions in our web store use createHTMLNotification
>>>> * 72 have more than 10k users
>>>> * 14 have more than 100k users
>>>> * 3 have more than 500k users
>>>> * 6.7M total actextension installs
>>>>
>>>> We can move developers off of this API, but not overnight. Is it
>>>> possible to come up with a slower deprecation plan than "immediately"?
>>>
>>> Since HTML notifications are already under a separate feature flag, it's probably practical to keep them around for a while, and just not include them in the proposed updated API. Do you have a suggestion for what might be a reasonable deprecation timeline?
>>
>> Awesome.
>>
>> Here is a rough plan of how deprecation could work:
>>
>> 0 months: Add a new extension format version and remove HTML
>> notifications support with that version.
>> 2 months: Support for the new format version is in Chrome's stable
>> channel. The documentation advises the new format version, and new
>> features require it.
>> 4 months: We start requiring the new manifest version for new
>> extensions uploaded to the store.
>> 8 months: We start requiring the new manifest version for updates to
>> existing extensions in the store.
>> 10 months: Remove support for the old manifest version from trunk of
>> Chrome. I believe at this point, we can remove the code from WebKit.
>>
>> We've never actually done this before though, so there may be some
>> hiccups. I'd plan on about a year.
>>
>> We have already started a new manifest format version for Chrome 18,
>> hopefully I can squeeze this change into that release.
>>
>> On Wed, Feb 8, 2012 at 9:24 PM, Adam Barth <abarth at webkit.org> wrote:
>>> Unrelated to timeline, it might be worthwhile to make
>>> createHTMLNotification a runtime-enabled feature so that we can avoid
>>> offering it to the web at large and possibly restrict it to only a
>>> whitelisted set of extensions.
>>
>> This is a very good idea.
>>
>> - a
>