Re: [crx] Chrome Manifest version 1 to version 2 migration guide

[Aaron Boodman]

There's the "changes between 1 and 2" section on the bottom of this page:

http://code.google.com/chrome/extensions/manifestVersion.html

It's not a guide, but it lists all the things that change. The biggest
changes are the first two items: content_security_policy and
web_accessible_resources.

HTH,

- a

On Mon, Jul 9, 2012 at 2:35 AM, boxhead <andy....@gmail.com> wrote:
> I'm trying to upgrade my chrome extension from manifest version 1 to
> manifest version 2 but I can't find a migration guide, is there one?
>
> Cheers
>
> --
> You received this message because you are subscribed to the Google Groups
> "Chromium-extensions" group.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/-/RDmTqgX86AUJ.
> 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.

[Abraham Williams]

Bjorn,

Strand users on older versions of Chrome? Do you have a lot of users that are running an outdated version of Chrome? Is there a reason they versions are outdated?

Abraham
--
Abraham Williams | abrah.am | abraham+ | addvocate.co

@abraham | github.com/abraham | blog.abrah.am
This email is: [ ] shareable [x] ask first [ ] private.

On Mon, Jul 9, 2012 at 12:40 PM, Bjorn Stromberg <bjor...@gmail.com> wrote:

If you use messaging in your extension you cannot change to manifest version 2 without stranding users on older versions.

manifest_version: 1 requires background_page to send messages.

manifest_version: 2 explicitly disallows having background_page set.

You currently cannot publish an extension that works in both version 1 and version 2.

I have no idea why the developers decided to not include backwards compatibility between manifest_version 1 and manifest_version 2.

I have a lot of upset users that are stuck with a broken extension because of this.

On Monday, July 9, 2012 9:51:58 AM UTC-5, Aaron Boodman wrote:

There's the "changes between 1 and 2" section on the bottom of this page:

http://code.google.com/chrome/extensions/manifestVersion.html

It's not a guide, but it lists all the things that change. The biggest
changes are the first two items: content_security_policy and
web_accessible_resources.

HTH,

- a

On Mon, Jul 9, 2012 at 2:35 AM, boxhead <andy....@gmail.com> wrote:
> I'm trying to upgrade my chrome extension from manifest version 1 to
> manifest version 2 but I can't find a migration guide, is there one?
>
> Cheers
>
> --
> You received this message because you are subscribed to the Google Groups
> "Chromium-extensions" group.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/-/RDmTqgX86AUJ.

> To post to this group, send email to chromium-extensions@chromium.org.

> To unsubscribe from this group, send email to

> chromium-extensions+unsub...@chromium.org.

> For more options, visit this group at
> http://groups.google.com/a/chromium.org/group/chromium-extensions/?hl=en.

--

You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/-/UlpZBsFft_EJ.

[Drew]

Guys, this is a much bigger problem than you seem to realize.  We here at LastPass recently made many changes to ready ourselves for the inevitability of manifest version 2, although we haven't flipped it on yet.  One of those changes was background_page => background.

After releasing, we found that a ton of users are still using Chrome < 18, even though it's been out almost 4 months.  Also, RockMelt, a browser based on Chrome, is still based on Chrome 16.

So, we've been forced to switch back to background_page and will have to make an emergency release.  Of course, if you stick to your stated timelines, come early November, we'll be forced to switch from background_page to background again, and the same problem will most likely occur.

You might want to revisit your timelines or do whatever else is necessary to lessen the impact of this.  I have to imagine most if not all other extensions will suffer the same problems.

I've found that if I include both background_page and background, I get an ugly warning on the extensions page in Chrome 20, but it works in both Chrome 20 and RockMelt.

Will this be a legitimate solution going forward?  In other words, will the warning ever turn into an error?

Bjorn,

> chromium-extensions+unsubscribe...@chromium.org.

> For more options, visit this group at
> http://groups.google.com/a/chromium.org/group/chromium-extensions/?hl=en.

--
You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.

[Adam Barth]

I'm surprised that you found so many users using Chrome < 18.  Our numbers show that this population of users is very small.  Maybe we can ask these users to update to the newest version of Chrome?  Old versions get out-of-date w.r.t. security patches very quickly.

As for folks using RockMelt, I'm not sure what we can do to help.  Chrome 16 is very out-of-date w.r.t. security patches.

Adam

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/-/3Ooe1vGrpQEJ.

To post to this group, send email to chromium-...@chromium.org.
To unsubscribe from this group, send email to chromium-extens...@chromium.org.

[Drew]

I'm sure they're small percentage-wise, but they're definitely out there.  We've received dozens of bad reviews in the past few days due to this, and have been contacted directly by dozens of users as well.

I think it's likely that many (although certainly not all, since I see reports of Chrome 15 and Chrome 17) of the users who are affected are running other browsers based on Chrome, such as RockMelt and CoolNovo, which both appear to be based on Chrome 16 right now.  I see many reviews mention CoolNovo.  However, regardless of why they're running old versions, they are, and I doubt this problem will go away any time soon.  We can certainly suggest that users upgrade Chrome, but that doesn't help with the users that never contact us.

If background_page was deprecated due to a security issue, I'd understand.  However, it seems very unwise to simply deprecate background_page for no good reason, as it seems to have been.

If someone could respond to the workaround I seem to have found, I'd appreciate it:

I've found that if I include both background_page and background, I get an ugly warning on the extensions page in Chrome 20, but it works in both Chrome 20 and RockMelt.

Will this be a legitimate solution going forward?  In other words, will the warning ever turn into an error?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/-/3Ooe1vGrpQEJ.

[Aaron Boodman]

We're looking into this. We're going to have to investigate how
quickly the population of each version of Chrome shrinks and double
check our planned timing.

Thanks,

- a

>>>>>> > 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.
>>>>>
>>>>> --
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "Chromium-extensions" group.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/-/UlpZBsFft_EJ.
>>>>>

>>>>> 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.
>>>>
>>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Chromium-extensions" group.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/-/3Ooe1vGrpQEJ.
>>>

>>> 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.
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Chromium-extensions" group.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/-/Ih1mVGKLX1IJ.
>
> To post to this group, send email to chromium-...@chromium.org.

> To unsubscribe from this group, send email to

> chromium-extens...@chromium.org.

[Bjorn Stromberg]

Drew, that workaround doesn't work on v19, there is a hard fail that prevents users from installing an extension that has manifest_version 2 and background_page in the manifest. For some reason they relaxed it in v20.

Why is Google insisting on making manifest_version 2 not backwards compatible? It's a horrible way to maintain your developers and users goodwill. There doesn't seem to be any technical reason why this background/background_page change has to be made.

The main thrust of manifest_version 2 is dropping inline javascript which older versions handle with no problem. Same thing with getting rid of eval. The move to manifest_version 2 could be accomplished without breaking backwards compatibility and pissing off your developers and users. Unfortunately, you seem to enjoy making your developers and their users have trouble if they're not running a version of Chrome that's less than a week old.

Here's a solution for you: Make manifest_2.json file required for manifest_version 2 and allow us to continue to include an old manifest_version 1 file as manifest.json. Make manifest.json optional and manifest_2.json required for v2x and up. Chrome would load up manifest_2.json if it's there and on v2x and up refuse to load if it's missing. Then your developers can support old browsers and you can stop asking us "gee, why would anyone use a version that's more than a week old?"

Since you put in the breaking changes in v19 the only way you're going to get this to work is including a different manifest file for manifest_version 2 and maintain backwards compatibility.

 - Bjorn

[Zachary “Gamer_Z.” Yaro]

+1 to the idea of including both manifest types.  IMHO, that is the best solution since some people will inevitably end up stuck on older versions.

In addition, if Google wants to be able to force manifest_version 2 on us with no backward compatibility, it should first talk to the makers of popular chromium-based browsers about their update schedules.  My brother, a RockMelt user, is already encountering extensions he can no longer use because of the manifest_version.

—Zachary “Gamer_Z.” Yaro

--

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.

[PhistucK]

(The opinions in this post are solely my own.)

I think you are exaggerating here.

You can argue that they did not think this change through as much as needed, yes, but saying that they enjoy screwing developers is outright disrespectful.

You are angry, we get that. But try and calm down, they are doing their best to rectify this.

The breaking changes (as they stated) are needed for increasing the security of the extension system.

So, if they are making breaking change as it is (once, after, what, more than two years of non breaking changes (not talking about little ones like the page capture API)?), for the sake of propriety, they are also restructuring the manifest to future proof it and make it more appropriately structured for the features they add or plan to add, like background scripts, for example.

Obviously, Chrome 19 had a significant bug in the area of backward compatibility when using both of the properties (background and background_page). But it was a major bug, obviously - not an intended behavior. Someone did not plan it the right way, this happens. Granted, you would expect more from Google, but we are human and we make mistakes. I am sure it was embarrassing for the planners as well.

However, they rectified (although not fully, since Chrome 19 still exists somewhere and there is nothing they can do about it now) it in Chrome 20.

Once they figured this problem exists (or even before), they immediately changed the documentation not to encourage developers to use the new manifest version yet, if I am not mistaking.

Until Chrome 19 is completely out of the way (I guess when Chrome 21 is released, this should be the situation and if it is not, it is due to automatic update issues, which happen mostly in organizations, I believe and Google cannot control that), you better delay uploading the new manifest version.

By the time a version that features the two manifest feature you suggested (manifest_2.json) is released, the vast majority of the users (almost everyone) will already be running Chrome 20 or later, so this would result in wasted engineering time. I would not consider this a viable solution.

The only realistic solution for now, in my opinion, would be to postpone the time plan a little. Other than that, I cannot think of a better solution.

Regarding RockMeIt and the others, they are unrelated here. If they decide not to update their versions, that is not something Google should consider when they are making changes, especially security related ones. Also, as far as I know, they are not open source and they do not contribute back to Chromium (whether the patches would be accepted is unrelated here), which is more of a reason not to consider them. If they cannot keep up, they should face the consequences, or choose (or create) a different browser as their basis.

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

[Aaron Boodman]

On Wed, Jul 25, 2012 at 12:33 AM, PhistucK <phis...@gmail.com> wrote:
> Obviously, Chrome 19 had a significant bug in the area of backward
> compatibility when using both of the properties (background and
> background_page). But it was a major bug, obviously - not an intended
> behavior. Someone did not plan it the right way, this happens. Granted, you
> would expect more from Google, but we are human and we make mistakes. I am
> sure it was embarrassing for the planners as well.
>
> However, they rectified (although not fully, since Chrome 19 still exists
> somewhere and there is nothing they can do about it now) it in Chrome 20.
> Once they figured this problem exists (or even before), they immediately
> changed the documentation not to encourage developers to use the new
> manifest version yet, if I am not mistaking.

This isn't quite right. The "breaking changes" only apply if you opt
into manifest v2. Manifest v2 has existed since Chrome 18, but was
optional. We have been slowly ramping up its requiredness and recently
published our schedule for doing so:
http://code.google.com/chrome/extensions/manifestVersion.html

The problem is that that people are starting to transition to manifest
v2 now, and there are still Chrome <18 out there running in the wild.
That is three stable versions behind (or over 4.5 months)! We fix
security bugs in the browser with nearly every release, so this is not
a good situation for these people in any case.

> Until Chrome 19 is completely out of the way (I guess when Chrome 21 is
> released, this should be the situation and if it is not, it is due to
> automatic update issues, which happen mostly in organizations, I believe and
> Google cannot control that), you better delay uploading the new manifest
> version.

The problem is that with these kind of things there is usually a very
long, shallow tail. We still have people on Chrome 16, 15, 14, etc.
How long should we wait? We're looking into that now to see what, if
anything, we could do differently next time.

- a

[PhistucK]

On Wed, Jul 25, 2012 at 7:32 PM, Aaron Boodman <a...@chromium.org> wrote:

On Wed, Jul 25, 2012 at 12:33 AM, PhistucK <phis...@gmail.com> wrote:
> Obviously, Chrome 19 had a significant bug in the area of backward
> compatibility when using both of the properties (background and
> background_page). But it was a major bug, obviously - not an intended
> behavior. Someone did not plan it the right way, this happens. Granted, you
> would expect more from Google, but we are human and we make mistakes. I am
> sure it was embarrassing for the planners as well.
>
> However, they rectified (although not fully, since Chrome 19 still exists
> somewhere and there is nothing they can do about it now) it in Chrome 20.
> Once they figured this problem exists (or even before), they immediately
> changed the documentation not to encourage developers to use the new
> manifest version yet, if I am not mistaking.

This isn't quite right. The "breaking changes" only apply if you opt
into manifest v2. Manifest v2 has existed since Chrome 18, but was
optional. We have been slowly ramping up its requiredness and recently
published our schedule for doing so:
http://code.google.com/chrome/extensions/manifestVersion.html

What was not quite right there?

The context was the upgrading to new manifest version, which incorporates breaking changes that are incompatible with older versions of Chrome, like you stated, 17 and earlier.

Chrome 18 was fine in this regard, you could have had "background" and "background_page" in the same manifest, in Chrome 19, you could not.

Even though Chrome 18 was fine, like you said, Chrome 17 and earlier was not fine and still had a significant market share.

For a few weeks, the documentation (though it may not have been the stable edition) did encourage developers to upgrade already, but that was rectified.

[Aaron Boodman]

The Chrome 19 thing is a red herring.

We introduced backwards-incompatible changes in manifest v2, which was
available starting in Chrome 18. There was a minor bug in Chrome 18
that allowed one aspect of v1 manifests (background_page) to be mixed
with the v2 syntax, but that is weird so we fixed it in Chrome 19. In
general, manifest vn+1 is not compatible with vn, so extensions should
be one or the other, not both.

The question is: how long should we wait after deploying support for a
new manifest version before we can begin to start requiring its use.
The number of users on versions that can support the new version
approaches zero over time, but it never gets there. No matter what
timeframe we choose, requiring a new manifest version is going to cut
off some users.

In this case, we chose to wait three stable versions, or 4.5 months.
I'm looking into whether this number should be larger, or whether we
can do anything to minimize developer/user pain when these switches
are made.

I hope this helps clarify the issue.

- a

[Bjorn Stromberg]

Hold on, you just say you fixed in it v19, but then why did you back off that change in v20?

The issue is very much with v19. If you didn't make a hard fail with v19 we wouldn't be having these problems right now.

manifest with manifest_version 2, background_page and background: works fine in v16, v17, v18, gives a warning in v20 but won't load in v19.

manifest with manifest_version 2 and background: works fine in v18, v19, v20 but is broken in v16 and v17.

manifest with manifest_version 1 and background_page: works fine in all versions.

Given the choice, which one would you choose?

You haven't communicated clearly how manifest_version 2 is not backwards compatible. We keep hearing the term "breaking changes" but I don't see anything besides this issue with v19 and hard failing if background_page and manifest_version 2 are in the manifest.json file. What else is there?

I don't understand why you would intentionally remove backwards compatibility for all extensions. I wholeheartedly disagree with the idea that "In general, manifest vn+1 is not compatible with vn, so extensions should be one or the other, not both." If this is the direction that Google wants to take Chrome Extensions I think a lot of developers will be very unhappy.

[Aaron Boodman]

On Wed, Jul 25, 2012 at 2:14 PM, Bjorn Stromberg <bjor...@gmail.com> wrote:
> Hold on, you just say you fixed in it v19, but then why did you back off
> that change in v20?
>
> The issue is very much with v19. If you didn't make a hard fail with v19 we
> wouldn't be having these problems right now.
>
> manifest with manifest_version 2, background_page and background: works fine
> in v16, v17, v18, gives a warning in v20 but won't load in v19.
> manifest with manifest_version 2 and background: works fine in v18, v19, v20
> but is broken in v16 and v17.
> manifest with manifest_version 1 and background_page: works fine in all
> versions.
>
> Given the choice, which one would you choose?
>
> You haven't communicated clearly how manifest_version 2 is not backwards
> compatible. We keep hearing the term "breaking changes" but I don't see
> anything besides this issue with v19 and hard failing if background_page and
> manifest_version 2 are in the manifest.json file. What else is there?

The changes are all listed here:

http://code.google.com/chrome/extensions/manifestVersion.html

The ones that are most similar to background_page being removed are:

* The browser_actions key in the manifest, and the
chrome.browserActions API are gone. Use the singular browser_action
and chrome.browserAction instead.

* The icons property of browser_action has been removed. Use the
default_icon property or chrome.browserAction.setIcon instead.

* The name property of browser_action has been removed. Use the
default_title property or chrome.browserAction.setTitle instead.

* The popup property of browser_action has been removed. Use the
default_popup property or chrome.browserAction.setPopup instead.

* The default_popup property of browser_action can no longer be
specified as an object. It must be a string.

* The page_actions key in the manifest, and the chrome.pageActions API
are gone. Use the singular page_action and chrome.pageAction instead.

* The icons property of page_action has been removed. Use the
default_icon property or chrome.pageAction.setIcon instead.

* The name property of page_action has been removed. Use the
default_title property or chrome.pageAction.setTitle instead.

* The popup property of page_action has been removed. Use the
default_popup property or chrome.pageAction.setPopup instead.

* The default_popup property of page_action can no longer be specified
as an object. It must be a string.

All of these features have the same issue - that they work in Chrome
18 with manifest v1, but don't work with manifest v2. The only
difference between them and background_page is that they are less
commonly used.

> I don't understand why you would intentionally remove backwards
> compatibility for all extensions. I wholeheartedly disagree with the idea
> that "In general, manifest vn+1 is not compatible with vn, so extensions
> should be one or the other, not both." If this is the direction that Google
> wants to take Chrome Extensions I think a lot of developers will be very
> unhappy.

Our preference is also to never make breaking API changes. However, in
some rare cases we must do so for security reasons. For example, we
had to make a breaking change to introduce the CSP features in
manifest v2. And since manifest v2 is something developers have to opt
into, we took the opportunity to make other minor API changes at the
same time. This is important, so that we can eventually simplify our
codebase by removing support for these old cases.

Manifest v2 is the first major breaking change we have ever made. And
even in this case we are rolling out the changes over more than 1 year
so that developers have time to adapt.

The one thing we failed to take into account is that a large absolute
(if small in percentage) number of users would be on much older
versions of Chrome. We can't wait forever for these folks to update,
but there is probably something we can do so that we don't just break
them. That's what we'll be looking into. If you are interested please
'star' this bug: crbug.com/138740.

- a

[Zachary “Gamer_Z.” Yaro]

I personally think it is fine that these backward-incompatible changes were made, but then I think devs should be able to have separate manifest.json and manifest_v2.json files or something like that.  Then older Chromium versions would ignore the v2 manifest and newer versions could use the highest available number they support.

—Zachary “Gamer_Z.” Yaro

[Jeffrey Yasskin]

I don't know much about the infrastructure here, but I wonder if it
would make sense for the web store to avoid upgrading extensions for
old versions of chrome. For example, if an extension is marked with
manifest v2 and a chromium older than v18 asks for upgrades to it,
that extension could appear to have been deleted, stranding users on
an old version until they upgrade their browser. Users who actually
visit the web store should get notified that the extension needs them
to upgrade their browser.

Would that work for LastPass? Is is sensible from the extensions point of view?

Jeffrey

On Tue, Jul 24, 2012 at 9:35 AM, Drew <zit...@gmail.com> wrote:

>>>> > 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.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Chromium-extensions" group.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/-/UlpZBsFft_EJ.
>>>

>>> 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.
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Chromium-extensions" group.
> To view this discussion on the web visit

> https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/-/3Ooe1vGrpQEJ.
>
> To post to this group, send email to chromium-...@chromium.org.

> To unsubscribe from this group, send email to

> chromium-extens...@chromium.org.

[Abraham Williams]

To keep existing users from getting a broken extension you can use minimum_chrome_version in your manifest. They will no longer get updates until they update their browser, however.

https://code.google.com/chrome/extensions/trunk/manifest.html#minimum_chrome_version

Abraham
--
Abraham Williams | abrah.am | abraham+ | addvocate.co

@abraham | github.com/abraham | blog.abrah.am
This email is: [ ] shareable [x] ask first [ ] private.

On Tue, Jul 24, 2012 at 10:32 AM, Drew <zit...@gmail.com> wrote:

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/-/Ih1mVGKLX1IJ.

To post to this group, send email to chromium-...@chromium.org.
To unsubscribe from this group, send email to chromium-extens...@chromium.org.

[Nathan Wray]

Being able to host multiple revisions of an extension, each targeting a different browser version, seems like it would be useful here if supposed correctly by the play store. 

I suppose if you submitted it as different extensions ("XXX for Chrome 20" , "XXX for Chrome 16") might work but you'd lose having them appear as the same extension in terms of reviews etc.  And upgrades would be hosed. 

[Zachary “Gamer_Z.” Yaro]

I feel like that is likely where we end up, similar to the way some Android apps have separate 1.x/2.x versions.

—Zachary “Gamer_Z.” Yaro

[Aaron Boodman]

On Tue, Jul 24, 2012 at 10:46 AM, Jeffrey Yasskin <jyas...@chromium.org> wrote:
> I don't know much about the infrastructure here, but I wonder if it
> would make sense for the web store to avoid upgrading extensions for
> old versions of chrome. For example, if an extension is marked with
> manifest v2 and a chromium older than v18 asks for upgrades to it,
> that extension could appear to have been deleted, stranding users on
> an old version until they upgrade their browser. Users who actually
> visit the web store should get notified that the extension needs them
> to upgrade their browser.
>
> Would that work for LastPass? Is is sensible from the extensions point of view?

Yup, same thing we came up with on a separate thread. See
crbug.com/139062 and crbug.com/139064.

- a

[John J Barton]

Another gotcha, we can no longer have one extension be a library for another extension, instead we have to duplicate code.

Refused to load the script 'chrome-extension://fkhgelnmojgnpahkeemhnbjndeeocehc/atopwi/devtoolsAdapter/DebuggerProtocol.js' because it violates the following Content Security Policy directive: "script-src 'self' chrome-extension-resource:".

jjb

[Adam Barth]

Can you try adding this to your manifest:

  "content_security_policy": "script-src 'self' chrome-extension://fkhgelnmojgnpahkeemhnbjndeeocehc chrome-extension-resource: ; object-src 'self' "

That should whitelist the other extension as a source of script.

Adam

--

You received this message because you are subscribed to the Google Groups "Chromium-extensions" group.

[John J Barton]

Yes that works thanks!

I opened a bug against the docs:

https://code.google.com/p/chromium/issues/detail?id=139443

jjb

[jammm]

can you please update the page, giving exact dates, for at least the "first quarter" section of the page:

https://developer.chrome.com/extensions/manifestVersion.html 

if not the others too?

?

On Monday, July 9, 2012 3:51:58 PM UTC+1, Aaron Boodman wrote:

There's the "changes between 1 and 2" section on the bottom of this page:

http://code.google.com/chrome/extensions/manifestVersion.html

It's not a guide, but it lists all the things that change. The biggest
changes are the first two items: content_security_policy and
web_accessible_resources.

HTH,

- a

On Mon, Jul 9, 2012 at 2:35 AM, boxhead <andy....@gmail.com> wrote:
> I'm trying to upgrade my chrome extension from manifest version 1 to
> manifest version 2 but I can't find a migration guide, is there one?
>
> Cheers
>
> --
> You received this message because you are subscribed to the Google Groups
> "Chromium-extensions" group.
> To view this discussion on the web visit
> https://groups.google.com/a/chromium.org/d/msg/chromium-extensions/-/RDmTqgX86AUJ.
> To post to this group, send email to chromium-...@chromium.org.
> To unsubscribe from this group, send email to

> chromium-extensions+unsub...@chromium.org.

[Joe Montana]

Hey. So I found this group after searching for a way to switch manifest versions. I'm not a developer nor a programmer, but I do have an extension that simply won't work. I'm positive this is the problem. The extension is a javascript file and as far as I know there is no json file to go with it. How would I make my extension work? I'm sorry to trouble you but I am in a bit of a pickle and I'm trying everything I can. I've attached to you the JS file. I attempted to just simply add "

{

  ...,

  "manifest_version": 2,

  ...

}"  

to the coding but it didn't work.