Is it still possible to publish the v2 extension in the chrome store, at least in exceptional cases?

[anton]

As far as I know, they stopped being accepted into the store in January 2022, and starting from June 2023 they were supposed to stop accepting updates for existing extensions with such a manifest. As of January 2024, support for such extensions was planned to be completely discontinued, after having been delayed several times already. However, I don’t know whether this eventually started or not, since for example today I saw an extension in the store that was last updated in 2016.

When I started making my extension, I still didn’t know that support for manifest v2 was ending. As a result, this extension takes advantage of a feature that is available in v2, but which is not yet available in v3. I suggested it in the issue tracker (old link | new link), but it looks like we'll still have to wait a long time for this feature to be implemented in v3, like several years, maybe even a decade. And I would like to understand if I have any other option other than to wait until they add the necessary feature in v3.

[Patrick Kettner]

Hello Anton,

The timelines you mentioned are out of date. New MV2 extensions did cease to be accepted on the store in 2022, but you can still publish updates to existing MV2 extensions.

patrick 

On Mon, Feb 5, 2024 at 5:06 AM anton <antonm...@gmail.com> wrote:

As far as I know, they stopped being accepted into the store in January 2022, and starting from June 2023 they were supposed to stop accepting updates for existing extensions with such a manifest. As of January 2024, support for such extensions was planned to be completely discontinued, after having been delayed several times already. However, I don’t know whether this eventually started or not, since for example today I saw an extension in the store that was last updated in 2016.

When I started making my extension, I still didn’t know that support for manifest v2 was ending. As a result, this extension takes advantage of a feature that is available in v2, but which is not yet available in v3. I suggested it in the issue tracker (old link | new link), but it looks like we'll still have to wait a long time for this feature to be implemented in v3, like several years, maybe even a decade. And I would like to understand if I have any other option other than to wait until they add the necessary feature in v3.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/c9213aff-0a9a-4655-9a0f-d0cc45b7c29cn%40chromium.org.

[anton]

Well, I already realized that the terms are outdated, and that in normal cases extensions are not accepted. And I have exactly the new extension. But is it possible to somehow do this exceptionally?

And tell me what other options there might be? Maybe I'm missing something, and filtering by frameId in declarativeNetRequest is actually possible? I also thought in the direction of webRequest (this was what was initially done in the V2 manifest), but in version 3 webRequestBlocking is not available for use, and that’s what I need (since in onHeadersReceived you need to return a BlockingRequest object so that you can modify Headers ). However, the documentation of webRequest also says about certain extensions installed by the policy, and that they can use webRequestBlocking. However, nothing more is said about this “policy setting”, and I did not find information about it. Do you know anything about this? Is it possible to somehow use this way?

P.S. Sorry for my bad english, i'm using google translate.

понедельник, 12 февраля 2024 г. в 21:21:04 UTC+6, Patrick Kettner:

[Patrick Kettner]

Hello Anton,

Ты говоришь по-английски лучше, чем я говорю по-русски

There is no way to publish a new MV2 extension. Installed by policy means the the extension is installed via enterprise policy.

[anton]

Is there any workaround to make the declarativeNetRequest rule filter by iframe id?

четверг, 15 февраля 2024 г. в 20:53:17 UTC+5, Patrick Kettner:

[Patrick Kettner]

Hi Anton,

That is not currently supported. Would you be able to share more information about the usecase?

[anton]

I'm making a link preview extension, the point is to open the link not in a new tab, but in a subwindow in this tab. I display the previewed page in an iframe. In this case, the host of the main and viewed pages may differ, that is, the cross-origin x-frame problem arises. For example, if the main page is Google with the results of a query, and the viewed page is one of the results. To solve the problem, you need to remove x-frame headers, but if you do not filter frames by those that were opened by my extension and everyone else, then the end user will be at risk of a clickjacking attack. When manifest v2 was used, this was solved by filtering by frameId, but on v3 there is no such option

четверг, 2 мая 2024 г. в 08:42:23 UTC+5, Patrick Kettner: