Chrome vs Firefox vs Edge vs Safari: čo sme sa naučili pri vydaní 9 rozšírení prehliadača

Na papieri by moderné rozšírenie prehliadača malo byť takmer automaticky multiplatformovým produktom. Chrome, Firefox, Edge a Safari podporujú WebExtensions, používajú podobný súbor manifest.json a ponúkajú porovnateľné mechanizmy: content scripty, úložisko, komunikáciu medzi kontextmi, tlačidlo na paneli nástrojov a stránky nastavení.

Je to pravda, ale len do určitej miery.

Po vydaní a portovaní deviatich rozšírení POLPROG už vieme, že zdieľaný kód neznamená jeden totožný produkt. Väčšinu obchodnej logiky možno zdieľať, ale správanie prehliadača, životný cyklus procesu na pozadí, rozhranie, oprávnenia, balenie a kontrola v obchode zostávajú samostatnými problémami.

Portfólio zahŕňa:

• AutoScroll,
• ClickClean,
• DevScope,
• LeakLens,
• LoopIt,
• Loudly,
• OneMoreJump,
• TabZoo,
• TubePilot.

Nie je to deväť kópií rovnakého typu doplnku. Súbor zahŕňa nástroje pre video, zosilnenie zvuku, súkromie, čistenie údajov, vývoj, správu kariet a ľahkú hru. Problémy sa preto neobmedzovali na jedno API. Týkali sa service workerov, popupov, content scriptov, zvuku, úložiska, ikon, oprávnení a procesu publikovania.

POLPROG verejne udržiava deväť produktov typu rozšírenie, ktoré boli pôvodne vydávané najmä pre Chrome a Firefox a neskôr portované aj na Edge a Safari. [1][2]

Tento článok nie je laboratórny benchmark. Od prvého commitu sme nemerali každú minútu strávenú v jednotlivých obchodoch, preto nebudeme tvrdiť, že Safari stojí presne 2,7-krát viac než Chrome alebo že je 94 % kódu zdieľaných. To by bola falošná presnosť.

Môžeme však ukázať niečo užitočnejšie: ktoré predpoklady sa ukázali ako chybné, kde sa objavili skutočné poruchy a ako by sme dnes navrhli celý proces od začiatku.

Štyri prehliadače, štyri rôzne úlohy

Platforma	Úloha v našom procese	Najväčšia výhoda	Najčastejšia pasca
Chrome	Hlavný základ kompatibility s Manifest V3	Najširšia dokumentácia a najväčší trh s rozšíreniami	Uspávaný service worker a prísne požiadavky na oprávnenia
Edge	Port založený na Chromium	Malý rozdiel kódu oproti Chrome	Samostatný Partner Center, metadáta a certifikácia
Firefox	Nezávislá implementácia WebExtensions	Dobre odhaľuje predpoklady závislé od Chromium	Rozdiely API a manifestu, podpis a požiadavky na zdrojové kódy
Safari	Samostatný produkt v ekosystéme Apple	Prístup k používateľom macOS, iOS a iPadOS	Xcode, kontajnerová aplikácia, podpis a iné správanie runtime

MDN zdôrazňuje, že cieľom WebExtensions je umožniť doplnkom fungovať v hlavných prehliadačoch po minimálnych zmenách, zároveň však dokumentuje významné rozdiely medzi Chrome, Firefoxom a Safari v dostupnosti API, manifestoch a spracovaní asynchrónnych operácií. [7][8]

To dobre zodpovedá našej skúsenosti. „Minimálne zmeny“ sú realistické pri jednoduchom doplnku. Čím viac rozšírenie zasahuje do stránky, médií, životného cyklu kariet alebo procesu na pozadí, tým menej užitočné je slovo „minimálne“.

Lekcia 1: jedna codebase áno, jeden manifest nie nevyhnutne

Najlepším východiskovým bodom je zdieľaná logika s oddelenými konfiguráciami buildu.

V praxi sa najlepšie osvedčila štruktúra, v ktorej sa zdieľajú:

• logika funkcií,
• dátové modely,
• moduly storage,
• validácia,
• väčšina rozhrania popupu a nastavení,
• lokalizácie,
• unit testy.

Oddelené zostávajú:

• varianty manifestu,
• identifikátory doplnkov,
• minimálne verzie prehliadačov,
• konfigurácia backgroundu,
• časť oprávnení,
• ikony a store assets,
• balenie,
• podpis,
• publikačné skripty.

Neznamená to udržiavať štyri ručne kopírované adresáre. To rýchlo vedie k rozdielom. Lepším modelom sú zdieľané zdroje plus generátor alebo konfiguračná vrstva, ktorá pripraví samostatný artefakt pre každú platformu.

Firefox napríklad vyžaduje vlastné nastavenia v browser_specific_settings. V Manifest V3 je identifikátor rozšírenia potrebný na podpis a od novembra 2025 musia nové doplnky odosielané do AMO deklarovať aj nastavenia týkajúce sa zberu údajov. [9]

Safari zase vyžaduje projekt Xcode a aplikáciu obsahujúcu rozšírenie. Apple poskytuje konvertor WebExtension, ale výsledok je stále potrebné považovať za natívny projekt určený na podpísanie a distribúciu cez App Store. [3][4]

Spoločný manifest by teda bol len zdanlivou úsporou. Niekoľko malých a explicitných rozdielov sa udržiava ľahšie než jeden súbor plný výnimiek a podmienok.

Lekcia 2: Manifest V3 nezjednotil správanie prehliadačov

Manifest V3 zlepšil časť kompatibility a usporiadal model rozšírení, ale nevytvoril jeden identický runtime.

Najviditeľnejšou zmenou v Chrome je nahradenie trvalých stránok na pozadí extension service workerom. Google ho opisuje ako centrálny handler udalostí spúšťaný podľa potreby. Proces môže byť ukončený a premenné uložené iba v pamäti s ním zmiznú. [5][6]

To má priame dôsledky.

Kód ako:

let activeSessions = new Map();
let currentTab = null;
let isEnabled = false;

nemôže byť jediným zdrojom pravdy, ak sú tieto údaje potrebné po opätovnom spustení service workera.

Stav je vhodné rozdeliť do troch skupín:

1. dočasný stav, ktorý môže bezpečne zmiznúť;
2. stav rekonštruovateľný z aktívnych kariet alebo DOM;
3. trvalý stav, ktorý musí byť uložený do storage.local, storage.session alebo iného vhodného miesta.

Rovnako dôležitá je registrácia listenerov. Chrome odporúča deklarovať handlery udalostí v globálnom scope skriptu, aby sa registrovali synchrónne pri prebudení service workera. Listener vytvorený až po asynchrónnej inicializácii môže zmeškať udalosť, ktorá worker práve prebudila. [10]

Pri vývoji je ľahké si to nevšimnúť. Otvorený DevTools môže ovplyvniť životný cyklus service workera a chyba sa prejaví až pri bežnom používaní. Google opísal podobné problémy pri migráciách na MV3: uspatie procesu môže prerušiť časovače a odstrániť stav uložený v pamäti. [11]

Hlavné pravidlo teda znie:

Proces rozšírenia na pozadí by mal byť navrhnutý ako prerušiteľný handler udalostí, nie ako malý server Node.js bežiaci nepretržite.

Lekcia 3: Chrome je dobrý východiskový bod, ale zlé jediné testovacie prostredie

Chrome je prirodzenou základňou pre projekt Manifest V3. Má rozsiahlu dokumentáciu, príklady, vývojárske nástroje a najväčší ekosystém doplnkov.

Súčasne testovanie iba v Chrome vytvára falošný pocit kompatibility.

Ak kód funguje v Chrome a Edge, potvrdzuje to predovšetkým kompatibilitu s Chromium. Nepotvrdzuje:

• správne správanie v Gecko,
• správne správanie vo WebKit,
• odolnosť voči inému životnému cyklu popupu,
• fungovanie v inom modeli oprávnení,
• správne škálovanie ikon,
• správne správanie zvuku,
• totožnú sémantiku API.

Chrome Web Store vyžaduje, aby rozšírenie malo jeden úzky a ľahko pochopiteľný účel. Vyžaduje aj minimálnu sadu oprávnení, zdôvodnenie každého z nich a konzistentné vyhlásenia o práci s údajmi. Príliš široké oprávnenia môžu viesť k zamietnutiu. Manifest V3 navyše nepovoľuje načítanie a spúšťanie vzdialene hostovaného kódu. [12]

Tieto požiadavky ovplyvňujú architektúru skôr, než sa môže zdať. Pridať „pre istotu“ prístup ku všetkým stránkam nie je neutrálne. Neskôr ho treba vysvetliť reviewerovi aj používateľovi. Lepším riešením môže byť activeTab, voliteľné host permissions alebo prístup obmedzený na konkrétne domény.

Chrome nás preto naučil dve protichodné veci:

• dobre sa hodí ako základná varianta MV3;
• nemal by definovať všetky predpoklady zdieľanej vrstvy.

Lekcia 4: Edge je najľahší technický port, ale nie bezplatný distribučný kanál

Microsoft oficiálne opisuje portovanie existujúceho rozšírenia Chrome do Edge ako samostatný podporovaný scenár. Keďže oba prehliadače používajú Chromium, rozdiely v základnom kóde bývajú malé. [13]

V našich projektoch Edge zvyčajne vyžadoval najmenej technických zmien. Napriek tomu to neznamenalo publikovanie „jedným kliknutím“.

Rozšírenie sa odosiela do samostatného Partner Center, kde je potrebné:

• nahrať vlastný ZIP balík,
• nastaviť dostupnosť a trhy,
• vybrať kategóriu,
• opísať jediný účel,
• zdôvodniť každé oprávnenie,
• deklarovať použitie vzdialeného kódu,
• opísať prácu s údajmi,
• pripraviť listingy pre rôzne jazyky,
• nahrať samostatnú grafiku a screenshoty,
• pridať poznámky pre certifikačný tím. [14]

Rovnako ako Google vyžaduje Microsoft jasne definovaný účel a najmenšiu potrebnú sadu oprávnení. Partner Center tiež upozorňuje, že neúplné alebo nekonzistentné vyhlásenia môžu predĺžiť certifikáciu alebo viesť k zamietnutiu. [14]

Edge preto dobre ukazuje rozdiel medzi nákladmi na port a nákladmi distribučného kanála.

Kód môže byť takmer totožný, ale stále treba udržiavať:

• samostatný záznam produktu,
• samostatný stav kontroly,
• samostatné metadáta,
• samostatné grafické varianty,
• samostatný aktualizačný proces,
• konzistenciu vyhlásení o súkromí.

Pri jednom rozšírení ide o miernu réžiu. Pri deviatich produktoch sa z nej stáva pravidelný prevádzkový proces.

Lekcia 5: Firefox najlepšie odhalí kód napísaný „omylom len pre Chrome“

Firefox používa WebExtensions, ale nie je Chromium. Práve preto je takým cenným testovacím prostredím.

Najznámejší rozdiel sa týka namespace a asynchrónneho kódu. Chrome historicky používal chrome a callbacky, zatiaľ čo Firefox a Safari používajú browser a promises. V Manifest V3 pridali Chrome a Edge podporu promises pre mnohé metódy, ale všetky rozdiely nezmizli. Mozilla odporúča písať kód s browser a promises a v prípade potreby použiť WebExtension browser API Polyfill. [8][15]

Nie je vhodné rozptýliť po projekte podmienky typu:

if (isFirefox) {
  // ...
} else {
  // ...
}

pri každom volaní API. Lepšie je vytvoriť malú adaptačnú vrstvu:

export const extensionApi = {
  storageGet: (keys) => browser.storage.local.get(keys),
  storageSet: (value) => browser.storage.local.set(value),
  sendMessage: (message) => browser.runtime.sendMessage(message),
};

a riešiť rozdiely na jednom mieste.

Firefox tiež vyžaduje väčšiu disciplínu pri publikovaní. Rozšírenia musia byť podpísané aj pri samostatnej distribúcii v štandardnej konfigurácii. AMO balík validuje a minifikovaný alebo ťažko čitateľný kód môže vyžadovať odoslanie kompletného zdrojového balíka. Mozilla môže navyše po publikovaní vykonať ručnú kontrolu a zamietnuť súčasnú alebo staršiu verziu. [16][17][18]

Z hľadiska kvality je to výhoda. Proces núti, aby build bol:

• reprodukovateľný,
• zdokumentovaný,
• bez zbytočnej obfuskácie,
• v súlade s deklarovaným správaním,
• kontrolovateľný bez interných znalostí autora.

Firefox tiež odhalil problémy v miestach, kde bolo Chromium tolerantnejšie. Týkali sa spracovania správ, čakania na promise odpoveď, rozdielov popupov a predpokladov o dostupnosti niektorých vlastností API.

Hlavná lekcia:

Firefox nie je dodatočný checkbox po dokončení projektu. Je to druhý nezávislý runtime, ktorý by mal vstúpiť do testov skoro.

Lekcia 6: Safari nie je port do ďalšieho obchodu, ale samostatná fáza produktu

Apple podporuje WebExtensions a ponúka nástroj na prevod rozšírení z Chrome, Firefoxu alebo Edge. Napriek tomu je proces Safari zásadne odlišný. [3][4]

Rozšírenie sa stáva súčasťou aplikácie vytváranej v Xcode. Je potrebné spravovať:

• projekt aplikácie,
• target rozšírenia,
• bundle identifier aplikácie,
• samostatný bundle identifier rozšírenia,
• podpis,
• profily a certifikáty,
• ikonu aplikácie,
• entitlements,
• archiváciu,
• App Store Connect,
• kontrolu App Store.

Apple vyžaduje, aby rozšírenie fungovalo s aktuálnou verziou Safari pre daný systém, nezasahovalo do rozhrania Safari a nežiadalo prístup k väčšiemu počtu webov, než je potrebné. [19]

Práve tu sa objavili najkonkrétnejšie problémy nášho portfólia.

Loudly: rozhranie fungovalo, ale zvuk sa nezosilňoval

Loudly zasahuje do zvuku prehrávaného na stránke. Vo verzii Safari bolo možné zobraziť rozhranie, meniť nastavenia a získať dojem, že produkt funguje. Skutočný zvukový signál sa však nezosilňoval.

Ide o horší typ chyby než zjavný crash. Smoke test „popup sa otvorí“ prejde, ale základný sľub produktu splnený nie je.

Záver: pri multimediálnych rozšíreniach musí funkčný test merať konečný efekt, nie iba stav rozhrania.

TabZoo: biela obrazovka namiesto aplikácie

Verzia Safari pri TabZoo mohla zobraziť prázdnu bielu stránku. Príčinou môže byť chyba inicializácie, cesty k assetom, nesprávny kontext alebo výnimka pred vykreslením.

V Chromium môže podobná chyba zostať skrytá, ak je poradie spustenia alebo dostupnosť API odlišná.

Záver: každá obrazovka rozšírenia by mala mať minimálny diagnostický mechanizmus a obsluhu chyby inicializácie. Prázdna stránka nesmie byť konečným stavom produktu.

LoopIt: jeden klik otvoril dve rozhrania

V LoopIt spôsobilo kliknutie na ikonu v Safari zobrazenie popupu a ďalšieho panela rozšírenia. Išlo o konflikt medzi deklaratívne nastaveným popupom a ručnou obsluhou kliknutia.

V jednom prehliadači sa správanie zdalo správne, v inom vyvolalo dvojitú reakciu.

Záver: musí byť jednoznačné, kto obsluhuje kliknutie na tlačidlo. Buď má tlačidlo default_popup, alebo je udalosť spracovaná programovo. Kombinácia oboch mechanizmov vyžaduje veľmi vedomý návrh.

Tieto tri prípady ukazujú, prečo spustenie Apple konvertora port nedokončí. Konvertor prenesie štruktúru. Nepotvrdí sémantiku správania.

Lekcia 7: video a audio rozšírenia sú ťažšie, než naznačuje popup

Štyri naše produkty sú silne závislé od médií:

• AutoScroll,
• LoopIt,
• Loudly,
• TubePilot.

Každý musí koordinovať niekoľko svetov:

• DOM stránky,
• audio alebo video prvok,
• content script,
• popup,
• proces na pozadí,
• uložené nastavenia,
• SPA navigáciu,
• zmeny aktívnej karty.

Väčšina chýb nevzniká vnútri jednej funkcie, ale na hranici týchto kontextov.

Príklad scenára:

1. používateľ otvorí popup;
2. popup sa opýta content scriptu na aktuálny stav;
3. stránka práve zmenila video bez úplného reloadu;
4. starý video prvok bol odstránený;
5. content script stále drží odkaz na predchádzajúci prvok;
6. popup ukazuje správnu hodnotu, ale mení neaktívny prehrávač.

Pridať ďalší setTimeout nie je riešenie. Je potrebný explicitný model stavu:

• identifikovať aktívny prvok,
• sledovať zmeny DOM,
• znovu pripojiť handlery,
• potvrdiť vykonanie príkazu,
• synchronizovať UI až po odpovedi,
• obnoviť stav po reštarte procesu na pozadí.

Pri službách ako YouTube je navyše potrebné počítať so SPA navigáciou. Zmena videa nie vždy spôsobí úplné načítanie dokumentu, preto jednorazová inicializácia content scriptu nestačí.

Lekcia 8: ikona a popup sú súčasťou implementácie, nie len brandingu

Multiplatformový build môže byť technicky správny a napriek tomu vyzerať zle.

V našich testoch sa objavovali ikony:

• príliš veľké vzhľadom na dostupnú plochu,
• bez bezpečného okraja,
• dotýkajúce sa hrán,
• opticky menšie než iné ikony rozšírení napriek rovnakej veľkosti súboru,
• správne v obchode, ale zle čitateľné na paneli nástrojov.

Rozmer PNG problém nerieši. Dôležitá je vizuálna veľkosť symbolu vnútri plátna.

To isté platí pre popupy. Rovnaká CSS šírka sa môže zobraziť odlišne pre:

• vykresľovanie fontov,
• predvolené štýly formulárových prvkov,
• správanie scrollbarov,
• výpočet výšky,
• systémové okraje,
• škálovanie obrazovky,
• svetlý a tmavý režim.

Preto dnes pripravujeme assets ako sadu, nie ako jeden obrázok:

• zdrojové SVG,
• rastrové varianty požadované manifestom,
• kontrolovanú safe area,
• ikonu aplikácie Safari,
• grafiku listingov,
• screenshoty obchodov.

Rozhranie rozšírenia by malo mať aj minimálne a maximálne rozmery a zostať čitateľné pri zmene dĺžky prekladov.

Lekcia 9: publikovanie je samostatný prevádzkový produkt

Najväčšou organizačnou chybou by bolo predpokladať, že práca končí vytvorením ZIPu.

Každý obchod má vlastný model dôvery.

Chrome Web Store

Chrome vyžaduje jasný jediný účel, minimálne oprávnenia, vyhlásenia o údajoch a zásady ochrany súkromia. V Manifest V3 je vzdialene spúšťaný kód zakázaný. [12]

Opis produktu musí zodpovedať skutočnému správaniu. Ak listing sľubuje funkciu, ktorú reviewer nedokáže spustiť, nejde o marketingový, ale certifikačný problém.

Firefox Add-ons

AMO balík automaticky validuje, môže vyžadovať zdrojové súbory pre zostavený kód a zachováva možnosť neskoršej ručnej kontroly. Bezpečnostné a privacy upozornenia je vhodné opraviť, aj keď možno technicky pokračovať. [16][17]

Microsoft Edge Add-ons

Partner Center vyžaduje samostatné informácie o dostupnosti, súkromí a jazykových listingoch. Každé oprávnenie by malo byť zdôvodnené a informácie musia zodpovedať manifestu a správaniu rozšírenia. [14]

Safari a App Store

Safari pridáva vrstvu aplikácie, podpis, metadáta App Store a pravidlá platné pre aplikácie Apple. Rozšírenie musí fungovať na aktuálnej verzii Safari a obmedziť prístup k webom na potrebné minimum. [19]

Deväť rozšírení preto neznamená deväť listingov. Pri úplnom pokrytí štyroch platforiem môže vzniknúť až 36 kombinácií produkt-prehliadač, bez jazykových verzií a samostatných variantov pre zariadenia Apple.

To je dostatočný dôvod uchovávať metadáta v repozitári.

Lekcia 10: je potrebná testovacia matica, nie poznámka „skontrolovať rozšírenie“

Pre každé rozšírenie udržiavame rovnaký základ testov a potom pridávame prípady súvisiace s jeho funkciou.

Minimálny smoke test

Po každom builde kontrolujeme:

1. čistú inštaláciu;
2. aktualizáciu z predchádzajúcej verzie;
3. zobrazenie ikony;
4. otvorenie popupu;
5. neprítomnosť chýb inicializácie;
6. uloženie a opätovné načítanie nastavení;
7. fungovanie po zatvorení a reštarte prehliadača;
8. fungovanie po uspatí backgroundu;
9. správanie bez oprávnenia k stránke;
10. správanie na nepodporovanej stránke.

Test komunikácie

Samostatne testujeme:

• popup → background,
• popup → content script,
• content script → background,
• asynchrónnu odpoveď,
• chýbajúcu aktívnu kartu,
• reload karty,
• SPA navigáciu,
• opätovné vloženie content scriptu,
• zatvorenie popupu pred prijatím odpovede.

Test konkrétnej funkcie

Pri Loudly nestačí posunúť slider. Je potrebné potvrdiť zmenu úrovne zvuku.

Pri LoopIt treba overiť, že sa prehrávanie skutočne vráti do vybraného rozsahu.

Pri AutoScroll treba testovať rôzne layouty, fullscreen, zmenu videa a ručné scrollovanie.

Pri ClickClean treba overiť efekt na reálnych testovacích údajoch, nie len správu „hotovo“.

Pri DevScope a LeakLens treba skontrolovať report na stránkach s rôznymi CSP pravidlami, počtom framov a sadou hlavičiek.

Platformový test

Nakoniec prichádzajú prípady špecifické pre prehliadač:

• reštart service workera v Chromium,
• podpísaný balík Firefoxu,
• host permissions vo Firefoxe,
• inštalácia a aktivácia rozšírenia v Safari,
• verzie macOS a iOS, ak ich produkt podporuje,
• aktualizácia cez obchod, nielen lokálny sideload.

Lekcia 11: automatické testy nenahrádzajú skutočné browser QA

Automatizácia je potrebná, ale má obmedzenia.

Unit testy dobre pokrývajú:

• obchodnú logiku,
• validáciu,
• migrácie storage,
• formátovanie údajov,
• pravidlá zapínania funkcií.

Integračné testy môžu kontrolovať:

• manifest,
• prítomnosť súborov,
• komunikáciu medzi modulmi,
• základné volania API,
• úplnosť lokalizácií.

E2E testy v Chromium zachytia veľkú časť regresií rozhrania a content scriptov.

Nepotvrdia však, že:

• Firefox interpretuje všetky oprávnenia rovnako,
• Safari správne mení zvuk,
• App Store spustí správny target,
• popup sa neotvorí dvakrát,
• ikona vyzerá správne v systémovom paneli.

Najdrahšie chyby našich portov nebolo ľahké odhaliť unit testom. Išlo o integračné problémy medzi rozšírením, prehliadačom, webom a operačným systémom.

Lekcia 12: vrstva kompatibility by mala opisovať schopnosti, nie názvy prehliadačov

Na začiatku projektu je lákavá podmienka:

if (browserName === "safari") {
  // špeciálne správanie
}

Niekedy je nevyhnutná, ale nemala by byť hlavným architektonickým modelom.

Lepšie otázky sú:

• podporuje prostredie dané API?
• je popup deklaratívny?
• je background service worker?
• je konkrétna metóda dostupná?
• vyžaduje funkcia natívny kontajner?
• sprístupňuje stránka potrebný mediálny prvok?

Kód založený na schopnostiach je odolnejší voči zmenám verzií a ľahšie sa testuje.

Platformová vrstva môže napríklad poskytovať:

export const capabilities = {
  supportsSessionStorage: Boolean(browser.storage?.session),
  supportsSidePanel: Boolean(browser.sidePanel),
  usesServiceWorker: import.meta.env.BACKGROUND_MODE === "service-worker",
  isSafariContainer: import.meta.env.TARGET === "safari",
};

Rozdiely to neodstráni. Urobí ich explicitné a sústredí ich na jednom mieste.

Lekcia 13: privacy-first skutočne zjednodušuje publikovanie

Rozšírenia POLPROG sú navrhované bez analytiky, trackingu a externého backendu tam, kde nie sú potrebné.

Nie je to len rozhodnutie značky. Zjednodušuje:

• opis toku údajov,
• zásady ochrany súkromia,
• zdôvodnenie oprávnení,
• code review,
• riziko úniku,
• súlad medzi listingom a kódom.

Neznamená to, že súkromné rozšírenie nepotrebuje dokumentáciu. Ak doplnok číta obsah stránky, históriu, karty alebo cookies, musí jasne vysvetliť prečo, aj keď nič neodosiela na server.

Chrome a Edge vyžadujú zdôvodnenie oprávnení a deklarácie práce s údajmi. Firefox pri nových doplnkoch vyžaduje informácie o oprávneniach súvisiacich so zberom údajov. Safari odporúča obmedziť prístup k webom na potrebné minimum. [9][12][14][19]

Navrhovať od prvého dňa s minimom oprávnení je oveľa jednoduchšie než odstraňovať nadbytočné práva po zamietnutí.

Lekcia 14: release pipeline má vytvárať produkty, nie archív final-final.zip

Pri deviatich rozšíreniach prestáva byť ručné balenie rýchlo bezpečné.

Dobrá pipeline by mala:

1. skontrolovať verziu;
2. validovať základný manifest;
3. vygenerovať platformový manifest;
4. zostaviť kód;
5. skopírovať správne ikony;
6. skontrolovať neprítomnosť vzdialeného kódu;
7. spustiť testy;
8. vytvoriť samostatné artefakty;
9. vytvoriť kontrolné súčty;
10. pripraviť changelog a informácie pre obchod.

Príklad výsledku:

dist/
  loudly/
    chrome/loudly-1.4.0.zip
    edge/loudly-1.4.0.zip
    firefox/loudly-1.4.0.xpi
    safari/Loudly.xcarchive

Verzia by mala pochádzať z jedného zdroja pravdy, ale artefakty nemusia byť totožné.

Automaticky je vhodné kontrolovať aj:

• zakázané súbory,
• sourcemapy,
• tajné údaje,
• nepoužité oprávnenia,
• chýbajúce lokalizácie,
• nesprávnu cestu ikony,
• nesúlad verzií medzi manifestmi.

Automatizácia neodstraňuje kontrolu v obchode. Odstraňuje chyby, ktoré by sa k reviewerovi nikdy nemali dostať.

Ktorý prehliadač bol najjednoduchší?

Odpoveď závisí od toho, čo meriame.

Najjednoduchší začiatok: Chrome

Najviac dokumentácie, príkladov a nástrojov. Dobrá voľba pre základnú verziu MV3.

Najjednoduchší port kódu: Edge

Ak je verzia Chrome správna, technické rozdiely sú často malé. Samostatná publikačná práca však zostáva.

Najlepší test nezávislosti: Firefox

Nie je vždy najjednoduchší, ale prináša veľkú hodnotu. Odhaľuje kód náhodne naviazaný na Chromium a núti k disciplíne buildu.

Najvyššie celkové úsilie: Safari

Nielen kvôli API. Pribúda Xcode, aplikácia, podpis, App Store a testy na zariadeniach Apple. Problémy Loudly, TabZoo a LoopIt tiež ukázali, že fungujúce rozhranie neznamená fungujúcu funkciu.

Čo by sme dnes urobili inak?

1. Safari by bolo v pláne od prvého sprintu

Nemuselo by hneď obsahovať všetky funkcie. Mal by však existovať funkčný skeleton projektu Xcode a pravidelný test základného toku.

2. Firefox by vstúpil do CI skôr

Nielen build, ale aj testy spúšťané v skutočnom Firefoxe.

3. Každá funkcia by mala vlastníka stavu

Pred implementáciou by sme rozhodli, či stav patrí content scriptu, backgroundu, popupu alebo storage. Mnohé komunikačné chyby vznikajú z nejasnej odpovede.

4. Oprávnenia by sa navrhovali spolu s funkciou

Každé nové oprávnenie by malo mať:

• technické zdôvodnenie,
• text pre obchod,
• scenár odmietnutia,
• test správania bez súhlasu.

5. Listing by bol súčasťou repozitára

Opis, krátke zhrnutie, release notes, vyhľadávacie termíny, zásady ochrany súkromia a grafika by mali mať históriu zmien.

6. Údaje by sme merali od prvej verzie

Ďalšia etapa reportu by mala zahŕňať:

• čas od odoslania do publikácie,
• počet zamietnutí,
• dôvod každého zamietnutia,
• počet zmien špecifických pre platformu,
• počet regresií odhalených iba mimo Chrome,
• čas potrebný na prípravu aktualizácie,
• veľkosť zdieľaného a platformového kódu.

Dnes tieto hodnoty nerekonštruujeme z pamäte, pretože chceme oddeliť skúsenosť od štatistiky. V budúcnosti umožnia ešte presnejšie reporty.

Odporúčaná architektúra multiplatformového rozšírenia

src/
  core/
    domain/
    storage/
    validation/
  platform/
    api.ts
    capabilities.ts
    messaging.ts
  background/
  content/
  popup/
  options/
  locales/

manifests/
  chrome.json
  edge.json
  firefox.json
  safari.json

store/
  chrome/
  edge/
  firefox/
  safari/

tests/
  unit/
  integration/
  e2e/
  manual/

Najdôležitejšie je rozdelenie zodpovedností:

• core nepozná konkrétny prehliadač;
• platform prevádza WebExtensions do spoločného rozhrania;
• UI sa zdieľa tam, kde je to rozumné;
• manifesty a store assets sú explicitne platformové;
• ručné testy majú zapísané scenáre a neexistujú iba v pamäti autora.

Verdikt

Najdôležitejšia lekcia z deviatich rozšírení je jednoduchá:

WebExtensions umožňuje udržiavať jeden spoločný produkt, ale nezbavuje potreby vytvoriť štyri správne vydania.

Chrome ponúka najlepší východiskový bod. Edge býva najjednoduchší technický port. Firefox je najcennejší test skutočnej kompatibility. Safari vyžaduje považovať rozšírenie za súčasť aplikácie Apple, nie za ďalší variant ZIP.

Najväčšie problémy nevznikali tam, kde chýbal ekvivalent jednej metódy API. Vznikali na priesečníku:

• životného cyklu procesu,
• stavu,
• webovej stránky,
• rozhrania,
• oprávnení,
• balenia,
• kontroly obchodu.

Efektívny tím preto nezačína otázkou: „Ako skopírujeme rozšírenie Chrome do ďalších troch obchodov?“ Začína otázkami:

• čo je spoločným jadrom produktu?
• ktoré schopnosti závisia od platformy?
• kde je uložený stav?
• ako overíme skutočný efekt funkcie?
• ako obmedzíme oprávnenia?
• ako reprodukujeme každý build?
• ako otestujeme aktualizáciu, nie iba čistú inštaláciu?

Po týchto skúsenostiach stále považujeme jednu codebase za správnu stratégiu. Len nepredstierame, že štyri prehliadače sú jedno prostredie.

Práve prijatie rozdielov umožňuje zdieľať kód bez zníženia kvality.

Zdroje

1. POLPROG, hlavná stránka a informácie o portfóliu rozšírení
2. POLPROG, profil vydavateľa na Firefox Add-ons
3. Apple Developer, Safari Extensions
4. Apple Developer, Meet Safari Web Extensions
5. Chrome for Developers, Migrate to a service worker
6. Chrome for Developers, Extension service worker lifecycle
7. MDN, Chrome incompatibilities
8. MDN, Differences between API implementations
9. MDN, browser_specific_settings
10. Chrome for Developers, Events in extension service workers
11. Chrome for Developers, Testing MV3 service worker suspension
12. Chrome for Developers, Chrome Web Store privacy fields and permissions
13. Microsoft Learn, Port a Chrome extension to Microsoft Edge
14. Microsoft Learn, Publish a Microsoft Edge extension
15. MDN, Build a cross-browser extension
16. Mozilla Extension Workshop, Submitting an add-on
17. Mozilla Extension Workshop, Signing and distribution overview
18. Mozilla Extension Workshop, Add-on Policies
19. Apple Developer, App Review Guidelines, Safari extensions
20. Mozilla, Approach to Manifest V3
21. Pantelaios a Kapravelos, Manifest V3 Unveiled
22. Polčák a kol., Developers Insight on Manifest V3