allan ebdrup bloghoved ny

Browser-extensions er dårligt kodet

Vi har bygget en webapplikation, der gør vores brugere i stand til at logge JavaScript-fejl i produktion. Den installeres som Google Analytics - bare indsæt et script og du er i gang med at logge fejl. Vi er i lukket betatest med cirka 400 brugere. Der er blevet monitoreret over 12 millioner sidevisninger for JavaScript-fejl og vi har logget i hundredetusindvis af fejl, så nu begynder der at tegne sig nogle interessante mønstre.

Browser-extensions

En af de ting vi kan se er, at der opstår enormt mange JavaScript-fejl i browser-extensions. Flere browsere lader nemlig udviklere lave extensions til browseren i JavaScript, og når der er fejl i disse extensions, logger vi dem også. Det står slemt til. Cirka 24 procent af alle de fejl, vi logger, kommer fra browser-extensions. Vi filtrerer selvfølgelig disse fejl fra i vores brugeres log, så loggen ikke sander til i fejlbeskeder fra extensions.

Er der nogen, der har et bud på, hvorfor browser-extensions kaster så mange fejl? Er det fordi dem der udvikler dem ikke tester godt nok? Er de meget svære at teste?

Man bliver jo også bekymret for, at nogle af disse fejl vil gøre, at websites ikke fungerer efter hensigten. En dårligt kodet extension kan måske ødelægge siden. Er der nogen, der har oplevet det?

Kommentarer (15)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Claus Junker Jørgensen

Hvorfor? Fordi JavaScript i sig selv indbyder til at kaste mange fejl. Et sprog der har 5 forskellige former for null, og hvor man generelt ikke gør i range checks o.lign. er en stensikker kandidat til massere af fejl.

Og da fejl i JavaScript, principelt ikke har nogen videre effekt på resten af koden, er det jo normalt at ignorer dem.

Hvis man med vilje lader noget kode terminate via. en fejl, vil det jo dukke op i jeres logger, selvom fejlen var intentional.

  • 4
  • 6
Peter Müller

Der er adskillige extensions som injicerer html på hjemmesiderne, hvilket altid giver potentielle fejlmuligheder. For Chrome extensions gælder dette dobbelt, da det lader til at scriptingen foregår på selve hjemmesiden i stedet for i en sandkasse, som i Firefox.

Jeg har eksempeltvis observeret adblock html og css i emails jeg har modtaget, som har sat display: none; på indholdet af mailen. Dette er sket fordi mailen er skrevet i en webmail som benytter design mode, hvor adblock har indsat sine ting.

Og jeg ser også jævnligt javascriptfejl i min konsol på en mængde hjemmesider jeg besøger. Og debugging i konsollen. Det børe man altså smide et commit hook i sin versionsstyring om så det bliver fjernet.

  • 1
  • 1
Peter Müller

Claus Junker, det ville klæde debatten hvis du skrev lidt mere velovervejet og med bare et minimalt forsøg på at forstå problemstillingen.

Nej, javascript indbyder ikke til at kaste en masse fejl hvis du gør dit arbejde ordentligt.

Nej, det passer ikke at javascriptfejl ikke har nogen effekt på resten af koden.

Og hvis man med vilje lader kode afslutte ved at kaste fejl så vil jeg mene man som udvikler har begået en fejl.

  • 12
  • 1
Daniel Aleksandersen

Jeg kan dele litt insight fra en browser tester for en browser som tillater UserJS og extensions—som begge er måter for tredjeparter å injete script inn i tredjeparts sider—som ser hva brukerne sender inn av feil, og som en browser extension utvikler som har møtt noe av de samme problemene.

Det er mange brukere som sender inn bugger med populære nettsider som ikke virker fordi en extension ikke fungerer som forventet. Hovedsakelig er det at extensionen sin funksjonalitet ikke er ønsket på akkurat den siden og at det skaper konflikter. På de extensionene hvor jeg har måtte gå inn å se på koden er det også mye dårlig arbeide og løse ender. Det er nesten ikke tatt høyde for at browseren ikke er i en ideell state som forventes.

Som en extension utvikler kan jeg fra andre siden si at det er enkelt å ta høyde for mye, men at det stadig er endringer som du ikke klarer å forutse. Funksjonaliteten du vil oppnå er ofte et moving-target og tredjeparter kan være veldig uforutsigbare.

  • 3
  • 0
Jacob Christian Munch-Andersen

Det er ret almindeligt at dårlig JavaScript laver fejl. Selve sproget som sådan tror jeg ikke er så forskelligt fra alle mulige andre sprog på det punkt, men der er den væsentlige forskel at brugeren ikke bliver belemret med at siden crasher blot fordi der er en runtime fejl i et stykke JavaScript. Dermed kan man let overse at man har lavet en runtime fejl.

Det er ganske typisk for et stykke begynder prøv-sig-frem kode at det efter en umådeligt ineffektiv udviklingproces sådan set gør hvad det skal, plus en hel del andre ting som blot ikke har synlig effekt, fx fordi de stykker kode crasher før de gør noget synligt.

  • 1
  • 0
Rasmus Wihlborg Jelsgaard

...er formodentlig ikke væsentligt forskellig fra alt andet kode, der bliver skrevet. Jeg ved det ikke, men ville meget gerne se noget forskning og/eller statistik, der kan underbygge/afvise påstanden?

Udvikling og test af browser extensions er en anden snak. Det er interessant, hvis der mange fejl i dem ifht. andet software, hvad jeg dog også gerne vil se dokumenteret, før vi hidser os op og hudfletter de stakkels extension udviklere. Hvis det er tilfældet, kunne et forsigtigt bud være, at det er svært at integrationsteste kode, der skal køre i et heterogent miljø med et stort antal slutbrugere.

Jeg kunne også forestille mig at det kunne være svært at lave automatiserede tests af den type af software. Er der ikke nogen, der arbejder indenfor området som udvikler, der kan kaste lidt mere lys over det? Hvordan griber man det an og hvordan er omkostningerne ifht. andre typer af software, hvor man måske selv har mere kontrol over de systemer, man skal integrere med?

  • 0
  • 0
Jesper Louis Andersen

Mit bud er som sådan temmeligt simpelt: Kode kan godt have fejl og warnings uden at den nødvendigvis gør det "forkerte" i det typiske tilfælde. Du logger ganske vidst en fejl, men du logger nok ikke hvor mange gange det er gået godt? Så et eller andet sted er det bare et udtryk for error-paths i noget kode men du kender ikke frekvensen af hvor ofte den kode bliver kørt.

Når det så er sagt, så tillader et sprog som Javascript dig ret meget uden at det går ud over brugeren. Havde du lavet samme småfejl i C f.eks., så havde programmet crashet med en passende SIGSEGV ved den første grumme fejl og så havde brugeren af programmet nok fundet sig et andet program. Det er, til dels, også en konsekvens af HTML: En forkert HTML side giver ikke brugeren en fejl, men derimod et bedste renderingsforsøg. Det er grundliggende forkert, men desværre hvad man endte på.

Du kan formentlig skrive "pænt" JS der ikke er omfattet af ovenstående, men faktum er at rigtigt meget af det kode der er derude er bundhamrende elendigt.

  • 0
  • 0
Allan Ebdrup Blogger

Jeg har kigget lidt mere på data, og en del af fejlen har fejlbeskeden:

Uncaught Error: chrome.tabs can only be used in extension processes. See the content scripts documentation for more details.

Og kommer fra

extensions/renderer_extension_bindings.js (Chrome 16)

eller

chrome /RendererExtensionBindings (Chrome 15)

Så er det extension-programmøren der ikke har læst dokumentationen godt nok. http://code.google.com/chrome/extensions/content_scripts.html

Det virker ihvertfald som en ret banal fejl.

  • 0
  • 0
Jonas Høgh

En forkert HTML side giver ikke brugeren en fejl, men derimod et bedste renderingsforsøg. Det er grundliggende forkert, men desværre hvad man endte på.

XHTML har været specificeret til at fejle hårdt ved ugyldigt input siden den kom ud i 1999. Det har ikke ligefrem været noget stor succes som standard. Derimod er man gået tilbage til at forsøge at rendere så meget som muligt i HTML5.

  • 2
  • 0
Casper Bang

Det virker ihvertfald som en ret banal fejl.

Udover at JavaScript er et godmodigt dynamisk sprog, er det også en anden vinkel på historien, nemlig versionering! Hvis man beskæftsiger sig med andre plugin frameworks, ved man at vedligeholde kompatibilitet samtidig med at ting udvikler sig, er et særdeles tricky balancegang... og få ting ændrer sig så meget som browsere!!!

  • 0
  • 0
Casper Bang

Det kan godt være. Mener du at fejlen er opstået pga opdatering af Chrome?

Ja samt indirekte breaks; hvor folk har skrevet workarounds der skaber problemer når problemet rent faktisk rettes senere hen. Hører man til dem der skriver plugins til f.eks. NetBeans (udvikler IDE til Java, C, PHP etc.) så kender man bestemt til dette problem. Versionering er et tricky emne der får relativ ringe dækning i branchen: Specificér for bredt, og du ricikerer at ramme versioner der ikke er kompatible; specificér for løst, og du kan ikke foretage dig andet end at hente/bygge opdateringer.

  • 1
  • 0
Jan Gundtofte-Bruun

hvis det er forventeligt, kan du så forklare hvordan du er kommet frem til det?

Er det ikke bare et spørgsmål om "masse" -- kan ske du kun kører een browser, men hvis du kører med 15 extensions så vægter de meget tungt. Endvidere kan vi efterhånden godt antage at browseren som sådan kan være ret godt kodet, mens de enkelte extensions kan være skrevet af "hvem som helst" med følgelig mulighed for dårligere kvalitetskontrol. (Ikke ment som kritik; de fleste "one man band" aktører har bare ikke samme muligheder som flagskibene.)

Lad os antage at der er 5% sandsynlighed for at en extension eksekverer buggy kode mens den kører. Hvis man har 15 extensions kørende, så summer "sandsynlig" sig op til "forventelig", og så er det i høj grad et spørgsmål om hvorledes de påvirker hinanden og siden man ønsker at se.

  • 0
  • 0
Log ind eller Opret konto for at kommentere