Mozilla stopt met ondersteunen embedded Gecko

Mozilla heeft aangekondigd niet langer het embedden van browserengine Gecko in andere applicaties te ondersteunen. De benodigde code wordt niet meer onderhouden en staat nieuwe ontwikkelingen voor Gecko in de weg, aldus Mozilla.

Bij monde van Benjamin Smedberg, die verantwoordelijk is voor Gecko's embeddingmodules, heeft Mozilla bekendgemaakt niet langer binary embedding te ondersteunen. Volgens Smedberg kost de ondersteuning veel tijd die ook in Firefox gestopt kan worden. Ook passen aanstaande verbeteringen in de Gecko-browserengine, zoals het splitsen van pagina's renderen en de gebruikersinterface in verschillende processen, slecht in de huidige oplossing voor embedding.

Smedburg geeft aan de modules gtkmozembed, javaxpcom en de ActiveX-control en plugin te verwijderen uit de Gecko-code. Geïnteresseerde ontwikkelaars kunnen zich melden om deze modules te onderhouden. Smedberg sluit niet uit dat in de toekomst, zodra het renderen in Gecko door een apart proces gebeurt, gekeken wordt naar een nieuwe manier om embedding mogelijk te maken.

Het team achter Camino, een browser van Mozilla voor Mac OS X, overweegt door de aankondiging Gecko in te ruilen voor WebKit. Camino gebruikt Apples Cocoa-interface in plaats van Mozilla xul. Het ondersteunen van embedden heeft nooit een hoge prioriteit gehad bij Mozilla, waardoor de ontwikkeling van Camino achterligt op Firefox. De ontwikkelaars van Camino werken aan de binnenkort te verschijnen versie 2.1 van de browser, die dezelfde Gecko 1.9.2-engine gebruikt als Firefox 3.6.

Reacties (42)

Ik hoop niet dat ze naar webkit gaan. Is een beetje een half gare engine. Neem nu bijvoorbeeld de site www.intramed.nl.

Als je de site in firefox of IE benadert en je beweegt over de menu-items dan zou je ook rollout menus moet zien.

Als je ditzelfde bekijkt met Chrome of Safari dan werkt dit niet. Als je over de menu-items gaat links van de site dan verschijnt er geen tweede menu.

Heb dit maanden geleden al gemeld bij Google maar er is niks mee gedaan.

En dat ligt aan webkit? Denk eerder dat het aan de site ligt. Imho is webkit de beste engine op de markt. Gebruikt in Safari, Chrome, iOS, WebOS, Android en volgens mij ook nog RIM.

Dat veel instanties het gebruiken wil natuurlijk nog niet zeggen dat het, het beste is.

Maar ik denk zeker dat Mozilla de ontwikkelaars die hier mee bezig waren de tijd wel beter kunnen besteden door onder andere aan Firefox te gaan werken.

Misschien is de oorzaak webkit, misschien is de oorzaak slechte code van de site. Moeilijk om zo een oordeel te vellen.

Heb je de code van die site wel 'ns bekeken? Is 'n complete puinhoop. Het verbaast me eerlijk gezegd dat het wel werkt in Firefox en IE.
Safari en Chrome bevatten fouten, maar in dit geval verbaast het me niets dat die site problemen geeft.
Overigens is mijn ervaring bij het testen van sites dat Webkit niet meer fouten of afwijkingen heeft dan Gecko. Google Chrome heeft wel wat eigen fouten erin weten te krijgen, maar ook niet echt heel veel.

Google doet er niets mee omdat het niet hun probleem is maar een probleem van de site bouwer.

Het probleem komt me bekend voor, had ooit ook zoiets met dit type css menu. Je hebt hoogst waarschijnlijk je css verkeerd staan (zelfs de opstelling van de diverse css blokken kan invloed hebben in welke hij selecteert).

Er zijn zat copy/paste voorbeelden op google die werken in elke browser (ze doen het allemaal vrijwel hetzelfde).

Needless to say, wij proberen altijd alles in zo veel mogelijk browsers werkend te maken maar garanderen alleen correcte werking onder IE en FF. Gelukkig gedragen bijna alle browsers zich hetzelfde tegenwoordig.

http://validator.w3.org/c...29&doctype=Inline&group=0

Ik begrijp best waarom het niet werkt.

Dus omdat de maker van die site geen fatsoenlijk JavaScript-menu kan bouwen, is WebKit een gare engine?

Verbaast me niks dat Google hier niks aan gedaan heeft.

Sowieso is Google niet de partij achter WebKit.

Zou blij zijn als Camino webkit gaat ondersteunen, word het eindelijk een beetje een moderne browser.

Voegt Camino dan nog wat toe ten opzichte van Safari?

Een eigen userinterface, die gebruikers wellicht prefereren boven die van Safari. Als Camino overstapt naar WebKit zou het in dezelfde categorie als OmniWeb en iCab passen.

Met gecko is niets mis, het is gewoon spijtig dat Mozilla de gecko engine zo moeilijk integreerbaar maakt in andere projecten.

Heb zelf ooit eens een projectje gemaakt waarbij ik een browserengine moest embedden. Heb uiteindelijk ergens een pakketje gevonden met gecko voor .net en met slechts enkele lijnen code was ik klaar.

De gecko engine is zeker niet perfect en ondersteund misschien wel veel standaarden (valt eigenlijk ook wel tegen) maar is onderhuids behoorlijk log, onhandig, oversized en antiek. Ik denk dat het voor Camino alleen maar beter zal zijn om webkit te gebruiken, alleen al voor de browsersnelheid en het geheugen en processorgebruik. Al vraag ik mij dan af hoe ze zich gaan onderscheiden van Safari.

En nu worden developers een beetje gedwongen om Trident (Internet Explorer rendering engine) te gebruiken als base. Slechte zaak.

Niet alleen WebKit, maar ze kunnen ook aanbieden om de modules zelf te gaan onderhouden, ipv dat het door het Mozilla-team zelf als onderdeel van de 'core' onderhouden wordt. Het is niet voor niets open source. Wat dat aangaat vindt ik het ook een ietwat vreemde aankondiging - ik zou eerder aangeven dat de embedded modules gesplitst worden van het 'core' Gecko project en het aan de OS community overlaten om het project over te nemen en op te pakken, dwz buiten het 'core' Gecko team om.

Overigens lijkt me de Trident render engine niet een geheel verkeerd alternatief sinds versie 9 van IE, het is tenminste niet zo'n slechte keuze in vergelijking met die van IE 6.

[Reactie gewijzigd door YopY op 3 april 2011 10:46]

De IE-engine ondersteunt helemaal geen embedden zoals het in dit artikel bedoeld wordt

Je kunt wel de engine gebruiken en aanroepen, maar dan gebruik je gewoon de IE-engine die op het systeem van de gebruiker aanwezig is. Het gedrag is dan dus onvoorspelbaar. Trident is closed source en kun je daardoor niet meeleveren met je software zoals Gecko of Webkit.

Webkit is het enige serieuze alternatief als het gaat om een goede, open, goed onderhoude, snelle, moderne en xplatform browser engine.

[Reactie gewijzigd door Bosmonster op 3 april 2011 13:18]

Het gedrag is dan dus onvoorspelbaar.

De API is toch behoorlijk gedetailleerd gedocumenteerd.

Dat wel, maar het gedrag niet. Afhankelijk van welke IE-versie op het systeem geinstalleerd is, zal jouw applicatie ineens gebruik maken van de IE6, 7, 8 of 9 engine. Dat betekent dus ook dat je je applicatie met al deze versies zal moeten testen.

Wat dat betreft is het dus vaak handiger om gewoon een WebKit-build mee te leveren.

Niet crossplatform, als Mozilla werd gebruikt i.p.v. IE als render engine is de kans groot dat dit was omdat het een crossplatform applicatie betreft waarbij het nadeel van de filesize niet zo belangrijk is als het voordeel van dezelfde render engine op meerdere platformen. Bij een Windows-only applicatie is het ongebruikelijk om de gebruiker met de extra MB's van de Mozilla render engine op te zadelen.

Nee toch, zoals in het artikel staat kunnen ze ook gewoon WebKit gebruiken.

Als je het artikel had gelezen, had je kunnen zien dat vooral wordt gekeken naar een overstap naar WebKit, die onder door Safari (browser van Apple) en Google Chrome wordt gebruikt.

Het lijkt me dat Trident afvalt, alleen al omdat deze uitsluitend beschikbaar is voor Windows.

Weet niet of IE9 het ook gebruikt maar als dat wel zo is dan zie ik het probleem niet. IE9 is gewoon een hele goede browser.

Volgens mij bestaan er besturingssystemen waar MSIE 9 niet onder werkt. Als dat klopt is Trident geen geschikte keus voor een cross-platform applicatie. Ik heb de indruk dar er relatief weinig Windows Only OpenSource applicaties bestaan.

True, mijn comment was niet zo zeer gericht op dat het de beste optie zou zijn maar op dat IE9 - en daarmee de engine - tegenwoordig best goed is.

Hoe zit het dan nu bijvoorbeeld met Thunderbird? Die geeft immers ook html weer (in de email) en is ook van Mozilla. Gaat die nu een eigen engine gebruiken of?

Aangezien dat ook een XUL applicatie is, is het misschien niet Embedded? De voorbeelden in het artikel zijn allemaal C/C++/Java.

Ik begrijp het punt vanuit de ontwikkeling natuurlijk wel. Maar dit is op zich best wel jammer.

Af en toe heb ik bij spel ontwikkelaars geklaagd over hun gebruik van de IE engine in hun spel/launcher (volgens mij omdat het je standaard profiel gebruikt voor veiligheidsinstellingen - maar dat kan natuurlijk aan de ontwikkelaar hebben gelegen). Maar ze hadden altijd het goede weerwoord dat het gebruik van welke andere engine heel veel moeite kost. En dat is dan al gauw zonde van de tijd van een programmeur.

Misschien is dat voor andere engines nu wel beter geworden. Maar gecko is er nooit sterk in geweest. En als Firefox gebruiker vind ik dat natuurlijk wel jammer.

Maar aan de andere kant kijk ik erg vooruit naar:

zoals het splitsen van pagina's renderen en de gebruikersinterface in verschillende processen

Wacht.. FireFox is toch "open source"? Nou nog 1 reden minder om FireFox te gebruiken.

Vreemde opmerking.

Ja Firefox is opensource, er wordt nu dus meer tijd ingestoken doordat de mensen die zich met de embedded versie van Mozilla bezig hielden zich nou op Firefox zelf gaan richten.

Dat is op de één of andere manier een reden om Firefox niet te gebruiken? Ik kan je logica niet volgen, zou juist een reden zijn om het wel te gebruiken in mijn ogen aangezien de updates nu sneller klaar zullen zijn. Staat je ook vrij om zelf het embedded project op te pakken als dit zo'n groot bezwaar is..

Wat is het punt dat je wil maken? Firefox is open source, net als de Gecko-engine waar het in dit bericht om gaat. De code is beschikbaar onder de MPL/GPL/LGPL.

"Geïnteresseerde ontwikkelaars kunnen zich melden om deze modules te onderhouden" dat is zelfs typisch open source: je kan mee komen helpen als de modules belangrijk zijn voor je. Als de koers van het Gecko-project je niet bevalt kan je ook de code forken en doen wat je zelf goeddunkt ("roll your own").

En zowel firefox als gecko blijven open source. Alleen stopt mozilla met de ontwikkeling van een bepaald deel. Of mag dat ook al niet meer?

Zou dit het begin van het einde voor Gecko zijn?

Nee, want de grootste gebruiker er van, Firefox gebruikt hem nog steeds

Hoezo? Firefox heeft een aardig marktaandeel en zolang die gecko nog blijft gebruiken zal gecko niet zo snel uitsterven en gezien deze zin: "en staat nieuwe ontwikkelingen voor Gecko in de weg, aldus Mozilla." lijkt het er ook niet op dat ze er afscheid van willen nemen. Ze hebben alleen aangegeven dat ze de huidige embedded gecko niet meer ondersteunen omdat dit huidige ontwikkelen tegenhoud.

Het zou mij niet verbazen als ze langzaam aan de huidige gecko engine geschikt willen maken voor embedded toepassingen. Beter 1 engine die het allemaal kan dan meedere engines die je allemaal apart moet onderhouden.

een beetje onduidelijk bericht, ergens anders las ik dit:

I'm a developer at Mozilla. It looks like there is some confusion about this announcement.

1. Most importantly, *it is still possible to create applications that use Gecko*. Even without the Gecko embedding APIs, you can write such apps. For example, there are two separate Mozilla-supported apps that use Gecko: Firefox and Fennec (mobile Firefox). There is also Songbird, which is written in a similar way (the article mistakenly implies Songbird will be negatively affected by this announcement, which is not true - the situation for them is very different than for Camino, for example).

In other words, you *can* still write Gecko apps, but you must integrate tightly with Gecko. This is sort of like the Linux kernel not committing to a stable API, things change as needed (people sometimes complain about that, but overall it lets the kernel move forward faster). Similarly, for Mozilla moving forward is much easier without committing to stable APIs for embedding. But again, you can still write apps that use Gecko without such APIs, just like you can write code for Linux.

2. Second, to clarify the term 'killed' that the article used: If someone steps up to maintain the embedding APIs, they can continue. So in that sense nothing is 'killed'. It is just that Mozilla itself, however, isn't focusing on them, for the reasons I mentioned before.

So, where does this leave things? If you want to write an app that embeds an HTML engine, you can still choose Gecko or WebKit. WebKit is easier to embed, but that has a price. As an example, look how quickly Google added cross-process support to Chrome, without any stable API promises and without anything but Chrome benefiting; Apple is adding cross-process support to WebKit itself, with a stable API, but it is still not complete as the process takes much longer.

I would argue, however, and this is totally my personal opinion - not Mozilla's - that all of this *doesn't really matter*. The places that need to embed a web browser are decreasing, not increasing, because things are moving *into* web browsers, not vice versa. What I am trying to say, is that these days people fire up their web browser and do everything from read news to check email to play games. They don't have separate apps for each that embed a web browser, they have a single web browser for all their activities.

Current applications that embed web browsers, like say Songbird, could today be websites or browser plugins, as browser capabilities have improved so much recently. For that matter, alternative browsers like Flock and RockMelt could be browser plugins.

That leaves projects like Camino and Epiphany that provide much better OS integration than cross-platform browsers like Firefox or Chrome. There is a place for such OS integration. Some of it can be achieved with browser plugins, but I concede that it might be necessary in some cases to do more. I think that such work code be done with the upstream projects, though, to get the best results, as opposed to separate projects that just embed rendering engines. For example, Firefox can render using Qt on Linux, but it needs more love - would be great to see more Qt hackers contribute upstream on that, and to get Firefox/Qt stable.

Commentaar op de moderaties niet hier, maar http://gathering.tweakers.net/forum/list_topics/16