[Lazarus] Chromium embedded on freebsd or firefox embedded

[Lars via Lazarus]

What is the actual status of chromium embedded and firefox embedded on
bsd? Does it only work on Windows and Linux?

Seems there is not so much info about CEF in general on freebsd other than
this info:
https://lists.freebsd.org/pipermail/freebsd-chromium/2014-January/001113.html

I so much love the bsd license and want to move my desktop and some of my
development over to BSD, but it just seems like bsd is constantly playing
catch up to what linux and windows already had years ago. That's my
biggest fear about all bsd's.

Since I will be doing work with chromium embedded on multiple projects it
will be interesting to know what the status of it is on bsd for lazarus?
--

[Graeme Geldenhuys via Lazarus]

Post by Lars via Lazarus
I so much love the bsd license and want to move my desktop and some of my
development over to BSD, but it just seems like bsd is constantly playing
catch up to what linux and windows already had years ago.

I agree with the first part and disagree with the second part. :) I've
switched to FreeBSD some 4 years ago, as my only desktop system for work
and play. I've never been happier. My system runs for months on end
without a reboot, I watch movies, browse the net, host multiple
development VM's, run two 24/7 server VM's, and do all my daily
development work on it. Upgrading is dead simple, and the ports system
rocks! And the best part is ZFS - I'll never trust my data on anything
else ever again. I also run a nVIDIA graphics card that drives 3
monitors. I've never been happier with my computer setup.

I don't know about Chromium Embedded, but I did dab with Firefox
Embedded 4 years ago, and from what I remember it was working fine. I
never used in in a large-scale application though. I didn't like the
large dependency I had to include with every application.

Regards,
Graeme

[Lars via Lazarus]

Post by Graeme Geldenhuys via Lazarus
I don't know about Chromium Embedded, but I did dab with Firefox
Embedded 4 years ago, and from what I remember it was working fine. I
never used in in a large-scale application though. I didn't like the large
dependency I had to include with every application.

Ahh, the dependency issue is definitely an issue since the dll's and files
included are massive. Okay for large apps, but for small apps it increases
the download size significantly.

When you dabbed with firefox embedded, was it a lazarus component? Or did
you make calls directly to an API without using a component?

Appreciate Michael V. C.'s article on the topic, in a PDF. Some of the old
links are dead though, referencing the newbielabs website.

--

[Graeme Geldenhuys via Lazarus]

Post by Lars via Lazarus
but for small apps it increases
the download size significantly.

Exactly.

Post by Lars via Lazarus
When you dabbed with firefox embedded, was it a lazarus component?

It's been a while, but I believe it was a Lazarus component.


Regards,
Graeme

[José Mejuto via Lazarus]

Post by Lars via Lazarus
When you dabbed with firefox embedded, was it a lazarus component? Or did
you make calls directly to an API without using a component?

Hello,

Embeded Firefox is not possible anymore via XulRunner as embedded
support has been dropped by Mozilla.

The only way is to get Firefox sources and maintain something that can
be embedded, but since since Firefox 40 +/- internat API is not frozen
anymore, also projects like Thunderbird have troubles now to follow API
changes.

Firefox embedded does not work properly in Lazarus since Firefox 9 +/-
and it is not possible to make it work unless forking Firefox xulrunner.

[Lars via Lazarus]

Post by José Mejuto via Lazarus
Embeded Firefox is not possible anymore via XulRunner as embedded
support has been dropped by Mozilla.

Really? I heard about them changing the architecture to a new embedded
architecture and no longer supporting an old architecture in the new code
base, but not dropping support entirely for the entire embedded system?

Or lazarus is simply not yet supporting the new architecture they came up
with?

Post by José Mejuto via Lazarus
Firefox embedded does not work properly in Lazarus since Firefox 9 +/-
and it is not possible to make it work unless forking Firefox xulrunner.

Isn't there a new xulrunner architecutre they created to replace it..
that's what I remember reading. I will find a link to the page and report
back here soon if I find it.
--

[Lars via Lazarus]

Post by Lars via Lazarus

Post by José Mejuto via Lazarus
Firefox embedded does not work properly in Lazarus since Firefox 9 +/-
and it is not possible to make it work unless forking Firefox xulrunner.

Isn't there a new xulrunner architecutre they created to replace it..
that's what I remember reading. I will find a link to the page and report
back here soon if I find it.

As promised, links:

https://github.com/zotero/translation-server/issues/24

Someone says that there is now something called a Firefox SDK or Gecko SDK
instead of xulrunner...

I wonder if it replaces it or is more complicated/difficult to use and not
intended so much for embedding?
--

[José Mejuto via Lazarus]

Post by Lars via Lazarus
https://github.com/zotero/translation-server/issues/24
Someone says that there is now something called a Firefox SDK or Gecko SDK
instead of xulrunner...
I wonder if it replaces it or is more complicated/difficult to use and not
intended so much for embedding?

Hello,

Yes XulRunner is being replaced by GeckoSDK, but the main difference is
that XulRunner had an stable API (frozen) and some semi-stable APIs, so
most base functions for embed are stable. This is now longer available
in GeckoSDK where nothing is frozen, API can change from release to
release and the only way to embed it is writing a C code that generates
a plain C interface that must link against a moving target.

It is expected that somebody write such library in a near future but
each library will match an specific Gecko engine, not as in XulRunner
where old code should work with modern Gecko.

The decision was taken around Firefox 40 because the browser needs a
major rewrite to handle things like multiprocess rendering which are
(from developers point of view) impossible to keep running with current
XulRunner architecture, so instead XulRunner n.0 they simply drop
XulRunner and all the satellite projects around Firefox.

I'll try later to find the relevant links I had found in the past about
this topic, found after spending a lot of hours trying to make morend
XulRunners work embedded in Lazarus.

[Lars via Lazarus]

Post by José Mejuto via Lazarus
Hello,
Yes XulRunner is being replaced by GeckoSDK, but the main difference is
that XulRunner had an stable API (frozen) and some semi-stable APIs, so
most base functions for embed are stable. This is now longer available in
GeckoSDK where nothing is frozen, API can change from release to
release and the only way to embed it is writing a C code that generates a
plain C interface that must link against a moving target.

I see! You certainly are very knowledgeable about the subject and have
done a lot of research on it. Now it makes sense to me more.

This api that continually changes, reminds me of MySQL. I wrote web
programs only to find out they broke, when mysql changed their API, and
then freepascal had to release a newer file that linked to the DLL. It's a
nightmare when api continually changes.

I can see them (firefox) changing the architecture to support multiprocess
though.

....

Post by José Mejuto via Lazarus
I'll try later to find the relevant links I had found in the past about
this topic, found after spending a lot of hours trying to make morend
XulRunners work embedded in Lazarus.

Your knowledge on the subject is significant! Thanks.
--

[José Mejuto via Lazarus]

Post by Lars via Lazarus

Post by Lars via Lazarus
Isn't there a new xulrunner architecutre they created to replace it..
that's what I remember reading. I will find a link to the page and report
back here soon if I find it.

https://github.com/zotero/translation-server/issues/24
Someone says that there is now something called a Firefox SDK or Gecko SDK
instead of xulrunner...
I wonder if it replaces it or is more complicated/difficult to use and not
intended so much for embedding?

Hello,

The link that explains almost anything:

https://dutherenverseauborddelatable.wordpress.com/2016/03/07/the-gecko-monoculture/

And the link that shows the embedding problem:

http://chrislord.net/index.php/2016/03/08/state-of-embedding-in-gecko/

[Lars via Lazarus]

Post by José Mejuto via Lazarus
https://dutherenverseauborddelatable.wordpress.com/2016/03/07/the-gecko-m
onoculture/
http://chrislord.net/index.php/2016/03/08/state-of-embedding-in-gecko/

Those are some interesting reads. It confirms my gut instinct to choose
chromium embedded (CEF) for development, instead of mozilla embedded, as
chromium embedded seems more designed for embedding at this stage than the
more immature firefox code.

I wonder how often chromium embedded breaks their api, or changes the V8
engine so that old stuff no longer works.

One thing I'd really like is a single DLL to ship with an application
instead of mounds and mounds of files that these embedded solutions
require. However I guess that's not going to happen.
--

[José Mejuto via Lazarus]

Post by Lars via Lazarus
Those are some interesting reads. It confirms my gut instinct to choose
chromium embedded (CEF) for development, instead of mozilla embedded, as
chromium embedded seems more designed for embedding at this stage than the
more immature firefox code.

Hello,

Yes, currently Chromium seems to be better, but anyway it will need a
lot of work starting from the CEF as if my brain serves me CEF API is
C++ so you will find the same problem as Qt interface, a very big DLL/so
to convert C++ to plain C functions that will need a quite good maintain.

Post by Lars via Lazarus
I wonder how often chromium embedded breaks their api, or changes the V8
engine so that old stuff no longer works.

As far as I know it is quite stable now.

Post by Lars via Lazarus
One thing I'd really like is a single DLL to ship with an application
instead of mounds and mounds of files that these embedded solutions
require. However I guess that's not going to happen.

No for sure, that will not happen :) unless you use some dirty tricks.
In the past I was able to "inject" 3 or 4 DLLs in my EXE and use them,
but only in 32 bits Windows and I was unable to port the code to the 64
bits windows loader (it basically performs the same actions Windows do
when load a DLL from disk, but the function loads it from a resource and
adjust the call pointers and other things as Windows will do it).

Of course that method will not with all DLLs.

[Lars via Lazarus]

Post by José Mejuto via Lazarus
Hello,
Yes, currently Chromium seems to be better, but anyway it will need a
lot of work starting from the CEF as if my brain serves me CEF API is C++
so you will find the same problem as Qt interface, a very big DLL/so to
convert C++ to plain C functions that will need a quite good maintain.

http://wiki.freepascal.org/fpCEF3

I was under the impression someone had already done a lot of the work
already porting all the C++ code...

Just wondered if it was usable on BD or mostly focused on Windows and
linux... also macosx interests me.

Post by José Mejuto via Lazarus

Post by Lars via Lazarus
I wonder how often chromium embedded breaks their api, or changes the V8
engine so that old stuff no longer works.

As far as I know it is quite stable now.

Just found out that some things in CEF1 are no longer working in CEF3:
example: they removed the Listener functions which were really useful, now
you have to use javascript listener code instead. So they have broken some
stuff from CEF1 to CEF3 but probably not nearly as broken as firefox
embedded! This is because firefox never started out as a multi process
browser, whereas chromium had a head start on multi process.

Post by José Mejuto via Lazarus

Post by Lars via Lazarus
One thing I'd really like is a single DLL to ship with an application
instead of mounds and mounds of files that these embedded solutions
require. However I guess that's not going to happen.

No for sure, that will not happen :) unless you use some dirty tricks.
In the past I was able to "inject" 3 or 4 DLLs in my EXE and use them,
but only in 32 bits Windows and I was unable to port the code to the 64
bits windows loader (it basically performs the same actions Windows do
when load a DLL from disk, but the function loads it from a resource and
adjust the call pointers and other things as Windows will do it).
Of course that method will not with all DLLs.

Interesting, I've heard of similar delphi tricks before of embedding exe's
or dll's inside exe's in order to ship a single binary .. In fact this
brings back nostalgia of reading about it 10-14 years ago.
--