Browserkompatibilitet: test webappen på de enheder, brugerne har

“Det virker hos mig” tester kun én kombination

Browser, version, operativsystem, skærmstørrelse, inputform og enhedens ydeevne kan ændre resultatet. En formular kan se rigtig ud på en stor skærm, men være dækket af tastaturet på en telefon. En filupload kan virke med mus og lokal disk, men fejle fra kamera eller fotobibliotek. En ny web-API kan mangle i en browser, selv om resten af siden indlæses.

Lav en supportmatrix ud fra virkelige brugere

Begynd med arbejdsdagen, ikke en tilfældig liste over browsernavne. Tal med dem, der skal bruge appen, og kontrollér eventuelt eksisterende trafikdata uden at gøre statistikværktøjet til den eneste sandhed. Nye kunder og firmastyrede enheder kan have andre kombinationer end de besøgende, I allerede kan måle.

Skriv også hvad der ikke understøttes. “De to seneste hovedversioner” kan være et udgangspunkt, men det er ikke en universel regel. En låst firmacomputer eller en felttelefon, der sjældent opdateres, kræver en konkret beslutning.

Vælg få brugerrejser med høj konsekvens

Et skærmbillede af forsiden beviser ikke, at arbejdet kan gennemføres. Test de flows, hvor en kompatibilitetsfejl stopper en medarbejder, skaber forkerte data eller gør resultatet uklart.

• Login og genåbning: Session, MFA eller loginlink virker, også efter at browseren har været lukket efter det aftalte design.
• Opret og redigér: Felter, datoer, dropdowns, dialoger og gem-knap kan bruges, og appen viser den serverbekræftede status.
• Fil og kamera: Filvælger, billedretning, størrelse, uploadstatus og fejlvej virker på de enheder, der faktisk bruges.
• Download og deling: Dokumentet kan åbnes eller gemmes, og en manglende delingsfunktion har en forståelig fallback.
• Lang side og lille skærm: Navigation, knapper og fejlbeskeder forsvinder ikke bag tastatur, browserlinje eller fastgjorte elementer.

Kontrollér funktioner – gæt ikke ud fra browsernavnet

MDN fraråder normalt at styre funktionalitet ved at fortolke browserens user-agent. Browserstrenge ændrer sig, kan ligne hinanden og fortæller ikke sikkert, om den konkrete funktion virker. Kontrollér i stedet den nødvendige API eller CSS-funktion, og behold et enklere basisforløb.

if ('share' in navigator) {
  shareButton.hidden = false;
  shareButton.addEventListener('click', () => navigator.share(data));
} else {
  copyLinkButton.hidden = false;
}

/* CSS: behold basislayoutet, og forbedr kun hvor funktionen findes */
@supports (display: grid) {
  .case-list { display: grid; grid-template-columns: repeat(2, 1fr); }
}

Baseline kan hjælpe med at vurdere, om en webfunktion er tilgængelig på tværs af de centrale browsere. Det erstatter ikke jeres supportaftale eller test: målgruppen kan bruge ældre versioner, og en funktion kan afhænge af operativsystem, tilladelse, hardware eller sikker kontekst.

Automatisér en lille browsermatrix

Et browserværktøj som Playwright kan køre de samme flows i Chromium, Firefox og WebKit samt med forskellige viewport- og enhedsindstillinger. Brug det til få, stabile kontroller: siden åbner, brugeren kan logge ind, en central post kan oprettes, og den forventede status kan ses bagefter.

1. 1. Genbrug samme hensigt. Test det samme forretningsresultat i hver browser frem for tre forskellige scripts.
2. 2. Find elementer via rolle og synligt navn. Det gør testen mindre afhængig af styling og giver samtidig pres på den semantiske HTML.
3. 3. Brug isolerede testdata. Browsermatrixen må ikke oprette rigtige betalinger, sende kundemails eller ændre produktion ukontrolleret.
4. 4. Gem brugbart fejlbevis. Screenshot, trace, browserprojekt og release skal gøre fejlen mulig at gentage.
5. 5. Kør før udgivelse. Lad relevante fejl stoppe deployment, og gentag et kort smoke test på den faktiske live-side.

En mobil viewport er et hurtigt filter, ikke et bevis

Chrome beskriver selv Device Mode som en tilnærmelse. Det kan simulere viewport, touch, orientering samt langsommere CPU og netværk, men koden kører stadig ikke på telefonens hardware og operativsystem. Brug simulering tidligt og ofte, og afprøv derefter de kritiske flows på mindst de repræsentative rigtige enheder.

• Åbn og luk det virtuelle tastatur omkring de længste formularer.
• Prøv stående og liggende retning, zoom og browserens egne navigationslinjer.
• Brug kamera, fotobibliotek, filvælger, download og deling, når de indgår i arbejdet.
• Afprøv langsom eller afbrudt forbindelse og kontrollér, om brugeren ved, om data blev gemt.
• Gentag på en firmastyret enhed, hvis VPN, proxy, udvidelser eller politikker kan påvirke appen.

Giv en sikker fallback, når en funktion mangler

En manglende browserfunktion må ikke efterlade en aktiv knap, der fejler lydløst. Skjul eller erstat kun den konkrete forbedring, forklar begrænsningen, og bevar den sikre kernehandling hvor det er muligt. Et delingspanel kan eksempelvis erstattes af “kopiér link”, mens en manglende kamerafunktion kan tilbyde almindelig filupload.

• Vis ikke “gemt”, før serveren eller den aftalte offline-model har bekræftet resultatet.
• Slå aldrig adgangskontrol, validering eller HTTPS-krav fra for at støtte en ældre browser.
• Hvis en sikker fallback ikke findes, så stop den konkrete handling med en tydelig forklaring og kontaktvej.
• Log den tekniske fejlkode og browserkontekst uden at kopiere tokens, formularindhold eller unødige personoplysninger.

Typiske fejl

• Kun udviklerens browser testes: Safari-, Firefox-, touch- eller firmapolitikfejl opdages af brugeren.
• Responsivt design kaldes mobiltest: En smal Chrome-viewport bliver forvekslet med en fysisk iPhone eller Android-enhed.
• Browsernavnet styrer koden: User-agent-regler bliver forældede og vælger forkert adfærd.
• Alt nyt får en polyfill: Bundle, vedligeholdelse og angrebsflade vokser uden et dokumenteret brugerbehov.
• Kun layoutet sammenlignes: Ingen kontrollerer, om data blev gemt, filen kom frem eller login faktisk holder.
• Gamle browsere afvises uden plan: En medarbejder står midt i arbejdet uden fallback, forklaring eller ejer.
• Testmatricen bliver uendelig: Teamet forsøger at dække alle kombinationer og får ikke beskyttet de få kritiske brugerrejser.

Tjekliste før medarbejdere eller kunder får adgang

• ☐ Understøttede browsere, versioner og enhedstyper er valgt ud fra målgruppen.
• ☐ Login, oprettelse, redigering, filflow og andre kritiske rejser er prioriteret.
• ☐ Nye webfunktioner er kontrolleret med aktuelle kompatibilitetsdata.
• ☐ Koden bruger feature detection og en sikker fallback frem for tilfældig user-agent-logik.
• ☐ De vigtigste flows kører automatisk i den aftalte browsermatrix.
• ☐ Mobil simulering suppleres med repræsentative rigtige enheder.
• ☐ Touch, tastatur, zoom, orientering, langsomt netværk og afbrydelse er afprøvet efter behov.
• ☐ Testdata og testkonti kan ikke udløse rigtige betalinger, massebeskeder eller kundedataændringer.
• ☐ En manglende funktion giver en forståelig fallback eller en sikker, afgrænset blokering.
• ☐ Fejl kan forbindes med browserprojekt, release og et reproducerbart flow.

Relaterede guides

Officielle kilder

Browserfunktioner, værktøjer og support ændrer sig. Kontrollér altid de konkrete funktioner og den browsermatrix, jeres brugere faktisk har, før I lover understøttelse.

• MDN: Introduktion til test på tværs af browsere
• MDN: Feature detection frem for browsergenkendelse
• MDN: CSS feature queries med @supports
• WebDX og web.dev: Baseline for webfunktioner
• Playwright: Kør tests i Chromium, Firefox og WebKit
• Playwright: Emulering af enheder og browserindstillinger
• Chrome DevTools: Muligheder og begrænsninger i Device Mode