Can OTA-15 be the final release including Oxide?

[UniSuperBox]

Hi everyone,

It's been about two years since we added QtWebEngine to Ubuntu Touch, beginning the arduous process of replacing Canonical's Oxide rendering engine.

At the time, all of the webapps and HTML5 apps on the store relied on Oxide's unique quirks. Some expected the behavior from Ubuntu.Web, others explicitly imported Oxide libraries.

Since then, things have changed. We've become increasingly present on 64-bit ARM devices where Oxide simply isn't available. Many of our users coming to the platform now can't take advantage of these apps.

Many app developers have released their apps to take advantage of Morph.Web or direct QtWebEngine imports. However, I believe there are still some holdouts on the store... Either by lack of maintainership or by choice. The Ogra webapp container in particular only uses the Oxide rendering engine. Any apps made with it simply don't work on the PinePhone, Volla Phone, Xperia X, Nexus 6P, or many other new ports...

With this in mind, I propose that we make OTA-15 of Ubuntu Touch the final release which includes the Oxide rendering engine. In other words, OTA-16 should not include Oxide. That gives a roughly three-month period to transition any remaining apps to the new rendering engine (on top of the two years already provided).

Removing the Oxide rendering engine takes a pretty large, not-updated piece of code out of the image. That means smaller updates for everyone, more space in the rootfs to provide newer features, and a more secure device overall.

Is this timeline with OTA-16 the first non-Oxide update feasible? What else do we need to consider before its removal that we can prioritize for OTA-14 and OTA-15?

[Fla]

Go for it! Less code to maintain is always a good thing.

[TotalSonic]

Going to un-publish the two Ogra based webapps I have in the Open Store right now, as a tiny part in furthering this effort, which makes total sense to me.

Edit: One thing I've noticed - it seems that the "Delete" button does not always appear on the page for an unpublished app, so that it is not always possible to completely delete an app off of the Open Store.

Best regards,
Steve Berson

[TotalSonic]

Seems any Ogra based webapp in the Open Store is marked as "Web App+" - think it would make sense to have a notice made that all of these apps marked as such will be unpublished automatically in a month or two, and then only allowed to re-publish if they are updated to QTwebengine.

Best regards,
Steve Berson

[lduboeuf]

@UniSuperBox
api documentation should be updated with Morph.Web https://api-docs.ubports.com/sdk/apps/qml/index.html

[CiberSheep]

I think it has been enough time to move to Morph... Thanks Oxide for all the good features, bye now

[dobey]

@UniSuperBox said in Can OTA-15 be the final release including Oxide?:

Is this timeline with OTA-16 the first non-Oxide update feasible? What else do we need to consider before its removal that we can prioritize for OTA-14 and OTA-15?

Given the release schedule we're trying to keep for stable releases, I'd even say we should remove it from OTA-15 and OTA-14 could be the last one with it. It has been widely understood for a long time that oxide is deprecated and we would be removing it. If we make appropriate announcement today that it will no longer be included as of the OTA-15 release, that should be ~8 weeks if we can keep to the desired schedule.

I think that's plenty of time.

[Giiba]

Oxide is the only one that works properly with the location service...

I have not tested since I crushed my OPO and started using a Pinephone though.

There is (was?) an oxide based webapp for google maps and it was the only one that properly locked location and tracked along. Morph (before the recent engine change) would lock location then freeze the location service and not update again, often requiring a reboot. It was the same for all web-based maps I tried.

Can the current morph maintain a location lock on a webpage?

[TotalSonic]

@Giiba - Google.com/maps finds my location in Morph with no problem in under a minute on Meizu Pro-5 post OTA-13 RC - just tested it now - you just need to give it permission to access your location when that dialog box pops up (a decision that you have an option for Morph to remember).

I unpublished yesterday the Ogra based Google Maps webapp (which uses Oxide) that I had posted 2 years ago. Between recent updates to uNav, Pure Maps, and OSM Scout Server, as well as the ability for Morph based webapps to find location, at this point I don't think it is actually necessary - and the Ogra webapp did not work on PinePhone or PineTab.

Best regards,
Steve Berson

[poVoq]

Remove as of OTA15 I would say.

Would be nice though if specific implementation details of morph.web could be better documented, as most apps seem to import qtwebengine directly.

[Giiba]

@TotalSonic but can it keep a lock and update as your location changes?

I ask honestly as the last time I tried in Morph 4 months ago, it did not work. I understand Oxide containers are old and have to go, but we should be sure the replacement functions fully. This is the only use case I had for an Oxide base app, everything else is handled very nicely by Morph.

[dobey]

@Giiba There are already other things not working in QtWebEngine which were working in Oxide that we know of; camera, mic, webgl, hw audio/video decoding, and probably a few other integration points.

However, Oxide is years old, unmaintained, and has known security holes which have been patched in newer versions of Chromium that QtWebEngine is based on. If we keep Oxide in the rootfs and people keep making webapps that use it, we'll never be able to get rid of it. We need to get it out and free up the space, and also get it removed from the realm of concern for developers.

If there are things that worked with Ubuntu.Web import when it was using Oxide, that don't when using Morph.Web with QtWebEngine, then let's get those differences documented in open issues against morph-browser on GitHub, rather than spending our time discussing it here, so appropriate people can maybe look into how those can be resolved.

If you really need a webapp using oxide, you can probably repackage a click to include the oxide components, as a temporary solution until your issues can be resolved in Morph/QtWebEngine. No, it's not ideal, but we need to move Ubuntu Touch forward, rather than to keep slowly stepping sideways with it.

[Giiba]

@dobey I couldn't (nor would) hold back progress, and your additions to my list of one item are exactly the sort of thing I hoped to draw out.

For the record, I am fully in support of continued development of Morph , and being on a Pinephone now I have stepped past oxide whether I wanted to or not.

[domubpkm]

Vivid is over. But the return of the webgl.

[domubpkm]

Bad possible news!
After a speech with @costales , it seems that uWriter can't find a solution to the transition.
So that would be the end of uWriter !

[dobey]

@domubpkm I'm not sure what it's doing exactly, but a quick look at the code looks like it could certainly be transitioned to Morph.Web and QtWebEngine, perhaps it also needs to use webchannels or websockets for what it's doing.