Deutsch
Francais
Nederlands
Svenska
Norsk
Dansk
Suomi
Espanol
Italiano
Portugues
Magyar
Polski
Cestina
Русский
Manifest V3 toi merkittäviä muutoksia taustaskriptien käsittelyyn selaimen laajennuksissa, erityisesti siirtymällä perinteisistä taustasivuista palvelutyöntekijä-arkkitehtuuriin. Aiemmin, Manifest V2:ssa, taustaskriptit toimivat "persistentteina" taustasivuina, jotka pyörivät jatkuvasti niin kauan kuin selain oli auki. Tämä mahdollisti pitkään käynnissä olevien toimintojen, kuten web-pyyntöjen ja ajastettujen tehtävien hallinnan ilman keskeytyksiä. Manifest V3:ssa palvelutyöntekijät ovat sen sijaan ei-persistentejä, eli ne aktivoituvat vain tapahtumien käsittelyyn ja lopettavat toimintansa sen jälkeen, mikä tuo tehokkuutta resurssien käyttöön, mutta rajoittaa pitkäkestoisia prosesseja.
Palvelutyöntekijät eivät enää pääse käsiksi DOM-objekteihin tai ikkunan (window) olioon, mikä sulkee pois monia aiemmin suoraan käytettävissä olleita selain-API:ta. Tämä tarkoittaa esimerkiksi sitä, että dokumenttia tai elementtejä ei voi muokata taustaskriptistä käsin, eikä suoranaista käyttöliittymän renderöintiä voi toteuttaa ilman apukirjastoja tai erillisiä mekanismeja kuten OffscreenCanvas. Myös localStorage ja sessionStorage, sekä evästeiden käsittely ovat poissa käytöstä, ja XMLHttpRequest on korvattu fetch()-kutsulla, mikä pakottaa kehittäjät muuttamaan perinteisiä verkkopyyntöjen käsittelytapoja.
Palvelutyöntekijöiden rajoitukset ulottuvat myös ajastimiin: setTimeout() ja setInterval() eivät ole enää luotettavia, sillä työntekijä voi sulkeutua ennen aikataulutettua toimintoa. Tämä tarkoittaa, että esimerkiksi toistuvien tehtävien toteuttamiseen on käytettävä chrome.alarms-API:a, joka kuitenkin asettaa vähimmäisrajaksi minuutin, tehden tarkat ja tiheät ajastukset haastaviksi. Lisäksi avoimet verkkoyhteydet, kuten WebSocketit, saatetaan katkaista, koska palvelutyöntekijän elinkaari ei ota niitä huomioon pysyvyyden määrittelyssä.
Merkittävä ero myös liittyy tapahtumien käsittelyyn: palvelutyöntekijä herää aina tietyn tapahtuman vuoksi ja suorittaa yhden tapahtumasilmukan kierroksen. Mikäli kyseisen tapahtuman käsittelijää ei ole määritelty tai se puuttuu, tapahtuma voi jäädä käsittelemättä. Tämä asettaa haasteita laajennuksen vakaudelle ja virheenkäsittelylle, mikä vaatii huolellista tapahtumien hallintaa.
Manifest V3:n myötä taustaskriptit yksinkertaistuivat: aiemmat usean skriptin taustasivut korvattiin yhdellä palvelutyöntekijäskriptillä, jota voidaan myös käyttää JavaScript-moduulina. Tämä parantaa koodin modulaarisuutta ja selkeyttä, mutta edellyttää myös, että kehittäjät suunnittelevat skriptinsä uudelleen yhteen moduuliin sopiviksi.
Palvelutyöntekijöiden ensisijainen rooli selainlaajennuksissa on hallita laajan kirjon tapahtumia, joita selain ja WebExtensions API lähettävät. Toisin kuin verkkosivujen palvelutyöntekijät, jotka ensisijaisesti toimivat välimuistina ja mahdollistavat offline-käytön sekä PWA-toiminnallisuudet, laajennusten palvelutyöntekijöiden tehtäväkenttä painottuu tapahtumien reagointiin ja resurssien hallintaan. Tämä on seurausta siitä, että laajennusten resurssit ovat jo valmiiksi selainympäristössä ja eivät tarvitse verkkovälimuistia.
Lisäksi palvelutyöntekijät eivät enää tue sulkemistapahtumia, kuten runtime.onSuspend tai runtime.onSuspendCanceled, mikä vaikeuttaa siivoamislogiikkaa laajennuksissa. Kehittäjien on näin löydettävä uusia keinoja hallita palvelutyöntekijän elinkaarta ja varmistaa resurssien asianmukainen vapauttaminen.
Näiden muutosten ymmärtäminen on olennaista laajennusten kehittäjille, sillä ne vaikuttavat ratkaisevasti laajennuksen suorituskykyyn, luotettavuuteen ja toimintatapaan. On tärkeää huomioida, että vaikka palvelutyöntekijöiden ei-persistenssi voi aluksi tuntua rajoittavalta, se mahdollistaa tehokkaamman resurssien käytön ja paremman skaalautuvuuden nykyaikaisissa selaimissa. Toisaalta kehittäjien on suunniteltava sovelluksensa niin, että ne toimivat luotettavasti palvelutyöntekijän rajoitetussa ympäristössä, hyödyntäen muun muassa chrome.alarms-API:n tarjoamia ajastettuja tapahtumia ja modulaarista koodirakennetta.
Erityisen tärkeää on ymmärtää, että palvelutyöntekijän kyvyttömyys käyttää DOM:ia ja perinteisiä selainobjekteja tarkoittaa, että kaikki käyttöliittymään liittyvä logiikka on siirrettävä aktiivisiin sisältöskripteihin tai muihin laajennuksen osiin. Tämä jakaa vastuun eri osien kesken ja korostaa laajennuksen sisäisen viestinnän merkitystä, jonka toteutuksessa käytetään asynkronista postMessage()-viestintää tai WebExtensions API:n viestintämenetelmiä. Lisäksi palvelutyöntekijän tapahtumapohjainen luonne edellyttää, että laajennuksen tilanhallinta ja toiminnallisuus mukautetaan siihen, että palvelutyöntekijä aktivoituu vain tarpeen vaatiessa ja ei pysy jatkuvasti käynnissä.
Miten Chrome-laajennukset käsittelevät kontekstivalikoita ja välilehtiä?
Chrome-laajennusten kehittämisessä keskeinen osa on käyttöliittymän ja toiminnallisuuden integrointi selainympäristöön. Yksi yleisimmistä ominaisuuksista on kontekstivalikon muokkaaminen ja sen tapahtumien käsittely, jolloin käyttäjä voi esimerkiksi tallentaa valittua tekstiä, sivun URL-osoitteen tai linkin kohteen muistiinpanoihin. Tämä saavutetaan luomalla kontekstivalikkoon eri vaihtoehtoja, joilla on yksilölliset tunnisteet (id), joiden perusteella laajennus osaa erotella, mitä sisältöä käyttäjä on halunnut tallentaa.
Kontekstivalikon klikkaustapahtumia kuunnellaan chrome.contextMenus.onClicked -kuuntelijalla. Tapahtuman tiedoista saadaan valittu elementti, kuten teksti, sivun URL tai linkin osoite, ja se liitetään muistiinpanojen listaan paikallisessa tallennustilassa. Tämä mahdollistaa notepad-tyyppisen toimintamallin selaimen sisällä, jossa muistiinpanoja voi tallentaa ja hakea myöhemmin eri sivuilta tai valituista sisällöistä.
Lisäksi selainlaajennusten hallinnassa on keskeistä välilehtien (tabs) käsittely. Tab Manager -tyyppinen laajennus voi toteuttaa reaaliaikaisen avoinna olevien välilehtien seurannan ja hallinnan. Tällainen laajennus hyödyntää chrome.tabs-APIa, joka mahdollistaa välilehtien listauksen, aktiivisen välilehden valinnan, sulkemisen sekä muutosten seuraamisen. Näin saadaan aikaan dynaaminen käyttöliittymä, joka päivittyy automaattisesti aina, kun käyttäjä avaa, sulkee tai muokkaa välilehtiä.
Tab Manager toimii usein erillisessä sivupaneelissa, joka on globaalisti käytössä kaikissa ikkunoissa ja välilehdissä, mikä poistaa tarpeen monimutkaiselle tilanhallinnalle. Paneeli kuuntelee välilehtien luomista, poistamista ja päivityksiä sekä soveltaa suodatuksia käyttäjän antaman hakukentän perusteella. Tämä takaa sen, että käyttäjä näkee aina ajan tasalla olevan ja suodatetun listan.
Manifest-tiedostossa määritellään tarvittavat oikeudet kuten "tabs" ja "sidePanel", sekä sivupaneelin oletuspolku. Palvelutyöntekijä (service worker) hoitaa taustatoiminnot, kuten sivupaneelin avaamisen laajennuksen kuvakkeen klikkauksesta.
Tämän lähestymistavan etuna on, että välilehtien hallinta tapahtuu ilman erillistä taustaskriptiä, mikä yksinkertaistaa arkkitehtuuria. Välilehtien tila haetaan chrome.tabs.query -kutsulla, ja suodatus- sekä renderöintitoiminnot ovat selkeästi eroteltu, jolloin käyttöliittymä on responsiivinen ja helposti ylläpidettävä.
On tärkeää ymmärtää, että selainlaajennusten toiminnallisuus perustuu tiiviiseen vuorovaikutukseen selaimen tarjoamien API-rajapintojen kanssa. Koko järjestelmä rakentuu tapahtumapohjaisuudelle, jossa eri tapahtumat laukaisevat päivityksiä käyttöliittymässä tai tallennustilassa. Näin voidaan luoda responsiivisia, käyttäjän tarpeisiin joustavasti mukautuvia työkaluja, jotka parantavat selauskokemusta merkittävästi.
Lisäksi selainlaajennusten testaaminen on olennainen osa kehitystä. Toimintojen, kuten muistiinpanojen tallennuksen, valitun tekstin tallennuksen, URL-osoitteiden käsittelyn sekä välilehtien hallinnan, on toimittava saumattomasti ja virheettömästi. Testauksessa kannattaa kiinnittää huomiota myös siihen, että tiedot säilyvät istuntojen yli ja että käyttöliittymä reagoi oikein eri käyttötilanteissa.
On huomioitava, että selainlaajennuksia kehitettäessä täytyy myös hallita oikeuksien myöntäminen ja suoritusympäristön rajoitukset, jotta laajennus toimii turvallisesti ja tehokkaasti ilman liiallista resurssien kulutusta. Tämä tarkoittaa esimerkiksi, ettei taustaskriptiä kannata käyttää turhaan, ja että käyttöoikeudet määritellään vain tarpeelliseen toiminnallisuuteen.