Chrome vs Firefox vs Edge vs Safari: co jsme se naučili při vydání 9 rozšíření prohlížeče

Na papíře by moderní rozšíření prohlížeče mělo být téměř automaticky multiplatformním produktem. Chrome, Firefox, Edge a Safari podporují WebExtensions, používají podobný soubor manifest.json a nabízejí srovnatelné mechanismy: content scripty, úložiště, komunikaci mezi kontexty, tlačítko v nástrojové liště a stránky nastavení.

To je pravda, ale jen do určité míry.

Po vydání a portování devíti rozšíření POLPROG už víme, že sdílený kód neznamená jeden totožný produkt. Většinu obchodní logiky lze sdílet, ale chování prohlížeče, životní cyklus procesu na pozadí, rozhraní, oprávnění, balení a kontrola v obchodě zůstávají samostatnými problémy.

Portfolio zahrnuje:

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

Nejde o devět kopií stejného typu doplňku. Soubor obsahuje nástroje pro video, zesílení zvuku, soukromí, čištění dat, vývoj, správu karet a lehkou hru. Problémy se proto neomezovaly na jedno API. Týkaly se service workerů, popupů, content scriptů, zvuku, úložiště, ikon, oprávnění a procesu publikování.

POLPROG veřejně udržuje devět produktů typu rozšíření, které byly původně vydávány především pro Chrome a Firefox a následně portovány také na Edge a Safari. [1][2]

Tento článek není laboratorní benchmark. Od prvního commitu jsme neměřili každou minutu strávenou v jednotlivých obchodech, proto nebudeme tvrdit, že Safari stojí přesně 2,7krát více než Chrome nebo že je 94 % kódu sdíleno. To by byla falešná přesnost.

Můžeme však ukázat něco užitečnějšího: které předpoklady se ukázaly jako chybné, kde se objevily skutečné poruchy a jak bychom dnes navrhli celý proces od začátku.

Čtyři prohlížeče, čtyři různé role

Platforma	Role v našem procesu	Největší výhoda	Nejčastější past
Chrome	Hlavní základ kompatibility s Manifest V3	Nejširší dokumentace a největší trh s rozšířeními	Uspávaný service worker a přísné požadavky na oprávnění
Edge	Port založený na Chromium	Malý rozdíl kódu oproti Chrome	Samostatný Partner Center, metadata a certifikace
Firefox	Nezávislá implementace WebExtensions	Dobře odhaluje předpoklady závislé na Chromium	Rozdíly API a manifestu, podpis a požadavky na zdrojové kódy
Safari	Samostatný produkt v ekosystému Apple	Přístup k uživatelům macOS, iOS a iPadOS	Xcode, kontejnerová aplikace, podpis a jiné chování runtime

MDN zdůrazňuje, že cílem WebExtensions je umožnit doplňkům fungovat v hlavních prohlížečích po minimálních změnách, současně ale dokumentuje významné rozdíly mezi Chrome, Firefoxem a Safari v dostupnosti API, manifestech a zpracování asynchronních operací. [7][8]

To dobře odpovídá naší zkušenosti. „Minimální změny“ jsou realistické u jednoduchého doplňku. Čím více rozšíření zasahuje do stránky, médií, životního cyklu karet nebo procesu na pozadí, tím méně užitečné je slovo „minimální“.

Lekce 1: jedna codebase ano, jeden manifest ne nutně

Nejlepším výchozím bodem je sdílená logika s oddělenými konfiguracemi buildu.

V praxi se nejlépe osvědčila struktura, ve které se sdílí:

• logika funkcí,
• datové modely,
• moduly storage,
• validace,
• většina rozhraní popupu a nastavení,
• lokalizace,
• unit testy.

Oddělené zůstávají:

• varianty manifestu,
• identifikátory doplňků,
• minimální verze prohlížečů,
• konfigurace backgroundu,
• část oprávnění,
• ikony a store assets,
• balení,
• podpis,
• publikační skripty.

Neznamená to udržovat čtyři ručně kopírované adresáře. To rychle vede k rozdílům. Lepším modelem jsou sdílené zdroje plus generátor nebo konfigurační vrstva, která připraví samostatný artefakt pro každou platformu.

Firefox například vyžaduje vlastní nastavení v browser_specific_settings. V Manifest V3 je identifikátor rozšíření potřebný pro podpis a od listopadu 2025 musí nové doplňky odesílané do AMO deklarovat také nastavení týkající se sběru dat. [9]

Safari zase vyžaduje projekt Xcode a aplikaci obsahující rozšíření. Apple poskytuje převodník WebExtension, ale výsledek je stále nutné považovat za nativní projekt určený k podepsání a distribuci přes App Store. [3][4]

Společný manifest by tedy byl jen zdánlivou úsporou. Několik malých a explicitních rozdílů se udržuje snadněji než jeden soubor plný výjimek a podmínek.

Lekce 2: Manifest V3 nesjednotil chování prohlížečů

Manifest V3 zlepšil část kompatibility a uspořádal model rozšíření, ale nevytvořil jeden identický runtime.

Nejviditelnější změnou v Chrome je nahrazení trvalých stránek na pozadí extension service workerem. Google jej popisuje jako centrální handler událostí spouštěný podle potřeby. Proces může být ukončen a proměnné uložené pouze v paměti s ním zmizí. [5][6]

To má přímé důsledky.

Kód jako:

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

nemůže být jediným zdrojem pravdy, pokud jsou tyto údaje potřebné po opětovném spuštění service workeru.

Stav je vhodné rozdělit do tří skupin:

1. dočasný stav, který může bezpečně zmizet;
2. stav rekonstruovatelný z aktivních karet nebo DOM;
3. trvalý stav, který musí být uložen do storage.local, storage.session nebo jiného vhodného místa.

Stejně důležitá je registrace listenerů. Chrome doporučuje deklarovat handlery událostí v globálním scope skriptu, aby se registrovaly synchronně při probuzení service workeru. Listener vytvořený až po asynchronní inicializaci může zmeškat událost, která worker právě probudila. [10]

Při vývoji je snadné si toho nevšimnout. Otevřený DevTools může ovlivnit životní cyklus service workeru a chyba se projeví až při běžném používání. Google popsal podobné problémy při migracích na MV3: uspání procesu může přerušit časovače a odstranit stav uložený v paměti. [11]

Hlavní pravidlo tedy zní:

Proces rozšíření na pozadí by měl být navržen jako přerušitelný handler událostí, nikoli jako malý server Node.js běžící nepřetržitě.

Lekce 3: Chrome je dobrý výchozí bod, ale špatné jediné testovací prostředí

Chrome je přirozenou základnou pro projekt Manifest V3. Má rozsáhlou dokumentaci, příklady, vývojářské nástroje a největší ekosystém doplňků.

Současně testování pouze v Chrome vytváří falešný pocit kompatibility.

Pokud kód funguje v Chrome a Edge, potvrzuje to především kompatibilitu s Chromium. Nepotvrzuje:

• správné chování v Gecko,
• správné chování ve WebKit,
• odolnost vůči jinému životnímu cyklu popupu,
• fungování v jiném modelu oprávnění,
• správné škálování ikon,
• správné chování zvuku,
• totožnou sémantiku API.

Chrome Web Store vyžaduje, aby rozšíření mělo jeden úzký a snadno pochopitelný účel. Vyžaduje také minimální sadu oprávnění, zdůvodnění každého z nich a konzistentní prohlášení o práci s daty. Příliš široká oprávnění mohou vést k zamítnutí. Manifest V3 navíc nepovoluje načítání a spouštění vzdáleně hostovaného kódu. [12]

Tyto požadavky ovlivňují architekturu dříve, než se může zdát. Přidat „pro jistotu“ přístup ke všem stránkám není neutrální. Později je třeba jej vysvětlit reviewerovi i uživateli. Lepším řešením může být activeTab, volitelná host permissions nebo přístup omezený na konkrétní domény.

Chrome nás proto naučil dvě protichůdné věci:

• dobře se hodí jako základní varianta MV3;
• neměl by definovat všechny předpoklady sdílené vrstvy.

Lekce 4: Edge je nejsnazší technický port, ale ne bezplatný distribuční kanál

Microsoft oficiálně popisuje portování existujícího rozšíření Chrome do Edge jako samostatný podporovaný scénář. Protože oba prohlížeče používají Chromium, rozdíly v základním kódu bývají malé. [13]

V našich projektech Edge obvykle vyžadoval nejméně technických změn. Přesto to neznamenalo publikaci „jedním kliknutím“.

Rozšíření se odesílá do samostatného Partner Center, kde je potřeba:

• nahrát vlastní ZIP balíček,
• nastavit dostupnost a trhy,
• vybrat kategorii,
• popsat jediný účel,
• zdůvodnit každé oprávnění,
• deklarovat použití vzdáleného kódu,
• popsat práci s daty,
• připravit listingy pro různé jazyky,
• nahrát samostatnou grafiku a screenshoty,
• přidat poznámky pro certifikační tým. [14]

Stejně jako Google vyžaduje Microsoft jasně definovaný účel a nejmenší nutnou sadu oprávnění. Partner Center také upozorňuje, že neúplná nebo nekonzistentní prohlášení mohou prodloužit certifikaci nebo vést k zamítnutí. [14]

Edge proto dobře ukazuje rozdíl mezi náklady na port a náklady distribučního kanálu.

Kód může být téměř totožný, ale stále je třeba udržovat:

• samostatný záznam produktu,
• samostatný stav kontroly,
• samostatná metadata,
• samostatné grafické varianty,
• samostatný aktualizační proces,
• konzistenci prohlášení o soukromí.

U jednoho rozšíření jde o mírnou režii. U devíti produktů se z ní stává pravidelný provozní proces.

Lekce 5: Firefox nejlépe odhalí kód napsaný „omylem jen pro Chrome“

Firefox používá WebExtensions, ale není Chromium. Právě proto je tak cenným testovacím prostředím.

Nejznámější rozdíl se týká namespace a asynchronního kódu. Chrome historicky používal chrome a callbacky, zatímco Firefox a Safari používají browser a promises. V Manifest V3 přidaly Chrome a Edge podporu promises pro mnoho metod, ale všechny rozdíly nezmizely. Mozilla doporučuje psát kód s browser a promises a v případě potřeby použít WebExtension browser API Polyfill. [8][15]

Není vhodné rozptýlit po projektu podmínky typu:

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

u každého volání API. Lepší je vytvořit malou 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 řešit rozdíly na jednom místě.

Firefox také vyžaduje větší disciplínu při publikaci. Rozšíření musí být podepsaná i při samostatné distribuci ve standardní konfiguraci. AMO balíček validuje a minifikovaný nebo obtížně čitelný kód může vyžadovat odeslání kompletního zdrojového balíčku. Mozilla může navíc po publikaci provést ruční kontrolu a zamítnout současnou nebo dřívější verzi. [16][17][18]

Z hlediska kvality je to výhoda. Proces nutí, aby build byl:

• reprodukovatelný,
• zdokumentovaný,
• bez zbytečné obfuskace,
• v souladu s deklarovaným chováním,
• kontrolovatelný bez interních znalostí autora.

Firefox také odhalil problémy v místech, kde bylo Chromium tolerantnější. Týkaly se zpracování zpráv, čekání na promise odpověď, rozdílů popupů a předpokladů o dostupnosti některých vlastností API.

Hlavní lekce:

Firefox není dodatečný checkbox po dokončení projektu. Je to druhý nezávislý runtime, který by měl vstoupit do testů brzy.

Lekce 6: Safari není port do dalšího obchodu, ale samostatná fáze produktu

Apple podporuje WebExtensions a nabízí nástroj pro převod rozšíření z Chrome, Firefoxu nebo Edge. Přesto je proces Safari zásadně odlišný. [3][4]

Rozšíření se stává součástí aplikace vytvářené v Xcode. Je třeba spravovat:

• projekt aplikace,
• target rozšíření,
• bundle identifier aplikace,
• samostatný bundle identifier rozšíření,
• podpis,
• profily a certifikáty,
• ikonu aplikace,
• entitlements,
• archivaci,
• App Store Connect,
• kontrolu App Store.

Apple vyžaduje, aby rozšíření fungovalo s aktuální verzí Safari pro daný systém, nezasahovalo do rozhraní Safari a nežádalo přístup k většímu počtu webů, než je nutné. [19]

Právě zde se objevily nejkonkrétnější problémy našeho portfolia.

Loudly: rozhraní fungovalo, ale zvuk se nezesiloval

Loudly zasahuje do zvuku přehrávaného na stránce. Ve verzi Safari bylo možné zobrazit rozhraní, měnit nastavení a získat dojem, že produkt funguje. Skutečný zvukový signál se však nezesiloval.

Jde o horší typ chyby než zjevný crash. Smoke test „popup se otevře“ projde, ale základní slib produktu splněn není.

Závěr: u multimediálních rozšíření musí funkční test měřit konečný efekt, nikoli pouze stav rozhraní.

TabZoo: bílá obrazovka místo aplikace

Verze Safari u TabZoo mohla zobrazit prázdnou bílou stránku. Příčinou může být chyba inicializace, cesty k assetům, nesprávný kontext nebo výjimka před vykreslením.

V Chromium může podobná chyba zůstat skrytá, pokud je pořadí spuštění nebo dostupnost API jiné.

Závěr: každá obrazovka rozšíření by měla mít minimální diagnostický mechanismus a obsluhu chyby inicializace. Prázdná stránka nesmí být konečným stavem produktu.

LoopIt: jeden klik otevřel dvě rozhraní

V LoopIt způsobilo kliknutí na ikonu v Safari zobrazení popupu a dalšího panelu rozšíření. Šlo o konflikt mezi deklarativně nastaveným popupem a ruční obsluhou kliknutí.

V jednom prohlížeči se chování zdálo správné, v jiném vyvolalo dvojitou reakci.

Závěr: musí být jednoznačné, kdo obsluhuje kliknutí na tlačítko. Buď má tlačítko default_popup, nebo je událost zpracována programově. Kombinace obou mechanismů vyžaduje velmi vědomý návrh.

Tyto tři případy ukazují, proč spuštění Apple konvertoru port nedokončí. Konvertor přenese strukturu. Nepotvrdí sémantiku chování.

Lekce 7: video a audio rozšíření jsou obtížnější, než naznačuje popup

Čtyři naše produkty jsou silně závislé na médiích:

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

Každý musí koordinovat několik světů:

• DOM stránky,
• audio nebo video prvek,
• content script,
• popup,
• proces na pozadí,
• uložená nastavení,
• SPA navigaci,
• změny aktivní karty.

Většina chyb nevzniká uvnitř jedné funkce, ale na hranici těchto kontextů.

Příklad scénáře:

1. uživatel otevře popup;
2. popup se zeptá content scriptu na aktuální stav;
3. stránka právě změnila video bez úplného reloadu;
4. starý video prvek byl odstraněn;
5. content script stále drží odkaz na předchozí prvek;
6. popup ukazuje správnou hodnotu, ale mění neaktivní přehrávač.

Přidat další setTimeout není řešení. Je potřeba explicitní model stavu:

• identifikovat aktivní prvek,
• sledovat změny DOM,
• znovu připojit handlery,
• potvrdit provedení příkazu,
• synchronizovat UI až po odpovědi,
• obnovit stav po restartu procesu na pozadí.

U služeb jako YouTube je navíc nutné počítat s SPA navigací. Změna videa ne vždy způsobí úplné načtení dokumentu, proto jednorázová inicializace content scriptu nestačí.

Lekce 8: ikona a popup jsou součástí implementace, ne jen brandingu

Multiplatformní build může být technicky správný a přesto vypadat špatně.

V našich testech se objevovaly ikony:

• příliš velké vůči dostupné ploše,
• bez bezpečného okraje,
• dotýkající se hran,
• opticky menší než jiné ikony rozšíření navzdory stejné velikosti souboru,
• správné v obchodě, ale špatně čitelné v nástrojové liště.

Rozměr PNG problém neřeší. Důležitá je vizuální velikost symbolu uvnitř plátna.

Totéž platí pro popupy. Stejná CSS šířka se může zobrazit odlišně kvůli:

• renderování fontů,
• výchozím stylům formulářových prvků,
• chování scrollbarů,
• výpočtu výšky,
• systémovým okrajům,
• škálování obrazovky,
• světlému a tmavému režimu.

Proto dnes připravujeme assets jako sadu, ne jako jeden obrázek:

• zdrojové SVG,
• rastrové varianty požadované manifestem,
• kontrolovanou safe area,
• ikonu aplikace Safari,
• grafiku listingů,
• screenshoty obchodů.

Rozhraní rozšíření by také mělo mít minimální a maximální rozměry a zůstat čitelné při změně délky překladů.

Lekce 9: publikování je samostatný provozní produkt

Největší organizační chybou by bylo předpokládat, že práce končí vytvořením ZIPu.

Každý obchod má vlastní model důvěry.

Chrome Web Store

Chrome vyžaduje jasný jediný účel, minimální oprávnění, prohlášení o datech a zásady ochrany soukromí. V Manifest V3 je vzdáleně spouštěný kód zakázán. [12]

Popis produktu musí odpovídat skutečnému chování. Pokud listing slibuje funkci, kterou reviewer nedokáže spustit, nejde o marketingový, ale certifikační problém.

Firefox Add-ons

AMO balíček automaticky validuje, může vyžadovat zdrojové soubory pro sestavený kód a zachovává možnost pozdější ruční kontroly. Bezpečnostní a privacy upozornění je vhodné opravit, i když lze technicky pokračovat. [16][17]

Microsoft Edge Add-ons

Partner Center vyžaduje samostatné informace o dostupnosti, soukromí a jazykových listinzích. Každé oprávnění by mělo být zdůvodněno a informace musí odpovídat manifestu a chování rozšíření. [14]

Safari a App Store

Safari přidává vrstvu aplikace, podpis, metadata App Store a pravidla platná pro aplikace Apple. Rozšíření musí fungovat na aktuální verzi Safari a omezit přístup k webům na nutné minimum. [19]

Devět rozšíření proto neznamená devět listingů. Při úplném pokrytí čtyř platforem může vzniknout až 36 kombinací produkt-prohlížeč, bez jazykových verzí a samostatných variant pro zařízení Apple.

To je dostatečný důvod uchovávat metadata v repozitáři.

Lekce 10: je potřeba testovací matice, ne poznámka „zkontrolovat rozšíření“

Pro každé rozšíření udržujeme stejný základ testů a poté přidáváme případy související s jeho funkcí.

Minimální smoke test

Po každém buildu kontrolujeme:

1. čistou instalaci;
2. aktualizaci z předchozí verze;
3. zobrazení ikony;
4. otevření popupu;
5. absenci chyb inicializace;
6. uložení a opětovné načtení nastavení;
7. fungování po zavření a restartu prohlížeče;
8. fungování po uspání backgroundu;
9. chování bez oprávnění ke stránce;
10. chování na nepodporované stránce.

Test komunikace

Samostatně testujeme:

• popup → background,
• popup → content script,
• content script → background,
• asynchronní odpověď,
• chybějící aktivní karta,
• reload karty,
• SPA navigaci,
• opětovné vložení content scriptu,
• zavření popupu před přijetím odpovědi.

Test konkrétní funkce

U Loudly nestačí posunout slider. Je třeba potvrdit změnu úrovně zvuku.

U LoopIt je nutné ověřit, že se přehrávání skutečně vrací do vybraného rozsahu.

U AutoScroll je potřeba testovat různé layouty, fullscreen, změnu videa a ruční scrollování.

U ClickClean je třeba ověřit efekt na reálných testovacích datech, ne jen zprávu „hotovo“.

U DevScope a LeakLens je třeba zkontrolovat report na stránkách s různými CSP pravidly, počtem framů a sadou hlaviček.

Platformní test

Nakonec přicházejí případy specifické pro prohlížeč:

• restart service workeru v Chromium,
• podepsaný balíček Firefoxu,
• host permissions ve Firefoxu,
• instalace a aktivace rozšíření v Safari,
• verze macOS a iOS, pokud je produkt podporuje,
• aktualizace přes obchod, nejen lokální sideload.

Lekce 11: automatické testy nenahrazují skutečné browser QA

Automatizace je nutná, ale má omezení.

Unit testy dobře pokrývají:

• obchodní logiku,
• validaci,
• migrace storage,
• formátování dat,
• pravidla zapínání funkcí.

Integrační testy mohou kontrolovat:

• manifest,
• přítomnost souborů,
• komunikaci mezi moduly,
• základní volání API,
• úplnost lokalizací.

E2E testy v Chromium zachytí velkou část regresí rozhraní a content scriptů.

Nepotvrdí však, že:

• Firefox interpretuje všechna oprávnění stejně,
• Safari správně mění zvuk,
• App Store spustí správný target,
• popup se neotevře dvakrát,
• ikona vypadá správně v systémové liště.

Nejdražší chyby našich portů nebyly snadno odhalitelné unit testem. Šlo o integrační problémy mezi rozšířením, prohlížečem, webem a operačním systémem.

Lekce 12: vrstva kompatibility by měla popisovat schopnosti, ne názvy prohlížečů

Na začátku projektu je lákavá podmínka:

if (browserName === "safari") {
  // speciální chování
}

Někdy je nevyhnutelná, ale neměla by být hlavním architektonickým modelem.

Lepší otázky jsou:

• podporuje prostředí dané API?
• je popup deklarativní?
• je background service worker?
• je konkrétní metoda dostupná?
• vyžaduje funkce nativní kontejner?
• zpřístupňuje stránka potřebný mediální prvek?

Kód založený na schopnostech je odolnější vůči změnám verzí a snáze se testuje.

Platformní vrstva může například poskytovat:

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",
};

Rozdíly to neodstraní. Udělá je explicitní a soustředí je na jednom místě.

Lekce 13: privacy-first skutečně zjednodušuje publikaci

Rozšíření POLPROG jsou navrhována bez analytiky, trackingu a externího backendu tam, kde nejsou potřeba.

Není to jen rozhodnutí značky. Zjednodušuje:

• popis toku dat,
• zásady ochrany soukromí,
• zdůvodnění oprávnění,
• code review,
• riziko úniku,
• soulad mezi listingem a kódem.

Neznamená to, že soukromé rozšíření nepotřebuje dokumentaci. Pokud doplněk čte obsah stránky, historii, karty nebo cookies, musí jasně vysvětlit proč, i když nic neodesílá na server.

Chrome a Edge vyžadují zdůvodnění oprávnění a deklarace práce s daty. Firefox u nových doplňků vyžaduje informace o oprávněních souvisejících se sběrem dat. Safari doporučuje omezit přístup k webům na nutné minimum. [9][12][14][19]

Navrhovat od prvního dne s minimem oprávnění je mnohem snazší než odstraňovat nadbytečná práva po zamítnutí.

Lekce 14: release pipeline má vytvářet produkty, ne archiv final-final.zip

U devíti rozšíření přestává být ruční balení rychle bezpečné.

Dobrá pipeline by měla:

1. zkontrolovat verzi;
2. validovat základní manifest;
3. vygenerovat platformní manifest;
4. sestavit kód;
5. zkopírovat správné ikony;
6. zkontrolovat absenci vzdáleného kódu;
7. spustit testy;
8. vytvořit samostatné artefakty;
9. vytvořit kontrolní součty;
10. připravit changelog a informace pro obchod.

Pří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

Verze by měla pocházet z jednoho zdroje pravdy, ale artefakty nemusejí být totožné.

Automaticky je vhodné kontrolovat také:

• zakázané soubory,
• sourcemapy,
• tajné údaje,
• nepoužitá oprávnění,
• chybějící lokalizace,
• nesprávnou cestu ikony,
• nesoulad verzí mezi manifesty.

Automatizace neodstraňuje kontrolu v obchodu. Odstraňuje chyby, které by se k reviewerovi nikdy neměly dostat.

Který prohlížeč byl nejsnazší?

Odpověď závisí na tom, co měříme.

Nejjednodušší začátek: Chrome

Nejvíce dokumentace, příkladů a nástrojů. Dobrá volba pro základní verzi MV3.

Nejjednodušší port kódu: Edge

Pokud je verze Chrome správná, technické rozdíly jsou často malé. Samostatná publikační práce však zůstává.

Nejlepší test nezávislosti: Firefox

Není vždy nejjednodušší, ale přináší velkou hodnotu. Odhaluje kód náhodně svázaný s Chromium a nutí k disciplíně buildu.

Nejvyšší celkové úsilí: Safari

Nejen kvůli API. Přibývá Xcode, aplikace, podpis, App Store a testy na zařízeních Apple. Problémy Loudly, TabZoo a LoopIt také ukázaly, že fungující rozhraní neznamená fungující funkci.

Co bychom dnes udělali jinak?

1. Safari by bylo v plánu od prvního sprintu

Nemuselo by hned obsahovat všechny funkce. Měl by však existovat funkční skeleton projektu Xcode a pravidelný test základního toku.

2. Firefox by vstoupil do CI dříve

Nejen build, ale také testy spouštěné ve skutečném Firefoxu.

3. Každá funkce by měla vlastníka stavu

Před implementací bychom rozhodli, zda stav patří content scriptu, backgroundu, popupu nebo storage. Mnoho komunikačních chyb vzniká z nejasné odpovědi.

4. Oprávnění by se navrhovala společně s funkcí

Každé nové oprávnění by mělo mít:

• technické zdůvodnění,
• text pro obchod,
• scénář odmítnutí,
• test chování bez souhlasu.

5. Listing by byl součástí repozitáře

Popis, krátké shrnutí, release notes, vyhledávací termíny, zásady ochrany soukromí a grafika by měly historii změn.

6. Data bychom měřili od první verze

Další etapa reportu by měla zahrnovat:

• čas od odeslání do publikace,
• počet zamítnutí,
• důvod každého zamítnutí,
• počet změn specifických pro platformu,
• počet regresí odhalených pouze mimo Chrome,
• čas potřebný pro přípravu aktualizace,
• velikost sdíleného a platformního kódu.

Dnes tyto hodnoty nerekonstruujeme z paměti, protože chceme oddělit zkušenost od statistiky. V budoucnu umožní ještě přesnější reporty.

Doporučená architektura multiplatformního rozšíření

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/

Nejdůležitější je rozdělení odpovědností:

• core nezná konkrétní prohlížeč;
• platform převádí WebExtensions do společného rozhraní;
• UI se sdílí tam, kde je to rozumné;
• manifesty a store assets jsou explicitně platformní;
• ruční testy mají zapsané scénáře a neexistují pouze v paměti autora.

Verdikt

Nejdůležitější lekce z devíti rozšíření je jednoduchá:

WebExtensions umožňuje udržovat jeden společný produkt, ale nezbavuje potřeby vytvořit čtyři správné verze.

Chrome nabízí nejlepší výchozí bod. Edge bývá nejjednodušší technický port. Firefox je nejcennější test skutečné kompatibility. Safari vyžaduje považovat rozšíření za součást aplikace Apple, ne za další variantu ZIP.

Největší problémy nevznikaly tam, kde chyběl ekvivalent jedné metody API. Vznikaly na průsečíku:

• životního cyklu procesu,
• stavu,
• webové stránky,
• rozhraní,
• oprávnění,
• balení,
• kontroly obchodu.

Efektivní tým proto nezačíná otázkou: „Jak zkopírujeme rozšíření Chrome do dalších tří obchodů?“ Začíná otázkami:

• co je společným jádrem produktu?
• které schopnosti závisí na platformě?
• kde je uložen stav?
• jak ověříme skutečný efekt funkce?
• jak omezíme oprávnění?
• jak reprodukujeme každý build?
• jak otestujeme aktualizaci, ne jen čistou instalaci?

Po těchto zkušenostech stále považujeme jednu codebase za správnou strategii. Jen nepředstíráme, že čtyři prohlížeče jsou jedno prostředí.

Právě přijetí rozdílů umožňuje sdílet kód bez snížení kvality.

Zdroje

1. POLPROG, hlavní stránka a informace o portfoliu rozšíření
2. POLPROG, profil vydavatele 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