In Manifest V3
// manifest.json
{
"permissions": ["favicon"]
}
// utils.js
function getFaviconUrl(url) {
return `chrome-extension://${chrome.runtime.id}/_favicon/?pageUrl=${encodeURIComponent(url)}&size=32`;
}
// or
function getFaviconUrl(url) {
let faviconUrl = new URL(`chrome-extension://${chrome.runtime.id}/_favicon/`);
faviconUrl.searchParams.append('pageUrl', url); faviconUrl.searchParams.append('size', '32');
return faviconUrl.href;
}
First, I stand on the developer's point of view, regardless of its internal implementation.
The old function getFaviconUrl() is a little easier than the new one.
Second, if browser supply a function to do it, e.g. chrome.runtime.getFaviconUrl(url, size) , developers don't need to pay attention to implementation details and don't have to change code from MV2 to MV3, MV4, MV5...
But what I want to express is not this little change in the code. What I want to say is that it is very important for developers to keep the platform stable and backward compatible. I hope that my extensions can be used by users for a long time without modification. If I have an accident or die one day, users can continue to use them for many years. If a platform must be overhauled every few years or has a lot of incompatible changes that require developers to make a lot of changes to make it continue work, this means that developers' time and lives are worthless (developers' time is not valued and is not a priority), and many good extensions will disappear in short years.
For example, the operating system binary executable file format, Java JDK and Java VM are very stable, very old programs can be run without modification. In addition, the standardized Web API is also very stable, and browsers are very cautious about making incompatible changes. However, the extension API is not standardized and is not treated as Web standards.
I think the easiest way for developers to do this(show favicon images) is backwards compatibility, so that developers do not need to modify anything and do not need to learn anything new. If developers need new features that are not supported by old APIs, then just design a new API for the new feature, so that the developers who need these new features will be happy to learn it.