Apple scheidt engine en userinterface in WebKit2

Apple heeft op de WebKit-mailinglist een nieuwe versie van de browser render-engine aangekondigd. WebKit2 scheidt webcontent van de gebruikersinterface om zo te voorkomen dat een crash de hele browser onderuit trekt.

WebKit-ontwikkelaar Anders Carlsson laat via de ontwikkelmailinglist van het project weten dat binnenkort de WebKit2-code zal verschijnen in de WebKit-repository. De grootste vernieuwing is het scheiden van webcontent en de user interface. Hierdoor draait elk tabblad in de browser in zijn eigen afgeschermde proces.

Google heeft deze functionaliteit al geïmplementeerd in zijn webbrowser Chrome, dat gebaseerd is op WebKit. De scheiding is bij Chrome echter ingebouwd op applicatieniveau, en niet in het WebKit-framework. Dankzij WebKit2 kunnen softwareprojecten die op de layout engine zijn gebaseerd, waaronder Safari, profiteren van deze scheiding. Mozilla en Microsoft zijn bezig met soortgelijke functionaliteit voor Firefox en Internet Explorer.

Door de wijzigingen moest de gehele api van WebKit op de schop, en de ontwikkelaars hebben de mogelijkheid aangegrepen om andere verbeteringen door te voeren. Zo streven de ontwikkelaars er naar om de hele api non-blocking te maken, wat de browser flexibeler maakt. Voor de implementatie van deze functionaliteit introduceert Apple verschillende typen callbacks, waarbij het mogelijk is om eigen code te injecteren als de callbacks niet afdoende blijken te zijn.

Reacties (51)

[_Thanatos_]

Maar waarom zoveel moeite doen om te zorgen dat een crash geen al te desatreuse gevolgen heeft? Waarom niet de oorzaak van het probleem gewoon fixen? Ja zal wel moeilijker zijn, maar in beginsel hoort een brower gewoon niet te crashen, toch?

[Maurits van Baerle]

Omdat de oorzaak van de crash vrijwel altijd buiten de macht van de browser bouwers ligt. Het is niet voor niets dat het vaak om crashende plugins gaat, software die door derden is ontwikkeld.

Adobe's Flash team lijkt wel uit één stagiair te bestaan die af en toe dronken wat aan de Flash-plugin prutst en dat als Final uitbrengt. Dat ik meerdere keren per dag een crashende browser heb is te wijten aan Adobe die er een puinhoop van maakt, niet aan Mozilla, Apple, Google, Microsoft, Opera of welke browser bouwer dan ook. Als de Flash plugin crasht neemt hij de browser mee in z'n val. Met dit soort trucs los je Adobe's puinhoop niet op, je voorkomt wel dat de rest van de browser er last van heeft.

Hetzelfde geldt voor web-devers die brakke code uitbrengen. Als browser bouwer heb je daar geen invloed op, het enige wat je kunt proberen is de schade te beperken, oplossen ligt buiten hun macht.

[Reactie gewijzigd door Maurits van Baerle op 26 juli 2024 09:41]

[_Thanatos_]

Als een plugin crasht, is daar niet aan te doen, maar dan is het zaak om de plugins in een apart proces te laden. Als webdevvers met "beschermde" code zoals javascript en css de browser kunnen laten crashen, is dat onmiskenbaar een bug in de browser. De runtime van die talen zit immers in de browser, en de browser behoort de boel goed te interpreteren. Een "fout" mag geen crash veroorzaken; alleen een niet-werkende pagina.

Het is hetzelfde als dat een crashende windows-applicatie heel windows onderuit kan halen. Dat kan niet, tenzij de applicatie iets raars met drivers doet. En als het zonder exotische dingen wel lukt, dan is het een bug in het OS. Zie je de analogie?

[Reactie gewijzigd door _Thanatos_ op 26 juli 2024 09:41]

[Verwijderd]

Mooie ontwikkeling, niet alleen voor Safari maar voor alle browsers. Ik hoop dat deze verbetering dan ook snel aanwezig zal zijn in toekomstige versies! Nu nog alle plug-ins & add-ons volledig apart laten draaien, hier durft bvb Flash Firefox wel eens laten vastlopen ...

[Verwijderd]

Wat betreft plugins kun je van firefox deze beta gebruiken, dan nemen plugins firefox niet meer mee als ze crashen.

[mmjjb]

InternetExplorer crashed ook niet als er een plugin crashed, dit door verdeling van de processen.

[Verwijderd]

Dat beweerde ik ook niet? KimG klaagde over iets in Firefox dus reageerde ik daarop.

[Barleone]

offtopic:
Mijn Win7 IE8 tabblad recovery is echter niet erg slim:
• Bezoek pagina
• flash van de pagina crashed.
• IE-tab crashed mee.
• IE gaat nieuwe tab openen met dezelfde pagina.
• IE-tab crashed weer opnieuw vanwege de Flash crash.
Iets met vizieus en cirkel

[Reactie gewijzigd door Barleone op 26 juli 2024 09:41]

[OMEGA_ReD]

Safari (x64) loopt ook niet vast als er een plugin crasht.

[CyBeR]

Maar wel als webkit zelf ergens op crasht.

[Dingen]

Het mooie hiervan is dat allerlei andere producten die zijn gebaseerd op Webkit hier ook profijt van hebben (WebOS, Epiphany, Steam, Adobe AIR, etc).

[stephenophof]

De internetbrowser van Android heeft ook WebKit

[tweakerbee]

En erg weinig plugins.

[arjankoole]

En erg weinig plugins.

plugins hebben weinig te maken met het HTML render deel.

[Caviatjuh]

Volledig offtopic:
Gebruikt steam webkit? Ik kan het me bijna niet voorstellen, ik heb geen flash geinstalleerd voor IE en steam loopt ook te zeuren over flash, denk dus eerder dat die de IE engine gebruikt.

[Sleepkever]

Steam gebruikt inderdaad de IE render engine. Echter is er sinds een paar weken een Steam beta client uit die heel de UI op de schop neemt en de switch van de IE engine naar een webkit engine maakt. Meer info hier voor de geintresseerde.

[MacWolf]

En mede door deze switch van render engine komt Steam binnen enkele maanden uit voor de Mac. Op het moment dat de huidige Windows beta ge-released wordt

[arjankoole]

Sterker nog: april komt Steam:Mac uit toch?

[ashemedai]

De huidige UI beta van Steam is van de IE rendering engine naar die van Webkit overgestapt. Dus dadelijk zijn alle steam clients over. (Logische stap als je hun Mac OS aankondiging in ogenschouw neemt.)

[ledog]

Van alle webkit ontwikkelingen draagt apple ongeveer 75% bij. Het is open source, maar Apple, en veel andere (mobiele) hardware bouwers hebben groot belang bij het verder ontwikkelingen van WebKit en HTML5 omdat het de grip van SilverLight en Flash op de markt van webapplicaties gaat terugdringen.

Ongeveer 80% van alle mobiele webcontent wordt gerendered in applicaties die hiervoor WebKiit gebruiken.

Als het aankomt op het opmaken en renderen van webcontent heeft Apple gekozen om volledig in te zetten op open standaarden en open source. Apple wil geen 3rd party oplossingen als Flash of Silverlight op het iPhone OS omdat het bedrijf in het verleden heeft geleerd dat het daardoor voortgang van innovatie op het eigen het platform uit handen geeft.

Flash is exit en WebKit heeft de toekomst, zeker op mobiele platforms.

[Blokker_1999]

bs, door het weren van flash of silverlight beperk je de mogelijkheden voor je gebruikers. En als men echt voor open standaarden zou gaan dan had men niet voor h.264 gekozen voor html video.

[Dingen]

H264 is een open standaard.

[DutchStoner]

Dat kan je niet zo stellig verklaren. Bijvoorbeeld;

"If you distribute H.264 codecs in a jurisdiction where software patents are enforceable, and you haven't paid the MPEG-LA for a patent license, you are at risk of being sued. "

bron; http://weblogs.mozillazin...0/01/video_freedom_a.html

of check deze. The HTML5 video mess; http://tedwise.com/2010/0...-video-mess-see-it-today/

[Reactie gewijzigd door DutchStoner op 26 juli 2024 09:41]

[Arthur]

Er is een verschil tussen een open standaard en een gratis standaard. H.264 is open, maar niet gratis. Iedereen kan het implementeren, maar niet iedereen mag dat voor niets doen.

Overigens is ook helemaal niet zeker dat het door Mozilla aangehangen "Ogg Theora" altijd door iedereen gratis toegepast mag worden. De ontwikkelaars van Theora geven het gratis weg, maar gezien de vrij algemene aard van veel softwarepatenten is het best goed mogelijk dat Theora (onwetend) videocodec-patenten schendt die derden in bezit hebben. Als deze hiervoor vergoedingen zouden gaan eisen (hetzelfde doemscenario wat over H264 geschetst wordt), dan loopt ook Theora het risico niet meer gratis te mogen zijn.

[Reactie gewijzigd door Arthur op 26 juli 2024 09:41]

[DutchStoner]

er is ook een verschil tussen een open-standaard en een standaard. Naar mijn idee is H.264 een standaard. Dus geen open-standaard. De term 'open' wordt normaliter gebruikt om aan te geven dat er geen royalties over betaald moeten worden. Dat is hier duidelijk wel het geval. Het is wel zo dat de term 'open' alweer een tijdje discutabel is.

[Maurits van Baerle]

Nee, open betekent dat iedereen de specificaties kan inzien en een eigen implementatie kan en mag bouwen. Of daar wel of niet kosten aan vast kunnen zitten heeft er niets mee te maken.

H.264 is dus gewoon een open standaard en iedereen die dat wil kan gewoon de spec downloaden en aan de slag. Geen gedoe met reverse-engineering zoals dat bij gesloten standaarden vaak nodig is.

[Reactie gewijzigd door Maurits van Baerle op 26 juli 2024 09:41]

[sumac]

H.264 is een open standaard, alleen niet gratis.

[FortezzA_64]

Hierdoor draait elk tabblad in de browser in zijn eigen afgeschermde proces.

Wat er toe kan leiden dat bijv. browsers multi-threated worden; in ieder geval meer processen draaien dan de huide browsers.

[Tha_Butcha]

Ja, maar soms gebeuren er crashes. Dat heet het hebben van een contingency plan. Kan bijvoorbeeld door smerige ajax code. Daar hebben de makers van webkit niks te mee te maken, dan wel invloed op.

Je gaat ook niet zeggen dat een auto slecht is, omdat ie gordels heeft, toch?

[Verwijderd]

Mijn ervaring is dat browsers die gemaakt zijn met de webkit altijd het mooist en het snelst lopen. Een goede standaard.. top.

[lasharor]

Misschien een domme vraag maar, heeft Apple dit nou gedaan of implenteert het bedrijf nou gewoon een vernieuwing (die nieuwe webkit engine) in safari?

[Dingen]

Apple is begonnen met het WebKit project om als render engine voor hun browser (Safari) te dienen. Omdat het echter open source is, zijn er allerlei andere producten (zoals Chrome) die hier ook gebruik van maken.

[_Silencer]

Apple heeft een fork van KHTML (KDE project) gedaan, dit is WebKit geworden. Door de fork moeten ze de voorwaarden van KHTML respecteren en daarom dat het open source is. Dus Apple heeft WebKit niet gemaakt vanaf 0, maar denk dat veel mensen blij zijn dat ze met dit project begonnen zijn.

[djhartman]

Je kan je echter afvragen in hoeverre KHTML nog terug te vinden is in de code nu. Er is VEEL veranderd en dat is maar goed ook. Respect voor de KHTML mensen, maar het succes van WebKit is toch grotendeels aan Apple te danken (en de laatste 2 jaar ook aan Google natuurlijk).

[Xthemes.us]

Er word ook overwogen om KDE webkit te laten gebruiken omdat dit standaard bij Qt inzit ( QtWebKit). Er is ondertussen ook de mogelijkheid om Konqueror de webkit engine te laten gebruiken (moet wel de kde4-webkitpart package worden geinstalleerd).

Ik ben benieuwd of deze nieuwe versie van webkit in bijvoorbeeld Qt 4.7 terechtkomt.. zou een leuke extra feature geven voor diverse webkit based browsers zoals Arora en Rekonq.

[Verwijderd]

En het is opensource, niet per se omdat die van Apple zulke toffe jongens zijn, maar omdat ze Webkit gebaseerd hebben op de KHTML engine van KDE. Na behoorlijk veel strubbelingen over de manier waarop Apple wijzigingen terugrapporteerde aan de KHTML crew, is nu Webkit de de facto standaard is geworden, met browsers voor Mac, KDE, GNOME, met Chrome en met alle mobiele browsers.
Een mooi voorbeeld van Opensource ontwikkeling dus, waar Apple inmiddels ook de vruchten van plukt!

[Verwijderd]

Apple heeft heel veel OpenSource projecten. En tuurlijk profiteren ze hier van, anders zouden ze het niet doen. Zelfs CoreFoundation is OpenSource.

Ga maar eens kijken op:

http://opensource.apple.com/

Ook de laatste technologie Grand Central Dispatch is open source in de hoop dat het opgepakt wordt door bijvoorbeeld Linux. Zie libdispatch.

Edit: Dubbelpost, edwingr zegt hieronder hetzelfde.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 09:41]

[Zer0]

Voor de volledigheid, Apple heeft WebKit geforkt van KHTML, welke gelicenceerd is onder LGPL. Als gevolg daarvan is WebKit open source.

[Zero Grav]

Apple heeft de open-source engine aangepast/herschreven om dit toe te laten. Het wordt echter terug met de gewone Webkit samengebracht omdat dit verplicht wordt door de licentievoorwaarden.

[edwingr]

Net als bijv. Google en IBM, heeft ook Apple open source software omarmd. Net als bij die andere bedrijven is dat ook bij hun niet omdat ze "toffe jongens" willen zijn, maar om de resultaten in hun producten te kunnen gebruiken. Uiteindelijk is het de bedoeling dat dit een goede wisselwerking tussen oss community en bedrijven teweeg brengt, waar beide partijen beter van worden. In het geval van webkit lijkt dat (na wat opstartprobleempjes) prima te werken.

zie ook: http://www.apple.com/opensource/

[thijsje66]

Ik wilde net zeggen, die functie heeft chrome toch ook? Nou sluit chrome bij mij wel de hele browser, maar herstelt ook netjes alle tabs.

Dus imo een erg mooie ontwikkeling, en natuurlijk weer een +1 voor apple. Nou nog HTML5 (of zit dat er al in?) erin gooien, en safari gaat richting de Chrome performance.

Alleen is de interface van Chrome toch mooier.

Sandbox FTW!

edit:
@Dingen
Epiphany hoeft van mij niet, dan installeer ik wel Chrome. Werkt toch beter vind ik.

[Reactie gewijzigd door thijsje66 op 26 juli 2024 09:41]

[ZpAz]

Beide browser maken gebruik van webkit, ze hebben beiden dezelfde html5 support dus.

[MoietyMe]

Alleen loopt de CSS3 support bij Chrome wat achter. Zo hebben ze een hele tijd geen support voor @font-face gehad. Ik weet niet of dat er nu wel in zit.

[curry684]

@font-face was in Chrome disabled tot december 2009 wegens security issues.

Voor de huidige status van HTML5 en CSS3 features zie http://findmebyip.com/litmus/

[Dingen]

Als je met de zoekmachine van Tweakers.net zoekt in het afgelopen jaar naar de steekwoorden "Apple", "Android", "Google" en "Microsoft" komt daar het volgende lijstje uit:

403 resultaten voor Apple
457 resultaten voor Android
485 resultaten voor Google
647 resultaten voor Microsoft

Dus... waar heb je het over?

[Verwijderd]

Dit is wel even wat meer dan een scheet van Apple. Dit is een grote verbetering voor WebKit, wellicht de beste opensource web rendering engine op dit moment.

Iedere andere grote tech site heeft hier trouwens wel een stuk over; slashdot.org , osnews.com , arstechnica.com , etc

Als je tech nieuws zoals dit niet wilt zien vraag ik me serieus af welk tech nieuws volgens jouw dan wel post waardig is.

En WebKit is nou eenmaal destijds door Apple geforked van KHTML dus logisch dat Apple sterk verbonden is aan WebKit.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 09:41]

[Gamebuster]

Waar slaat dit nou weer op? Het onderwerp van dit artikel is Webkit, niet Apple. Als je geen interesse hebt in de vooruitgang van een browser moet je misschien eens teruggaan naar Fok!, of gewoon dit artikel overslaan.

Er zijn namelijk mensen die wel interesse hebben in dit artikel, zoals ik.

[Reactie gewijzigd door Gamebuster op 26 juli 2024 09:41]

[Verwijderd]

Het is alweer 100 jaar geleden dat ik redekundig ontleden op school heb geleerd, maar als je de titel van het artikel pakt, "Apple scheidt engine en userinterface in WebKit2", dan is "Apple" toch wel degelijk het onderwerp van de zin.