implications of manifest_version: 2
Michael Gundlach
Adam Barth
On Thu, Jan 26, 2012 at 10:44 AM, Michael Gundlach
<adblockf...@gmail.com> wrote:
> A few clarifying questions about manifest_version:2.
>
> 1. I thought
> (per http://code.google.com/chrome/extensions/dev/manifest.html#manifest_version) that
> Chrome 18 required manifest_version:2, but 18.0.1019.0 Canary happily loads
> my unpacked extension with no "manifest_version" entry in manifest.json. Is
> this a bug in the docs?
The original plan was for Chrome 18 to require a manifest_version of
2, but we decided that was too harsh a transition for developers.
We're going to roll out manifest_version 2 more slowly so that folks
have a chance to update their extension on their own schedule.
Does the documentation say that manifest_version 2 is required?
Developers should start using manifest_version in Chrome 18, but it's
not yet required. We probably should clarify that in the
documentation.
> When will manifest_version:2 be required?
That depends on how smoothly and quickly developers update their
extension. Our current plan is to start recommending that extensions
authors update their extensions when Chrome 18 reaches the stable
channel. That way manifest_version 2 will behave consistently across
all three channels. Once that happens, we'll start adding "carrots
and sticks" to the ecosystem to encourage developers to update. It's
likely a hard requirement for manifest_version 2 will be a ways off.
> 2. Will adding manifest_version:2 to my manifest cause any changes other
> than requiring a valid "content_security_policy" entry?
Using manifest_version 2 doesn't require you to write a valid
content_security_policy. Instead, it gives you a default policy of
"script-src 'self'; object-src 'self' " which helps protect your
extension from cross-site scripting. If you like, you can add a
content_security_policy attribute to your manifest to tighten or
loosen this default policy.
We're in the process of improving the documentation how all this works
and to explain what changes you'll need to make in your extension to
make it work with these policies. That's one of the reasons we've
moving more slowly in recommending that developers update their
extensions. We want to make sure all the documentation is in place
first.
To actually answer your question: there are some other smaller
breaking changes. I'm not sure what the fully list that made the cut,
but one example is that today, all the resources inside your extension
(e.g., images) are visible to web pages. We're changing the default
to "not visible" and then adding a manifest attribute to let you
whitelist the resources that you want to be accessible to web pages.
> 3. I've successfully converted my extension to CSP and added a CSP manifest
> entry. Is it safe to add manifest_version:2 to my manifest and ship today
> to my Chrome 16 users?
Great! Yes. Please be sure to test your extension in a Chrome 18 dev
release (or with a Canary release). Using manifest_version 2 adds
some restrictions to what kinds of CSP policies you can use. For
example, previously you could have script-src 'unsafe-inline', but
manifest_version 2 blocks that because it opens up your extension to
XSS. If your extension loads and works in a recent Chrome 18 build,
you should be fine.
Please let me know if you have any more questions. We've been
somewhat hesitate to talk about this topic before Chrome 18 reaches
the stable channel because we want to make sure everything works
consistently before too many developers dive in, but that also means
that these changes can appear slightly mysterious.
Adam
Michael Gundlach
On Thu, Jan 26, 2012 at 10:44 AM, Michael Gundlach
Does the documentation say that manifest_version 2 is required?
To actually answer your question: there are some other smallerbreaking changes. I'm not sure what the fully list that made the cut,
but one example is that today, all the resources inside your extension
(e.g., images) are visible to web pages. We're changing the default
to "not visible" and then adding a manifest attribute to let you
whitelist the resources that you want to be accessible to web pages.
> 3. I've successfully converted my extension to CSP and added a CSP manifest
> entry. Is it safe to add manifest_version:2 to my manifest and ship today
> to my Chrome 16 users?
If your extension loads and works in a recent Chrome 18 build,
you should be fine.
Please let me know if you have any more questions. We've been
somewhat hesitate to talk about this topic before Chrome 18 reaches
the stable channel because we want to make sure everything works
consistently before too many developers dive in, but that also means
that these changes can appear slightly mysterious.
Michael
Adam Barth
I'm entirely sure about "background" versus "background_page". Chrome
16 does ignore the mainfest_version attribute. The situation will be
much easier to understand once Chrome 18 is in the stable channel
because then everything will behave the same way. For now, I would
recommending testing anything you're unsure about.
>> Please let me know if you have any more questions. We've been
>> somewhat hesitate to talk about this topic before Chrome 18 reaches
>> the stable channel because we want to make sure everything works
>> consistently before too many developers dive in, but that also means
>> that these changes can appear slightly mysterious.
>
> I understand your caution, though it backfired in my case: because I
> couldn't understand what was required and when re CSP and manifest_version,
> I felt I needed to urgently take care of this lest my extension be broken
> tomorrow by a change in Chrome.
>
> Maybe just updating the existing docs to explain that these upcoming changes
> can be safely ignored until sometime *after* Chrome 18 hits stable will keep
> other devs from jumping into the fray as I did.
That's a good idea. Thanks for bearing with us. This is the first
time we're making a change like this to the extension system, so we're
learning what works and what doesn't work.
Adam
Michael Gundlach
16 does ignore the mainfest_version attribute. The situation will beI'm entirely sure about "background" versus "background_page". Chrome
much easier to understand once Chrome 18 is in the stable channel
because then everything will behave the same way. For now, I would
recommending testing anything you're unsure about.
That's a good idea. Thanks for bearing with us. This is the firsttime we're making a change like this to the extension system, so we're
learning what works and what doesn't work.
PhistucK
--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.
To post to this group, send email to chromium-...@chromium.org.
To unsubscribe from this group, send email to chromium-extens...@chromium.org.
For more options, visit this group at http://groups.google.com/a/chromium.org/group/chromium-extensions/?hl=en.
Mike West
-Mike
Aaron Boodman
On Mon, Jan 30, 2012 at 11:42 AM, Aaron Boodman <a...@google.com> wrote:
> On Sat, Jan 28, 2012 at 1:18 AM, PhistucK <phis...@gmail.com> wrote:
>> If I am not mistaking, somewhere around Chrome 13 - 15, they made a change
>> so that undefined manifest properties are ignored (before, they were causing
>> errors and made the extension not load).
>
> This wasn't true in the general case. There were some special issues
> with hosted apps and permissions where we would choke on unknown
> manifest features, though.
>
>> So, if you want to be ready for the future, but also keep everything working
>> now, I advise you to put both of the properties ("background" and
>> "background_page"), as well as any other new ones.
>> Keep all of the existing ones and add all of the new ones and you should be
>> fine, I believe. Such a manifest requires two quick tests - one on Chrome 16
>> and one on Chrome 18 and you should be done. I believe you will have no
>> problems with such manifest, if it is already ready for Chrome 18.
>
> We are trying to arrange things such that extension developers don't
> have to test on multiple releases. Long story short: your extensions
> should keep working with no changes in Chrome 18. If you do choose to
> upgrade to manifest_version=2 (which we will encourage you to do once
> it is stable), then you will have to make a few changes.
>
> We'll put some docs together about this soon.
>
> - a