Can OTA-15 be the final release including Oxide?

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.