For these of you not accustomed to the world of net extension growth, a storm is brewing with Chrome. Google will cease help for manifest model 2, which is what the overwhelming majority of net extensions use. Manifest model 3 sees many adjustments however the largest change is transferring from persistent background scripts to service staff. This…is…a…large…change.
Adjustments from manifest model 2 to model 3 embrace:
- Going from persistent background script to a service employee that may die after 5 minutes
- No use of
<iframe>parts or different DOM APIs from the service employee - All APIs have change into Promise-based
- Restrictions on content material from a CSP perspective
One operate that net extensions usually make use of is executing scripts upon every new web page load. For an online extension like MetaMask, we have to present a worldwide window.ethereum for dApps to make use of. So how can we try this with manifest model 3?
As of Chrome v102, builders can outline a world property with a worth of remoted or foremost (within the web page) for content material scripts. Whereas builders ought to outline content_scripts within the extension’s manifest.json file, the foremost worth actually solely works (resulting from a Chrome bug) once you programmatically outline it from the service employee:
await chrome.scripting.registerContentScripts([
{
id: 'inpage',
matches: ['http://*/*', 'https://*/*'],
js: ['in-page.js'],
runAt: 'document_start',
world: 'MAIN',
},
]);
Within the instance above, in-page.js is injected and executed inside the primary content material tab each time a brand new web page is loaded. This in-page.js file units window.ethereum for all dApps to make use of. If the world is undefined or remoted, the script would nonetheless execute however would accomplish that in an remoted surroundings.
Manifest model 3 work is kind of the slog so please hug your closest extension developer. There are various enormous structural adjustments and navigating these adjustments is a brutal push!
