Support Ubuntu Touch

[zubozrout]

Hello, I know that at one point there was a preview release of Liri web browser for Ubuntu Touch and I wonder how hard would it be to support it again?

It seems that based on some internal UBports discussions the current system web browser wont receive much updates since Oxide is no longer developed and is missing maintainers. The talks are to utilize some other web browser amongst them Liri is one of the few feasible candidates.

So I guess my question is what would be necessary to change in Liri to run on Ubuntu Touch again?

Thank you very much for you answers :).

[timsueberkrueb]

Hey @zubozrout! Unfortunately there are some road blockers. The first problem is that Ubuntu Touch right now uses Qt 5.4. The most current planning status that I know of is that they plan to work towards upgrading to Qt 5.7 at some point at the future. Unfortunately, Fluid already requires Qt >= 5.8 right now. The second problem is that nobody seems to have yet succeeded building QtWebEngine for arm (for Ubuntu phone). Liri Browser used to be compatible with Oxide, but since Oxide is dead now, there's really no point anymore to support it. Snap/Flatpak support would probably at least solve problem 1. That being said, if those problems would be solved, I'd be very happy working towards getting Liri Browser working on Ubuntu Touch again :) EDIT: According to @plfiorini QtWebEngine does compile for arm, I guess it's probably not easy though.

[ShalokShalom]

How much support is there for Ubuntu touch?

[Flohack74]

Indeed we are aiming for Qt 5.7, but its way too early to say when this will land. Snaps are also a problem since they are missing basic access to Contenthub and other stuff we need for proper interaction. So unless we can bundle all things in a (huuuuge) click package it can only be put on hold. this will be true for other browser alternatives as well.

[timsueberkrueb]

Indeed we are aiming for Qt 5.7, but its way too early to say when this will land. Snaps are also a problem since they are missing basic access to Contenthub and other stuff we need for proper interaction.

@Flohack74 yeah, I definitely see that. However, if anyone succeeds building Qt >= 5.8 and QtWebEngine for arm and it runs on Ubuntu touch, we could indeed have some sort of fat click package. That would suck of course but still would be better than nothing, right? :) So, if anyone manages that, please report it here!

[timsueberkrueb]

@ShalokShalom can you explain what you mean, exactly?

[ShalokShalom]

Hnn, Canonical dropped the support for Ubuntu touch, yes? I think an own, independent group care for them now.

[Flohack74]

Yes thats us @ShalokShalom :) http://www.ubports.com

[timsueberkrueb]

@Flohack74 As it is right now, I think you're probably better off with Sailfish OS' default browser which doesn't require the latest Qt version and uses some sort of Gecko backend afaik if you're looking for a browser to use as default on Ubuntu Phone and you don't want to create your own/switch the Oxide engine in Canonical's browser for something else and maintain that.

[timsueberkrueb]

Looks like Qt 5.9 and Xenial on Ubuntu touch are slowly going to become a reality, maybe this can too :heart_eyes:

[Flohack74]

Yeah we are aiming now for Qt 5.9 and 16.04 to be usable, and there are first test builds. So anyone who wants to jump onboard this is pretty much welcomed...

[JLIT0]

Similarly to this, it would be amazing if Liri Browser could be packaged for postmarketOS.

The pmOS project already has QtWebEngine packed in its' repository so that won't be an issue.

[ShalokShalom]

Thanks a lot for sharing.

[timsueberkrueb]

I've got Fluid demo installed and running on Ubuntu Touch (xenial, Qt 5.9) :confetti_ball: :

I was also trying to get Liri Browser running with XMir, with no success yet though:

Fatal server error:
(EE) Failed to connect to Mir: Failed to connect: not accepted by server

Desktop file:

X-Ubuntu-XMir-Enable=true
Type=Application
X-Ubuntu-Touch=true

Launcher script:

export QT_QPA_PLATFORM=xcb
export DISPLAY=:0
liri-browser

I experience the same issue when trying to run a minimal QtWebEngine example using XMir. Actually, even when trying to run Fluid Demo (which doesn't use QtWebEngine) with X-Ubuntu-XMir-Enable=true, it crashes with the error messages above (!).

Running QtWebEngine without XMir:

Loading module: 'libubuntu_application_api_touch_mirclient.so.3.0.0'
WebEngine compiled with X11 support, however qpa backend is not xcb. This may fail.
[19493:19493:0127/183925.179355:ERROR:browser_main_loop.cc(494)] Failed to put Xlib into threaded mode.
[19493:19493:0127/183925.179787:ERROR:browser_main_loop.cc(1471)] Unable to open X display.

I can get Chromium and other X11 apps running just fine using XMir.

Am I missing something? Has anyone got QtWebEngine running on Ubuntu Touch yet? I'd highly appreciate any help/hints on this topic!

[timsueberkrueb]

I learned that I should not export DISPLAY=:0 in my launcher. Now I get a different issue:

[26228:26262:0127/200511.152330:ERROR:gl_context_egl.cc(117)] eglCreateContext failed with error EGL_BAD_CONTEXT
[26228:26262:0127/200511.155010:ERROR:gl_context_egl.cc(117)] eglCreateContext failed with error EGL_BAD_CONTEXT
[26228:26262:0127/200511.157703:ERROR:gl_context_egl.cc(117)] eglCreateContext failed with error EGL_BAD_CONTEXT
[26228:26262:0127/200511.160176:ERROR:gl_context_egl.cc(117)] eglCreateContext failed with error EGL_BAD_CONTEXT
[26228:26248:0127/200511.317979:ERROR:cert_verify_proc_nss.cc(918)] CERT_PKIXVerifyCert for duckduckgo.com failed err=-8181
Received signal 8 <unknown> 00000000669a
#0 0x0000b47d578a <unknown>
#1 0x0000b47d5a50 <unknown>
#2 0x0000b3c08270 <unknown>
#3 0x0000b3bf9af6 <unknown>
#4 0x0000b3c07648 gsignal
[end of stack trace]

Running a minimal QtWebEngine example.

[ShalokShalom]

This might help: https://forums.ubports.com/

Happy Grav-Mass ^^

[JLIT0]

If you're unable to make any progress with XMir, maybe you could try running Liri Browser with XWayland on the Plasma Mobile images or postmarketOS?

AFAIK, UBports is planning on switching to Wayland in the near future so this could be a solution to the issue.

[timsueberkrueb]

@ShalokShalom thanks for the pointer, I asked for help in their telegram group :) No progress/new information yet, though. @JLIT0 yeah, I'm definitely interested to try those out (if I can get them running on my Nexus 5) :)

[ShalokShalom]

Oh yeah, postmarketOS is awesome ^-^

[ShalokShalom]

Your phone is supported: https://wiki.postmarketos.org/wiki/Google_Nexus_5_(lg-hammerhead)

[zubozrout]

Hello @timsueberkrueb, it seems as Xenial is getting closer to the final OTA release. And I wonder, what are the current blockers for Liri Browser to run on Ubuntu Touch?

[timsueberkrueb]

Hey @zubozrout, I think @mariogrip made QtWebEngine work, so I will try that out :)

The problem with porting the browser is that we're already requiring Qt >= 5.10 for Liri Browser while Ubuntu touch is likely going to stay on the Qt 5.9 LTS release (afaik).

[Flohack74]

Yes, Qt 5.9 will be the one for xenial. Due to so many changes also for App compatibility we do not want to make it more unstable at the moment. That said, we might consider an upgrade to 5.10 later, since its not a required part of Ubuntu 16.04 per se, and could be upgraded any time.

[timsueberkrueb]

While security fixes for Chromium are ported to QtWebEngine for the LTS release 5.9, the Chromium version (56) is not updated. New Qt releases usually come with an updated Chromium version as well so it is in general probably desirable to use the latest Qt version for QtWebEngine applications (like Liri Browser).

[mariogrip]

We will use updated QtWebEngine, since that does not need to match the others for that reason. Right now we use 5.10 with backports from 5.11beta and we will update up 5.11 once its in Debian. The reason for this is we need egl support without x11 and this was a problem in 5.9 and also in 5.10 (reason for backport) we will try to use the latest QtWebEngine when we can

May 24, 2018 12:51 PM, "Tim Süberkrüb" notifications@github.com wrote:

While security fixes for Chromium are ported to QtWebEngine for the LTS release 5.9, the Chromium version (56) is not updated. New Qt releases usually come with an updated Chromium version as well so it is in general probably desirable to use the latest Qt version for QtWebEngine applications (like Liri Browser).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[timsueberkrueb]

Hey @mariogrip, I created a demo QtWebEngine app and installed the new QtWebEngine package on my device. I made sure to export the environment variables as you described:

qputenv("QTWEBENGINE_DISABLE_SANDBOX", QByteArray("1"));
qputenv("QT_WEBENGINE_DISABLE_GPU", QByteArray("1"));

There still seems to be at least an issue with the resources:

Loading module: 'libubuntu_application_api_touch_mirclient.so.3.0.0'
WebEngine compiled with X11 support, however qpa backend is not xcb. This may fail.
Sandboxing disabled by user.
[0526/141137.529308:ERROR:icu_util.cc(179)] Invalid file descriptor to ICU data received.
[0526/141137.529513:FATAL:content_main_runner.cc(611)] Check failed: base::i18n::InitializeICU(). 
#0 0x0000b380501e <unknown>
#1 0x0000b3804e9a <unknown>
#2 0x0000b38135ba <unknown>
#3 0x0000b37e4046 <unknown>
#4 0x0000b2c297d0 <unknown>
#5 0x0000b2c2a738 <unknown>
#6 0x0000b2bddbbc QtWebEngineCore::BrowserContextAdapter::defaultContext()

Do you have an idea what I'm missing? Thanks a lot :)

[mariogrip]

@timsueberkrueb I wonder, did you install the qtwebengine-data package? since it seems to not find ICU date

[timsueberkrueb]

Yep, it's installed:

libqt5webengine-data/xenial,now 5.10.1+dfsg-4ubports1 all [installed,automatic]
libqt5webengine5/xenial,now 5.10.1+dfsg-4ubports1 armhf [installed]
libqt5webenginecore5/xenial,now 5.10.1+dfsg-4ubports1 armhf [installed,automatic]
qml-module-qtwebengine/xenial,now 5.10.1+dfsg-4ubports1 armhf [installed]

I tried to adapt the Data path property in a qt.conf to point it to the right location but it seemed like it was already using the correct path to look for the resources.

EDIT: Here is the click package I tried this with.