Weiterentwicklung Chromium Browser Komponente

Rund um die LCL und andere Komponenten
stacho
Beiträge: 23
Registriert: Do 26. Nov 2009, 22:29

Weiterentwicklung Chromium Browser Komponente

Beitrag von stacho »

Hallo Leute,

ich möchte die Entwicklung der Chromium Browser Komponente für Lazarus vorranbringen. Dazu erläutere hier mal kurz die Funktionsweise der Komponente.
1. Was ist Chromium?

Chromium ist der Name für ein Open-Source-Projekt von Google der Browser-Quellcode zur Verfügung stellt, um eigene Browser für unterschiedliche Plattformen zu entwickeln. Unter anderem basiert der Browser Chrome auf diesen Quelldaten.

Aktueller Stand 20 February 2014 - Release version 35.0.1849.0

2. Chromium Embedded Framework (CEF)

Das Chromium Embedded Framework (CEF) ist ein Open-Source-Framework zum Einbetten eines Browser- Controls basierend auf Chromium. Es kann auf Linux , Mac OS X und Windows in 32 und 64 Bit-Versionen genutzt werden.

Die aktuelle Stable-Version ist 1750 und unterstützt Chromium 33.0.1750.117

CEF gibt es in den Versionen CEF 1 und CEF3 wobei CEF 1 nicht mehr weiterentwickelt wird. Zumindest CEF1 hat WebKit als Render-Engine verwendet.
CEF kann hier heruntergeladen werden: http://cefbuilds.com/

CEF kommt mit einer Beispielanwendung, die CefClient genannt wird. Geschrieben ist sie in C + + Wer CefClient unter Windows selber bauen möchte, braucht
Visual C++ Express 2010 (kostenlos) mit dem Visual Service Pack 1 und dem Windows 8 SDK.
Für CEF Versionen aus 2013 wird das SDK nicht benötigt.
Dann die Datei in VC++ (Zwei Fehlermeldungen einfach ignorieren) öffnen und Projekt erstellen. Fertig ist das Beispielprogramm.
Man kann über den obigen Link CefClient auch als fertiges Binary herunterladen. Im Menü kann man verschiedene Beispiele für HTML5, DOM, Javascript usw. ausprobieren. Das selber bauen ist natürlich sinnvoll, wenn man mehr in die Funktionsweise einsteigen will.

3. Delphi Chromium Embedded Framework (DCEF3

Delphi Chromium Embedded 3 - kurz dcef3 http://code.google.com/p/dcef3/ ist wiederum die Delphi-Übersetzung von CEF 3.

4. Free Pascal Chromium Embedded Framework (FPCEF3)

Ein Ableger von DCEF3 für Lazarus ist fpcef3 https://github.com/dliw/fpCEF3
Wie schon an anderer Stelle geschrieben: Die Komponente ließ sich bei mir problemlos unter Lazarus 1.1 fpc 2.7.1 Win32/64 installieren. (Wichtig, die passenden Binaries von CEF (3.1547.1412 funktioniert bei mir Stand März 2014) von der CEF-Hompage laden und ins selbe Verzeichnis wie die Anwendung legen).

Generell muss man bei der Weitergabe von Programmen, die die Komponente Chromium verwenden, Die dll’s (Windows) bzw. so’s (linux) aus den CEF-Binarys mitgeben.
Wer nur eine Plattformübergreifende Browser-Komponente für Lazarus benötigt ist mit der aktuellen Version gut bedient.

Wer aber Interaktion mit z.B. Javascript in der Browserkomponente und seinem Programm möchte wird mit der FPCEF-Variante nicht weiterkommen.

Prinzipiell ist die Funktionalität von CEF geeignet komplette z.B. WebBuilder zu bauen. Da möchte ich auch hin. Habe aber leider wenig Zeit, da beruflich sehr eingespannt.

Der Delphi-Entwickler Henri Gourvest hat eine Mammut-Arbeit abgeliefert und FPC auch schon teilweise berücksichtigt. Die zuvor beschriebenen Funktionen hat er über die Delphi RTTI, Generics und FireMonky umgesetzt. Der FPC-Entwickler hat in seinem Fork die Dateistrukturen von DCEF3 über den Haufen geworfen und die Delphi-typischen Dinge gekillt.

Der FPC-Fork scheint wenig Aktivität zu haben. Die Group um Delphi hat noch rege Aktivität aber der Entwickler Henri macht sich zurzeit etwas rar.

Ich möchte nun die FPC-spezifischen Dinge in die Delphi-Variante einpflegen damit Delphi und FPC Entwickler gemeinsam eine Plattform finden.

Wer mitmachen möchte bitte melden!!!

Fortsetzung folgt.

mschnell
Beiträge: 3418
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Weiterentwicklung Chromium Browser Komponente

Beitrag von mschnell »

Ich finde es super, dass Du keinen Fork machen möchtest. :D

Leider keine Zeit und keinen spezifischen Bedarf oder spezifische Kenntnisse auf meiner Seite :(

-Michael

Socke
Lazarusforum e. V.
Beiträge: 2787
Registriert: Di 22. Jul 2008, 19:27
OS, Lazarus, FPC: Lazarus: SVN; FPC: svn; Win 10/Linux/Raspbian/openSUSE
CPU-Target: 32bit x86 armhf
Wohnort: Köln
Kontaktdaten:

Re: Weiterentwicklung Chromium Browser Komponente

Beitrag von Socke »

mschnell hat geschrieben:Ich finde es super, dass Du keinen Fork machen möchtest. :D

Das unterschreibe auch ich. Richtig toll wäre es, wenn die Komponente am Ende mit Lazarus verteilt würde.

Zur Mitarbeit biete ich mich in Architekturfragen an. Operatives Codeproduzieren läuft leider wegen anderer Projekte nicht.
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein

stacho
Beiträge: 23
Registriert: Do 26. Nov 2009, 22:29

Re: Weiterentwicklung Chromium Browser Komponente

Beitrag von stacho »

Hallo socke und mschnell,

danke für die Antworten. Ich versuche gerade die Delphi-Version unter Lazarus zum Laufen zu bringen.
dann fließt erstmal der Code der FPC-Version ins Original ein um die Linux-Funktionalität zu erhalten. Evtl brauche ich da Hilfe da Linux-nob
Dann versuche ich die Dinge die im Original laufen und in Lazurus nicht funktionieren zu implementieren.

Ich hoffe, dass ich das schaffe bevor Henri seine Version updatet.

Eine Frage habe ich da jetzt schon.
Gibt es eine FPC-Entsprechung von Delphi-TValue? :?:

Schönes WE

mschnell
Beiträge: 3418
Registriert: Mo 11. Sep 2006, 10:24
OS, Lazarus, FPC: svn (Window32, Linux x64, Linux ARM (QNAP) (cross+nativ)
CPU-Target: X32 / X64 / ARMv5
Wohnort: Krefeld

Re: Weiterentwicklung Chromium Browser Komponente

Beitrag von mschnell »

stacho hat geschrieben:Ich versuche gerade die Delphi-Version unter Lazarus zum Laufen zu bringen.


Da werden ja sicherlich Strings verwendet, das könnte ein ziemliches Problem werden, wenn man nicht aufpasst.

Jedes aktuelle Delphi benutzt pseudo-dynamisch kodierte Strings, die aber so gut wie immer mit UTF16 Kodierung verwendet werden.

Das aktuelle Lazarus benutzt 8-Bit-Strings, die so gut wie immer mit UTF-8 Kodierung verwendet werden.

In absehbarer Zeit wird Lazarus vermutlich Delphi folgen und als type "String" pseudo-dynamisch kodierte Strings verwenden.

Bei Einsatz von TStringList verschärft sich das Problem noch.

Meine Kollegen in der Firma machen zu diesem Zweck folgendes:
- Alle String Variablen sind ein einem selbst (in einer zentralen Unit) definierten String Typ definiert, so dass man bei Bedarf mit einer Zeile einen passenden String Typ einsetzt.
- Die TStringList Klasse aus Delphi 7 wurde unter einem anderen Namen dem Projekt hinzugefügt, so dass eine effiziente Verwaltung von 8-Bit Strings in Delphi XE möglich ist.

-Michael

Socke
Lazarusforum e. V.
Beiträge: 2787
Registriert: Di 22. Jul 2008, 19:27
OS, Lazarus, FPC: Lazarus: SVN; FPC: svn; Win 10/Linux/Raspbian/openSUSE
CPU-Target: 32bit x86 armhf
Wohnort: Köln
Kontaktdaten:

Re: Weiterentwicklung Chromium Browser Komponente

Beitrag von Socke »

stacho hat geschrieben:Gibt es eine FPC-Entsprechung von Delphi-TValue? :?:

Wenn ich mir die Dokumentation ansehe, schaut mir das wie ein objekt orientiertes Variant aus. In Grundzügen hat es auch gewisse Ähnlichkeiten mit einem Array of const bzw. dem dort verwendeten TVarRec.
MfG Socke
Ein Gedicht braucht keinen Reim//Ich pack’ hier trotzdem einen rein

downloaditweb
Beiträge: 27
Registriert: Do 28. Jan 2010, 13:24
OS, Lazarus, FPC: openSuse Leap 42.3 (L 1.8 FPC 3.0.4)
CPU-Target: 64Bit

Re: Weiterentwicklung Chromium Browser Komponente

Beitrag von downloaditweb »

Hallo zusammen,
ich will die "technische" Diskussion nicht stören, also bitte als Antwort auf den ersten Beitrag verstehen. :mrgreen:

Zunächst - ich bin der Maintainer von fpCEF3. :oops:
Entstanden ist es, weil ich in einem meiner Projekte eine "anständige" HTML-Komponente brauche und es für Lazarus (abgesehen vom Geckobrowser, der auf veraltete Methoden der Firefox-Einbindung setzt) keine gibt, die mit aktuellem HTML + CSS klarkommen.
Für mich ist es trotzdem eine Notlösung, da dadurch eine fast 100MB (Release) bzw. 1,4GB (Debug) -Bibliothek libcef.so benötigt wird - und CEF für meine Zwecke eigtl. komplett überdimensioniert (Plugins, Javascript, ...) ist.
Ich hatte zunächst eine Weiterentwicklung von THTMLPort bzw. https://code.google.com/p/thtmlviewer im Blick, für mich aber zeitlich nicht machbar.
[ Eine Portierung nach C++ wollte ich mir auch nicht unbedigt antun :roll: ]

Der FPC-Entwickler hat in seinem Fork die Dateistrukturen von DCEF3 über den Haufen geworfen und die Delphi-typischen Dinge gekillt.

Ich habe zunächst privat an einer Version ausschließlich für Linux gearbeitet und mich später entschlossen das zu veröffentlichen. Die Windows-Version ist erst viel später (kurz nach der Veröffentlichung) dazugekommen - ein Blick in die Commits verrät das.

Anfangs habe ich auch versucht dcef3 für meine Zwecke (Free Pascal + Linux) zu modifizieren, allerdings ist da eine ganze Menge (subtiler) Änderungen notwendig, sodass ich das Ganze im Prinzip von Grund auf neu geschrieben habe - am Ende sieht das natürlich ziemlich ähnlich aus, auch weil ich - bewusst - versucht habe, nah am dcef-Design zu bleiben, um einen nachträglichen Merge nicht von vornherein auszuschließen. Die Delphi-spezifischen Sachen habe ich natürlich nicht wieder eingeführt :wink:
Was das RTTI-"Zeugs" betrifft: ich habe es erstmal unverändert übernommen, aber auskommentiert und nicht weiter bearbeitet, weil IMO erst alles andere funktionieren sollte.

Prinzipiell steht schon länger eine neue Version von fpCEF3 bereit, allerdings fehlen noch einige Kleinigkeiten, um das wirklich freigeben zu können - was bei mir bisher zeitlich nicht möglich war.
Der Grund dafür ist, dass die Linux-Version von CEF bzw. Chromium einige (bekannte) Bugs hat und fpCEF auch noch nicht fehlerfrei ist, sodass es für mich ziemlich schwierig ist die Ursache für diverse Abstürze zu finden.
Z.B. führt ein bekannter, aber (noch) nicht behobener Fehler in Chromium auf openSUSE zu einem Crash, weil der Wert in /proc/sys/kernel/shmmax nicht richtig interpretiert wird, allein das hat mich eine ganze Weile beschäftigt (inkl. Studieren der CEF- und Chromium-Quellen).
Weitere Problemfelder sind die Stringübergaben und Funktionsaufrufe aus Threads, die nicht von fp erstellt wurden.
Bei bestimmten Seiten (z.B. die Google-Startseite :P ) gibt es auch Abstürze in der V8-Engine von der Art "SIGILL, Illegal instruction", wobei mir die Ursache bisher nicht klar ist.
Das Debugging ist enorm aufwändig, weil CEF einen Haufen verschiedener Prozesse (subprocess) und Threads startet und gdb eine ganze Weile braucht, bis die 1,4GB Debug-Library für jeden gestarteten Prozess im Speicher (bzw. eher Swap) liegt. :(

Kurz: die Linux-Version ist (in der veröffentlichten Fassung) *nicht* stabil, die nächste Version sollte um einiges besser sein und zumindest die Fehler auf meiner Seite behoben haben - die Windows-Version hat (komischerweise) keinen dieser Fehler und ist - soweit ich das bisher testen konnte - stabil.

Erwähnenswert ist übrigens auch https://bitbucket.org/WaspAce/wacef; mit dem letzten Commit wird auch Free Pascal unterstützt, wenn auch kein Linux.
Zuletzt geändert von downloaditweb am So 6. Apr 2014, 01:57, insgesamt 3-mal geändert.

downloaditweb
Beiträge: 27
Registriert: Do 28. Jan 2010, 13:24
OS, Lazarus, FPC: openSuse Leap 42.3 (L 1.8 FPC 3.0.4)
CPU-Target: 64Bit

Re: Weiterentwicklung Chromium Browser Komponente

Beitrag von downloaditweb »

Eine kleine Ergänzung:
Ich beiße mir jedoch die Zähne daran aus, irgendwelche Events zu verarbeiten. So Sachen wie OnProcessMessageReceived werden nicht aufgerufen.

(aus dem anderen Thread)
Konkret kann ich aus dem Stand dazu nichts sagen. Es ist allerdings so, dass ich einige Events nicht gebunden habe, weil sie, wenn sie aufgerufen wurden, Totalabstürze verursachten (also nicht nur einen Subprocess crashten, was zwar zur Folge hat, dass die betroffene Seite nicht geladen wird, aber bei einem erneuten Aufruf alles wieder funktioniert; der Subprozess wird von CEF einfach neu gestartet bzw. eigtl. bei jedem Aufruf neu gestartet).
Teilweise waren die Events aber auch einfach nicht oder falsch gebunden, beides sollte in der neuen - noch unveröffentlichten - Version aber behoben sein.

Richtig toll wäre es, wenn die Komponente am Ende mit Lazarus verteilt würde.

+1
Allerdings habe ich den Eindruck, dass Komponenten mit Delphi-Kompatibilität "nicht gern gesehen" werden. Die mitgelieferten Komponenten sind - soweit ich das jetzt im Kopf habe - Forks oder eigens entwickelt. Ich wage auch zu behaupten, dass die wenigsten bzw. keine Komponenten aus dem Stand mit Delphi funktionieren. Ich weiß auch, dass in der Vergangenheit einiges an Anstrengung unternommen wurde, um z.B. aus Synedit den letzen Delphi-Code zu eliminieren.
Bitte korrigiert mich, wenn dem nicht so ist.

stacho
Beiträge: 23
Registriert: Do 26. Nov 2009, 22:29

Re: Weiterentwicklung Chromium Browser Komponente

Beitrag von stacho »

Hallo downloaditweb

erstmal sorry für die verspätete Rückmeldung - Im Job einiges zu tun. Ist ja toll dass das du dich als Maintainer hier meldest. :D :D
Erstmal großen Dank für die geleistete Arbeit. :!: :!: :!: :!:
Ich hatte mich auf das "original" Dcef gestürzt weil ich den Eindruck hatte, dass da öfter mal aktualisiert wird. Der Maintainer Henri hat z.B. vor kurzem auf ein aktuelles CEF-Release upgedatet.

Wenn du da noch aktiv bist - Super um so besser. Das ganze ist schon sehr umfangreich.

Ich habe mir erstmsal Visual c++ und Delphi XE (was ich schon eingemottet hatte) wieder installiert um ein wenig in die Quellen einzusteigen.

Ich habe gerade mit ganz wenig Modifikationen das cefclient-Beispiel von dcef3 unter windows 32/64 am laufen und wollte mich gerade an die Komponente ranmachen. Die Hauptdatei von dcef3 - ceflib.pas - die ja alle Funktionen von cef enthält, ist standardmäßig schon out of the box zu 98 % Lazarus (Windows)-Kompatibel.

Also ich klinke mich gerne wieder aus oder unterstütze Dich wenn du Hilfe brauchst. :mrgreen: :mrgreen:

Du hast recht. Debuggen ist sehr schwierig.
Kann es sein, das bei Dir die TImer-Funktion für die Message-Loops noch nicht richtig arbeitet und deshalb die Events nicht ausgelöst werden?

Zur Delphi/Lazarus Kompatibilität: Ich bin der Meinung das Pascal jeden "Fan" braucht um zu überleben, egal ob er mit Delphi oder Lazarus arbeitet, möchte aber in diesem Thread keine Diskussion auslösen. Hier gehts um CEF.

Du hast übrigens natürlich auch mit der Größe der dlls recht. Aber dafür bekommt man auch einen kompletten Browser. (Mhh wie groß ist Chrome eigendlich wenn mann den installiert?)

Nochmal - Super arbeit :!: :!:
Es währe toll wenn Du schon ein Zeitfenster für ein Update im Visier hast.

Schöne Grüße

downloaditweb
Beiträge: 27
Registriert: Do 28. Jan 2010, 13:24
OS, Lazarus, FPC: openSuse Leap 42.3 (L 1.8 FPC 3.0.4)
CPU-Target: 64Bit

Re: Weiterentwicklung Chromium Browser Komponente

Beitrag von downloaditweb »

stacho hat geschrieben:Ich habe gerade mit ganz wenig Modifikationen das cefclient-Beispiel von dcef3 unter windows 32/64 am laufen und wollte mich gerade an die Komponente ranmachen. Die Hauptdatei von dcef3 - ceflib.pas - die ja alle Funktionen von cef enthält, ist standardmäßig schon out of the box zu 98 % Lazarus (Windows)-Kompatibel.

Für Windows sollte das recht einfach zu machen sein, WACEF z.B. hat auch ein passendes Lazarus-Package.

stacho hat geschrieben:Kann es sein, das bei Dir die TImer-Funktion für die Message-Loops noch nicht richtig arbeitet und deshalb die Events nicht ausgelöst werden?

Werd ich nochmal explizit schauen, bin mir aber relativ sicher, dass das korrekt funktioniert.

stacho hat geschrieben:Zur Delphi/Lazarus Kompatibilität: Ich bin der Meinung das Pascal jeden "Fan" braucht um zu überleben, egal ob er mit Delphi oder Lazarus arbeitet [...]

Stimme komplett zu. Aufgrund der "Vorgeschichte" (geplant als Linux exklusiver, privater "Versuch") von fpCEF und weil ich nur auf Linux programmiere (habe übrigens auch nie Delphi benutzt), kann ich Delphi-Kompatibilität praktisch nicht sicherstellen, versuche aber - wie gesagt - zumindest so nah wie möglich an dcef zu bleiben.

stacho hat geschrieben:Es wäre toll, wenn Du schon ein Zeitfenster für ein Update im Visier hast.

Mir hat bisher Ostern vorschwebt, hat leider nicht geklappt :(
Je nachdem, wie viel Zeit ich finde, sollte es eigentlich nicht mehr lange dauern...

stacho
Beiträge: 23
Registriert: Do 26. Nov 2009, 22:29

Re: Weiterentwicklung Chromium Browser Komponente

Beitrag von stacho »

Hallo downloaditweb,

da bin ich mal ein paar tage in Urlaub und schon hat sich was getan.
Schönen Dank für dein Update :!: :!: :!: Tolle Arbeit. Vor allem das DOM Beispiel. Daran hatte ich mir schon die Zähne ausgebissen. :oops:

Kleiner Wermutstropfen unter Windows.

Unter
    Win7 64
    Lazarus 1.2.0 r44303 FPC 2.6.2 i386-win32-win32/win64 -> win32 eingestellt
    cef_binary_3.1650.1562_windows32

wird bei Anwendung deiner Beispiele aus der IDE heraus der Debugger nicht beendet, wenn man die Anwendung beendet.

Weiterhin liefert das debug.log von cef folgendes:

Code: Alles auswählen

 
[0611/213844:ERROR:scoped_ole_initializer.cc(20)] Multiple OleInitialize() calls for thread 4656
[0611/213902:WARNING:http_stream_factory.cc(80)] Alternate-Protocol header has unrecognized protocol: quic
[0611/213902:WARNING:http_stream_factory.cc(80)] Alternate-Protocol header has unrecognized protocol: quic
[0611/213903:WARNING:http_stream_factory.cc(80)] Alternate-Protocol header has unrecognized protocol: quic
[0611/213903:WARNING:http_stream_factory.cc(80)] Alternate-Protocol header has unrecognized protocol: quic
[0611/213903:WARNING:http_stream_factory.cc(80)] Alternate-Protocol header has unrecognized protocol: quic
[0611/213903:WARNING:http_stream_factory.cc(80)] Alternate-Protocol header has unrecognized protocol: quic
[0611/213904:WARNING:http_stream_factory.cc(80)] Alternate-Protocol header has unrecognized protocol: quic
[0611/213904:WARNING:http_stream_factory.cc(80)] Alternate-Protocol header has unrecognized protocol: quic
[0611/213904:WARNING:http_stream_factory.cc(80)] Alternate-Protocol header has unrecognized protocol: quic
[0611/213904:WARNING:http_stream_factory.cc(80)] Alternate-Protocol header has unrecognized protocol: quic
[0611/213904:WARNING:http_stream_factory.cc(80)] Alternate-Protocol header has unrecognized protocol: quic
[0611/213905:WARNING:http_stream_factory.cc(80)] Alternate-Protocol header has unrecognized protocol: quic
[0611/213905:WARNING:http_stream_factory.cc(80)] Alternate-Protocol header has unrecognized protocol: quic
[0611/213906:WARNING:http_stream_factory.cc(80)] Alternate-Protocol header has unrecognized protocol: quic
 


Sagt dir das was?

Ansonsten Danke nochmal für die Arbeit :!: :!:

downloaditweb
Beiträge: 27
Registriert: Do 28. Jan 2010, 13:24
OS, Lazarus, FPC: openSuse Leap 42.3 (L 1.8 FPC 3.0.4)
CPU-Target: 64Bit

Re: Weiterentwicklung Chromium Browser Komponente

Beitrag von downloaditweb »

stacho hat geschrieben:Sagt dir das was?

Leider nein, das einzige was ich sicher weiß ist, dass diese (Fehler-)Meldung nicht Windows-spezifisch ist.

Was den Debugger betrifft, kann ich wenig sagen.
Wenn ich mich richtig erinnere (ich debugge nur im Notfall, siehe oben) hat sich das unter Linux schon richtig geschlossen. Allerdings war das nicht aus Lazarus heraus, sondern Konsole + gdb.
Gilt das grundsätzlich oder nur für die beigefügten Beispiele? Funktioniert es ohne Debugger richtig?

Ansonsten vllcht. mal die jeweils anderen .dlls versuchen (Debug <-> Release). Ich habe nämlich festgestellt, dass die sich teilweise ziemlich unterschiedlich verhalten (können), zeitweise ging z.B. (unter Linux) auch nur die Release-Library.

stacho
Beiträge: 23
Registriert: Do 26. Nov 2009, 22:29

Re: Weiterentwicklung Chromium Browser Komponente

Beitrag von stacho »

Danke für die schnelle Antwort.

Bingo :D Release verwenden, nicht Debug. :!: :!:

Bei Verwendung der Debug-Dlls passiert folgendes:

Ich habe gerade festgestellt, dass bei direktem Start der exe, z.b. dom.exe ohne ide, diese dann zweimal als Prozess im Task-Manager auftaucht.
Das gleiche passiert wenn ich eine neue Anwendung baue mit der Chromium-Komponente drauf.
Wenn ich dann das Fenster schließe, bleibt ein Prozess offen.

Im Release wird übrigens witzigerweise auch in eine Debug.log gelogt.

Danke nochmal :D

downloaditweb
Beiträge: 27
Registriert: Do 28. Jan 2010, 13:24
OS, Lazarus, FPC: openSuse Leap 42.3 (L 1.8 FPC 3.0.4)
CPU-Target: 64Bit

Re: Weiterentwicklung Chromium Browser Komponente

Beitrag von downloaditweb »

stacho hat geschrieben:Ich habe gerade festgestellt, dass bei direktem Start der exe, z.b. dom.exe ohne ide, diese dann zweimal als Prozess im Task-Manager auftaucht.
Das gleiche passiert wenn ich eine neue Anwendung baue mit der Chromium-Komponente drauf.

Das mit den zwei/mehreren Prozessen ist normal, das ist typisch Chrome/ium, die Alternative ist halt ein Subprocess statt einer zweiten Instanz des Hauptprogramms.
Deshalb ist ja der Zugriff auf das DOM so kompliziert, da Daten im Hauptprozess sind, das DOM aber in einem der/dem Render-Prozess(e).

stacho hat geschrieben:Wenn ich dann das Fenster schließe, bleibt ein Prozess offen.

Stimmt, jetzt fällts mir auch wieder ein, hatte das schon wieder verdrängt :mrgreen:

stacho hat geschrieben:Im Release wird übrigens witzigerweise auch in eine Debug.log geloggt.

Allerdings gibt es im Fall eines Backtraces nur unaufgelöste Symbole / Adressen.

stacho
Beiträge: 23
Registriert: Do 26. Nov 2009, 22:29

Re: Weiterentwicklung Chromium Browser Komponente

Beitrag von stacho »

Hallo downloaditweb

ich habe mal weiter mit deiner Chromium-Komponente gespielt und versuche gerade die Javascript Bindings wie auf den Seiten von cef beschrieben zu testen.

Variablen von Lazarus-Programm an das Window-Objekt zu übergeben damit JS sie verwenden kann, funktioniert. :D :D

Was ich leider nicht ans laufen bekomme, ist das Einbinden von Extensions. :( :(

Dazu wird eine Extension in der OnWebKitInitialized Prozedur mit CefRegisterExtension in einem TCustomRenderProcessHandler registriert.

Wenn ich nun eine neue Seite lade wird OnWebKitInitialized ausgelöst. Aber Bei Aufruf der Funktion CefRegisterExtension gibt es die Fehlermeldung: External exception 80000003

Mit dcef in Delphi funktioniert das. Ich kann aber keine Unterschiede im Code erkennen, außer dass in Delphi die RegisterExtension-Funktion bei CPU64 mit stcall aufgerufen wird. Daran liegt es aber nicht.

Hast due eine Idee?

Hier mal der Code
1x Chromium-Komponente und 1 Edit , 3x Button auf einem Panel:

Kommt noch


Ich habe auch mal neuere DLLs getestet - gleiches Ergebnis.
DebugLog der Dlls gibts folgendes aus:
[0626/160224:FATAL:content_main_runner.cc(739)] Check failed: InitializeSandbox(sandbox_info).


Ich konnte in Google keine Lösung finden. :x

Antworten