Mozilla dropper Metro Firefox

Der er for få brugere på Microsofts Metro-brugerflade til, at det kan betale sig med en dedikeret udgave af Firefox. Sådan lyder det fra Mozilla, som nu dropper Firefox til Metro efter to års udvikling.

Kun fire dage inden at Firefox skulle indtage Metro-brugerfladen på Windows 8, vælger Mozilla helt at droppe udgivelsen. Det skriver Computerworld.com.

Der er simpelthen for få der overhovedet bruger Microsofts Metro-brugerflade til, at Mozilla vil bruge ressourcer på en dedikeret udgave af Firefox til Metro.

»På hvilken som helst dag er der millioner af mennesker, der tester præ-udgivelser af desktop version af Firefox. Men vi har aldrig registreret mere end 1.000 aktive brugere af Firefox til Metro,« skriver Johnathan Nightingale, vicedirektør for Firefox, på sin blog.

Ifølge Johnathan Nightingale er der derfor for få, som har brugt test-versionen af Firefox til Metro, til at browseren er gennemtestet nok. Han forudser, at en lang række fejl vil blive afsløret ved en udgivelse, hvilket ikke vil være besværet værd, når så få brugere har vist interesse i en Metro-udgave.

Mozilla har brugt omkring to år på at udvikle en Metro-udgave af Firefox. Det store arbejde bliver dog gemt, hvis brugerne på et senere tidspunkt skulle tage den kontroversielle brugerflade til sig.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (13)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Uffe Seerup

IE er integreret dybt i Windows, så selvfølgelig har IE en fordel.

IE bruger ikke APIer som andre browsere ikke også kan anvende. Der er ingen indbygget fordel for IE - der er ingen "skjulte APIer". Grunden til at IE føles mere "smooth" end de andre browsere på både desktop og i "Modern" er formentlig at IE benytter hardware acceleration når de kan (DirectX APIerne).

Det som Bo erindrer er formentlig den diskussion om at det kun var IE som kunne benytte de APIer der var nødvendige for at kunne lave en browser under "Modern". Oprindeligt havde Microsoft ikke planer om at tillade apps at benytte disse API'er. Det ville betyde - i lighed med iOS - at andre ikke kunne lave browser "apps".

Det klagede både Google og Mozilla dog over, og hellere end at tage slagsmålet, accepterede Microsoft at browsere kunne godkendes som særlige apps - som kunne tilgå de dele af APIet som ellers er låst for apps. Både Google og Mozilla har fået sådan en "key".

  • 4
  • 0
Daniel Udsen

Jeg testede, laggede og afinstallerede. Det er nok en af af grundene til at det ikke er mere udbredt. Chrome til Metro har iøvrigt samme problem, IE kører betydeligt hurtigere i Metro end de andre.

Som jeg har forstået det kører MS applikationer nativt mens 3je parts apps fra appstore køres virtualiseret inde i en .Net container. det giver selvfølgeligt MS egne programmer en potientiel hastighedsgevinst. Det står i direkte modspil til både apple's IOS og google's android hvor der ikke er forskel i adgang til rå metal for deres egne apps og diverse 3je parts apps.

Precist hvad der foregår er gemt i det politiske/marketing mæssige spil imellem de involverede firmaer, men hovedproblemet er svjv at MS egne apps ikke er ligestillede med 3je parts apps og at det ikke bare lige er så simpelt som lovet i praksis for 3je parter at få den samme adgang.

  • 1
  • 0
Svend Eriksen
  • 0
  • 0
Jonas Høgh
  • 1
  • 0
Daniel Udsen

  1. Hverken Chrome, IE eller Firefox er "store apps", de er helt almindelige Win32 applikationer, blot med et UI, der ligner resten af "modern UI".
  2. du kan sagtens skrive "store apps" i C++ uden det har det fjerneste med .Net at gøre.

Jeg mener samme binære objekt kode bruges svjv på både XP, vista, og 7 der alle er win32, hvor både chrome, så hvad er det firefox forsøger at porte til? Det kan vel ikke kun værre et "Modern UI" skin? Der er noget her der ikke stemmer.

Min forståelse er at Modern udover et nut GUI skin også er "longhorn reborn" altså en ren "virtuel platform" hvor der kompileres til et runtime og ikke direkte til den underliggende platform, der så ikke længere er win32 kompatibel. Er det ukorekt?

  • 0
  • 0
Johnnie Hougaard Nielsen

Det står i direkte modspil til både apple's IOS og google's android hvor der ikke er forskel i adgang til rå metal for deres egne apps og diverse 3je parts apps.

Faktisk gør Apple en stor forskel, således at kun deres egne apps får fuld adgang nær på rå metal. Helt konkret kan fx Google Chrome ikke få lov til at køre med sin egen V8 JavaScript under iOS, men er tvunget til at køre JavaScript via en facilitet som iOS stiller til rådighed. Denne er langsommere end hvad Safari får lov til at køre med, således at det er umuligt at lave en konkurrerende browser med fuld hastighed. Derudover får konkurrerende browsere ikke lov til at blive standardbrowser under iOS, så der er meget langt fra lige vilkår.

  • 2
  • 0
Jonas Høgh

Jeg mener samme binære objekt kode bruges svjv på både XP, vista, og 7 der alle er win32, hvor både chrome, så hvad er det firefox forsøger at porte til? Det kan vel ikke kun værre et "Modern UI" skin? Der er noget her der ikke stemmer.

Nej et skin er nok at forsimple det lidt. Der skal så vidt jeg har forstået det bruges nogle nye modern-specifikke UI API'er for at implementere integration med den nye platform, fx de standardiserede widgets til charms og søgning, måden en app skal kunne resizes og dockes, o.l. Men denne integration foregår for browsere i modern mode på en speciel måde, som er tættere på metallet, og ens med den IE modern bruger.

Min forståelse er at Modern udover et nut GUI skin også er "longhorn reborn" altså en ren "virtuel platform" hvor der kompileres til et runtime og ikke direkte til den underliggende platform, der så ikke længere er win32 kompatibel. Er det ukorekt?

Det er rigtigt at windows store apps kører i en sandkasse. Men som jeg forstår det er det mere en "du må kalde disse API'er og intet andet" sikkerhedsvalidering ala iOS, det skal ikke forveksles med en fuldt "managed" VM, hvor alt er garbage collected som Java eller .Net. Det der gør det tricky er, at når du skriver en store app i c++, så KAN du interoperere med .Net, og du har mulighed for at tilgå objekter på en managed heap der kører i en instans af .Net runtimen. Men det er valgfrit. Du kan også kalde WinRT API'erne direkte fra helt almindelig C++ kode, der blot er udvidet med diverse platform-uafhængige typer, der letter arbejdet med at compile til både x86 og ARM.

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