Webkit-gtk will be updated to latest upstream; midori browser to be replaced with Epiphany
Hello everyone,
I've been looking into updating oe-core's aging web engine/browser combo, and want to give you a heads up about what's going to happen:
1) webkit-gtk engine will be updated to latest stable upstream release (2.8.3 which is providing Webkit2 API and is a Gtk3 port)
2) midori browser will be replaced with Epiphany browser from the Gnome project. The reason is that the latest release of midori still defaults to Webkit1 and gtk2, a new version of midori is in development, but is a major rewrite with no target release date and is far from ready at the moment (from looking at the list of open issues).
The downside to this is extra bloat and dependencies, but I can't see any other way we can provide a modern client stack for the web. Having a browser is important nowadays for any kiosk-type device with a touchscreen, because that's how UIs are written.
Regards,
Alex
Quoted 14 lines · Alexander Kanavin
Hello everyone,
I've been looking into updating oe-core's aging web engine/browser combo, and want to give you a heads up about what's going to happen:
1) webkit-gtk engine will be updated to latest stable upstream release (2.8.3 which is providing Webkit2 API and is a Gtk3 port)
2) midori browser will be replaced with Epiphany browser from the Gnome project. The reason is that the latest release of midori still defaults to Webkit1 and gtk2, a new version of midori is in development, but is a major rewrite with no target release date and is far from ready at the moment (from looking at the list of open issues).
Quoted 5 lines
The downside to this is extra bloat and dependencies, but I can't see any other way we can provide a modern client stack for the web. Having a browser is important nowadays for any kiosk-type device with a touchscreen, because that's how UIs are written.
So we are loosing last working browser around - what get's better except later is greater?
Andreas
Quoted 3 lines · Andreas Müller
So we are loosing last working browser around - what get's better except later is greater?
If you actually compare the build dependencies, you'll see that Midori and Epiphany are actually almost identical.
We need to upgrade WebKit as the release we're shipping has known security flaws and is very old - and the community is rightly moaning about that. However Midori doesn't build with a recent WebKit... if you have an alternative solution then your thoughts are welcome.
Ross
Quoted 7 lines · Ross
If you actually compare the build dependencies, you'll see that Midori and Epiphany are actually almost identical.
We need to upgrade WebKit as the release we're shipping has known security flaws and is very old - and the community is rightly moaning about that. However Midori doesn't build with a recent WebKit... if you have an alternative solution then your thoughts are welcome.
Also, Webkit2 itself ships with a tiny browser wrapper called MiniBrowser:
http://blogs.igalia.com/carlosgc/2011/11/04/webkit2-gtk-minibrowser-ported-to-gtk-api/
That may be enough for many people's needs, and they can simply not include Epiphany into their images if it's too big and bloated or whatever.
Alex
Quoted 11 lines · Alexander Kanavin
Quoted 7 lines · Ross
If you actually compare the build dependencies, you'll see that Midori and Epiphany are actually almost identical.
We need to upgrade WebKit as the release we're shipping has known security flaws and is very old - and the community is rightly moaning about that. However Midori doesn't build with a recent WebKit... if you have an alternative solution then your thoughts are welcome.
Quoted 8 lines
Also, Webkit2 itself ships with a tiny browser wrapper called MiniBrowser:
http://blogs.igalia.com/carlosgc/2011/11/04/webkit2-gtk-minibrowser-ported-to-gtk-api/
That may be enough for many people's needs, and they can simply not include Epiphany into their images if it's too big and bloated or whatever.
How about doing same as others do e.g fedora [1-2]: Keep two version of webkit-gtk based on same recent code:
* gtk2/webkit1
* gtk3/webkit2
Andreas
[1] http://pkgs.fedoraproject.org/cgit/webkitgtk.git/tree/webkitgtk.spec
[2] http://pkgs.fedoraproject.org/cgit/webkitgtk3.git/tree/webkitgtk3.spec
Quoted 5 lines · Andreas Müller
How about doing same as others do e.g fedora [1-2]: Keep two version of webkit-gtk based on same recent code:
* gtk2/webkit1
* gtk3/webkit2
Before showing how, you need to explain why. Fedora has to package webkit1 because they have a lot of apps in the Gnome stack that still haven't been ported to webkit2. Oe-core on the other hand has only one such app: midori.
Also, webkit1 has been deprecated for years, and there is no commitment from upstream to maintain the 2.4.x series which is the last that still has it in the source tree; they may cease to do it at any moment. So once again, why keep it in oe-core?
Regards,
Alex
Quoted 5 lines · Alexander Kanavin
Quoted 3 lines · Andreas Müller
How about doing same as others do e.g fedora [1-2]: Keep two version of webkit-gtk based on same recent code:
Quoted 7 lines
Quoted 2 lines
* gtk2/webkit1
* gtk3/webkit2Before showing how, you need to explain why. Fedora has to package webkit1 because they have a lot of apps in the Gnome stack that still haven't been ported to webkit2. Oe-core on the other hand has only one such app: midori.
Yes and midori is the only working browser in Yocto (I know): firefox crashes since very long time for illegal ARM instruction and chromium does not start at all.
I suggest we stop discussing my comment: You continue updating webkitgtk and I'll try to get a working browser.
Andreas
Quoted 11 lines · Andreas Müller
Quoted 9 lines · Alexander Kanavin
Quoted 5 lines · Andreas Müller
How about doing same as others do e.g fedora [1-2]: Keep two version of webkit-gtk based on same recent code:
* gtk2/webkit1
* gtk3/webkit2
Quoted 6 lines
Quoted 3 lines
Before showing how, you need to explain why. Fedora has to package webkit1 because they have a lot of apps in the Gnome stack that still haven't been ported to webkit2. Oe-core on the other hand has only one such app: midori.
Yes and midori is the only working browser in Yocto (I know): firefox crashes since very long time for illegal ARM instruction and chromium does not start at all.
What platform are you using? Are you building these from meta-browser?
I routinely use both firefox and chromium on ARM (i.MX6) with no problems.
Quoted 6 lines
I suggest we stop discussing my comment: You continue updating webkitgtk and I'll try to get a working browser.
Andreas
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------
Quoted 22 lines · Gary Thomas
Quoted 21 lines · Andreas Müller
Quoted 17 lines · Alexander Kanavin
Quoted 5 lines · Andreas Müller
How about doing same as others do e.g fedora [1-2]: Keep two version of webkit-gtk based on same recent code:
* gtk2/webkit1
* gtk3/webkit2Before showing how, you need to explain why. Fedora has to package webkit1
because they have a lot of apps in the Gnome stack that still haven't been
ported to webkit2. Oe-core on the other hand has only one such app:
midori.
Quoted 8 lines
Quoted 3 lines
Yes and midori is the only working browser in Yocto (I know): firefox crashes since very long time for illegal ARM instruction and chromium does not start at all.
What platform are you using? Are you building these from meta-browser?
I routinely use both firefox and chromium on ARM (i.MX6) with no problems.
Hmm - I was wondering why nobody took care.
All my plattforms fail:
* i.MX6 base
* gumstix
* raspberry Pi2
I'll put this browser issue on my TODO currently I have no further time to take care.
Andreas
Quoted 3 lines · Andreas Müller
Yes and midori is the only working browser in Yocto (I know): firefox crashes since very long time for illegal ARM instruction and chromium does not start at all.
Latest epiphany will be provided as a replacement for midori. It works fine here in the core-image-sato under qemu. I can't promise it will work on ARM, but any ARM-specific issues are almost certainly in webkit's (or other web engine's) javascript JIT code and have nothing to do with the browser.
Alex
Quoted 5 lines · Alexander Kanavin
Latest epiphany will be provided as a replacement for midori. It works fine here in the core-image-sato under qemu. I can't promise it will work on ARM, but any ARM-specific issues are almost certainly in webkit's (or other web engine's) javascript JIT code and have nothing to do with the browser.
Oh, and with webkit it's trivial to disable JIT at compile time; in fact I have to do it for ARMv5 and ARMv6 because it has bitrotten for those architectures due to lack of upstream testing.
Alex
Quoted 33 lines · Andreas Müller
Quoted 22 lines · Gary Thomas
Quoted 21 lines · Andreas Müller
Quoted 17 lines · Alexander Kanavin
Quoted 5 lines · Andreas Müller
How about doing same as others do e.g fedora [1-2]: Keep two version of webkit-gtk based on same recent code:
* gtk2/webkit1
* gtk3/webkit2Before showing how, you need to explain why. Fedora has to package webkit1
because they have a lot of apps in the Gnome stack that still haven't been
ported to webkit2. Oe-core on the other hand has only one such app:
midori.Quoted 8 lines
Quoted 3 lines
Yes and midori is the only working browser in Yocto (I know): firefox crashes since very long time for illegal ARM instruction and chromium does not start at all.
What platform are you using? Are you building these from meta-browser?
I routinely use both firefox and chromium on ARM (i.MX6) with no problems.
Hmm - I was wondering why nobody took care.
Quoted 7 lines
All my plattforms fail:
* i.MX6 base
* gumstix
* raspberry Pi2I'll put this browser issue on my TODO currently I have no further time to take care.
BTW, I just tested both chromium and firefox on the i.MX6Q and RPi2 and they worked just fine. Built from meta-browser:0cc0419a
Signature · 4 lines
------------------------------------------------------------ Gary Thomas | Consulting for the MLB Associates | Embedded world ------------------------------------------------------------