How to get the extension icon data in Manifest V3

[Hao Nguyen]

Hi,

I am trying to get the extension icon using the management API: https://developer.chrome.com/docs/extensions/reference/management/#type-IconInfo. The icons returned are in the format chrome://extension-icon/*. In Manifest V2, I could make an Axios GET to that URL to get the actual payload of the icon and upload it to a remote server. However, in Manifest V3, making a Fetch API call to URL scheme "chrome" is not supported. Is there anyway to get the base64 encoding for all extension icons that are currently installed on a device?

Thanks,

Hao

[hrg...@gmail.com]

The only way I know you can get those URLs is by using XmlHttpRequest. This works in web workers too but not in a service worker, so you can't use it in MV3.

[Simeon Vincent]

Thanks for raising this, Hao.

We intend to provide extensions with a way to fetch extension icons from within a background service worker, but the exact mechanism is unclear at the moment. After a quick conversation with the eng team, the two options that look most promising at the moment are:

• Expand fetch() to support chrome:// (as well as file://) schemes in extensions
• Provide support for extension icons as part of the new favicon API

It's also possible we may explore other options or a combination. At this point it's simply too early to say. I've opened crbug.com/1257227 to track this issue.

Simeon - @dotproto

Chrome Extensions DevRel

[Hao Nguyen]

Hi, is there any ETA on this issue? It has been two months. I am building a new extension and this is preventing me from using Manifest V3.

Thanks,

Hao

[Simeon Vincent]

Can you describe your extension in more detail and explain how this is blocking you? Depending on your user experience and how this data is being used, there may be a few different ways you can work around this limitation.

Simeon - @dotproto

Chrome Extensions DevRel

[Hao Nguyen]

I am building an extension that allows an admin to track and manage Chrome extensions installed on their team members' browsers. Being able to see the icons of the extensions would make it easier to recognize the Chrome extensions more quickly. It does not necessarily block me, but it just makes the user experience significantly worse.

[Vladimir Yankovich]

It seems to me that you can rescore all the icons from the store and then match them by ID.

[Hao Nguyen]

There are extensions that are not publicly available from the Web Store: e.g., those that are installed locally or privately listed.

[Cuyler Stuwe]

Hao, if it makes the user experience suck, please allow yourself to express it as a “blocker”. That’s just the lingo these guys understand to refer to major gaps in the new platform; It doesn’t mean what you might be accustomed to it meaning in Scrum/etc.

--
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/c64a1729-9196-4343-8ced-acf69b02a88en%40chromium.org.

[Simeon Vincent]

I am building an extension that allows an admin to track and manage Chrome extensions installed on their team members' browsers. Being able to see the icons of the extensions would make it easier to recognize the Chrome extensions more quickly. It does not necessarily block me, but it just makes the user experience significantly worse. - Hao

Thanks for that context. Based on this it sounds like there's not much opportunity for your extension to show a window, popup, or other extension UI that you could use to send images back to your server. If you had something like a popup that users would occasionally invoke, you could use that temporary chrome-extension://<ID> page context to asynchronously retrieve extension icons and push them to your server shortly after page load. 

We haven't quite settled how to handle chrome://extension-icon/* URLs in Manifest V3. This could be rolled into the updates we're working on for favicons (i.e. chrome://favicon URls) or handled separately. Until we have the design ironed out, implemented, and shipped you won't be able to get extension icon data in the etension's service worker.

In the meantime, one idea that leaps to mind is to use either the Tabs or Windows API to create a short lived temporary context. Neither approach will require any new permissions.

One approach I've seen existing Manifest V2 extension use for similar purposes is use the Tabs API to create a new background tab and have the page's script immediately close the tab once your work is done. If the user has multiple windows open, this could be further refined to open the tab in a window that the user doesn't currently have focused in order to minimize potential user distraction.

function spawnSyncIconsPage() {

chrome.tabs.create({

url: chrome.runtime.getURL('sync-icons.html'),

active: false,

});

}

Alternatively, you could use the Windows API to spawn a new minimized window and have the page's script close the window once your work is complete.

function spawnSyncIconsPage() {

return chrome.windows.create({

url: chrome.runtime.getURL('sync-icons.html'),

state: chrome.windows.WindowState.MINIMIZED,

});

}

Both approaches have the potential to cause a flash on the user's screen, either in the tab bar or in the toolbar/dock/application launcher. There are some other strategies you may want to consider in order to minimize the chances the user will see this. For example, you could treat this sync work as a periodic job that runs at most once every N days, use the Idle API (and permission) to detect when the device is locked or idle, or only perform a sync when an extension is newly installed (Management API and permission).

chrome.management.onInstalled.addListener((info) => {

spawnSyncIconsPage();

});

Simeon - @dotproto

Chrome Extensions DevRel

[hrg...@gmail.com]

Simeon Vincent wrote:

One approach I've seen existing Manifest V2 extension use for similar purposes is use the Tabs API to create a new background tab

Did you meant to say "Manifest V3" here?

MV2 extensions have a background page already so there's no need to open another one.

[Simeon Vincent]

Nope, I meant to say Manifest V2.

While you and I may be familiar with this kind of use of background pages, your average extension dev likely isn't. In this particular case, I suspect that the extension developer didn't even think of the background script as being run in a "page," so they found a creative solution to their problem. That or they ran into something like CORS issues and found this solution easier/safer to hack together than trying to relax headers with webRequest.

Simeon - @dotproto

Chrome Extensions DevRel

[Cuyler Stuwe]

It’s pretty depressing that my clever-but-horrible-for-the-user workaround of “using a minimized window” seems to be the standard workaround now.

FWIW I discovered a while back that a popup window created as minimized actually doesn’t appear whatsoever… but only on Mac. So we can make sane background process contexts that don’t bother the user… but only if we can convince them to buy Apple products. It would be nice if that behavior was consistent across all 3 main desktop OSes.

--
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/CAFY0HLMk-o9Ps_niV8p7GC_1vLE6_wAwFeE920pMXBnWehnTzg%40mail.gmail.com.

[Simeon Vincent]

FWIW I discovered a while back that a popup window created as minimized actually doesn’t appear whatsoever… but only on Mac. - Cuyler

That's not quite accurate. Even if you spawn a window using a data URL like "data:text/html,<script>window.close()</script>", there will be a ~1 second animation where the window appears in and is removed from the dock. The only way this is "invisible" to the user is if the user has their dock hidden. In that case, the same could be said for Windows or Linux users that hide the equivalent parts of their system UI. 

Simeon - @dotproto

Chrome Extensions DevRel

[hrg...@gmail.com]

there will be a ~1 second animation where the window appears in and is removed from the dock.

If I'm not mistaken, windows of the same type are grouped under the same icon in the dock, correct?

[Simeon Vincent]

If I'm not mistaken, windows of the same type are grouped under the same icon in the dock, correct? - Hrg

That's true if you have the Minimize windows into application icon setting enabled, but I'm like 70% sure that this setting is disabled by default in a fresh macOS Monterey installation. Even then, the minimized windows are visible when using Mission Control's "Application windows" feature. 

Simeon - @dotproto

Chrome Extensions DevRel