[Headsup] deprecation of manifest v2, enforcement of manifest v3 and separately the deprecation of websql

[garfield69]

When chromium switch off support for manifest v2 (Mv2) in June 2023 and enforce manifest v3 (Mv3) then DuckieTV will need significant updates if it is to continue to run in any of the chromium browsers.
Support for Mv3 began on Chromuim 88, and the Web Store stopped allowing new extensions with Mv2, but that does not impact Dtv since we lost access to the Web Store years ago when they changes their security policy which Dtv cannot comply with due to the nature of its purpose.

(1) In theory the standalone build could continue to run as is, we would just stop upgrading NWJS and remain on the last chromium version that supports Mv2.
This is likely the option I will take, as I am not prepared to invest time to research, convert/replace/rewrite code.

A taste of what will become necessary:
To migrate to Mv3 will require some significant changes.
https://developer.chrome.com/docs/extensions/mv3/intro/mv3-migration/

Additionally, background scripts become service workers, which will need to change in a whole bunch of ways, as timers need to move to alarms, among other requirements.
https://developer.chrome.com/docs/extensions/mv2/background_pages/

Also in the pipeline: Developers should expect that WebSQL itself will be deprecated and removed when usage is low enough. Chromium 101 already Remove WebSQL in Third-Party Contexts but this does not appear to impact Dtv.

I definitely will not be converting/migrating the websql code to Indexed Database ahead of websql being switched off,
and will action option (1).

Unless, of course, some bright volunteer takes over and starts bringing Dtv up to date.

[CummingCowGirl]

Think since no one seems to b e willing to bring DTV up to date it's time to finally die, cause if it's not a security risk now it will be. I'm heading over to Tweak4All and ask Han's if he's interested or knows someone interested in breathing life into DTV. I for one would love to see it survive as a proper alternative to Sonarr. Without a lot of the CRAP the Sonarr devs think are important.

[garfield69]

Its happened. Chromium 119 has removed Web SQL
https://developer.chrome.com/blog/deprecating-web-sql/

So Dtv will not longer work on chrome browser.

That leaves only Dtv Standalone where we can lock in the last chromium to 118 for as long as that keeps running.

[Js41637]

You can get WebSQL back by enabling a chrome flag, i am unsure when and if they will be removing it though.
chrome://flags/#web-sql-access

[garfield69]

With Chromium 124 the WEB SQL support has been removed.

[Js41637]

I don't know how but I somehow managed to get manifest V3 working and replaced using WebSQL with SQLite though i have not really tested it much yet but it loads and i can add a show.
angular...feat/manifest-v3-insanity

WebSQL is basically identical to Sqlite so there really isn't any changes needed except for a couple edge cases. The only real problem is using sqlite as it requires web assembly and Chrome has made it really painful to use without having to jump through a heap of hoops 😒

[dewerl]

So, any plans on switching to SQLite instead of WebSQL för the browser extension? Been using DuckieTV for several years and I'm now on the "last" Chrome version where you still can activate WebSQL. Tried the standalone version, but it just hangs and won't start most of the time (Macbook Pro, M1). Tried Sonarr briefly but I didn't like it as much as I do with DuckieTV which, as I said, has been a steady companion for years... so, any thought on migrating to SQLite?

[Js41637]

Well there is the branch which you could try I guess. It seems to work but I suspect the performance is not going to be as good as there is more hoops to jump through when using sqlite compared to websql. It would also require importing a backup as there is no way to migrate existing data.

I was looking into if we can build a proper ARM build of the standalone version to see if it would work better for macs but the build tool is basically impossible to test and we have little control over it....

[garfield69]

@dewerl
Have you tried https://github.com/SchizoDuckie/DuckieTV/wiki/How-to-run-a-DuckieTV-Standalone-for-osX-ARM64 ?

If that does not work then you there is a SQLite WIP available as source. Fork this repo and switch to the manifest-v3-insanity branch. You can then try it with a Browser Extension in development mode, see https://github.com/SchizoDuckie/DuckieTV/wiki/How-to-Install-a-Development-version-of-the-DuckieTV-Chrome-Browser-Extension-SOURCE
Only the TAB mode manifest is provided, and there is no migration available other than via a Dtv backup import.

[garfield69]

@Js41637 Is the mac ARM build going to be exactly the same duckietv-builder code as the mac x64, other than using the ARM NWJS binaries ?
Because if it is identical in every other way, then I can readily duplicate that builder code and create a ARM package for someone to test with.
However, if there are additional package changes needed, such as a different mac archive method, then that is where I will become unstuck.

[Js41637]

I think it is possible to add arm support to the build script but I cannot test it, it depends on programs and tools that I don't have and I cannot find. I managed to test the building and making the binary but the package binary part I cannot run. It's possible it just works but I am not sure. I pushed it to a branch DuckieTV/duckietv-builder@9880d5d

As for the sqlite thing. Another thing is it uses some special chrome storage thing. I don't really understand how it works or how persistent the storage is. Another downside is it's impossible to access the database file externally. Chrome stores it in some special way that is only accessable to Chrome.

[garfield69]

I will see if I can use that duckietv-builder branch to create a ARM nightly and I'll post a link to the package if I can get my builder to generate it.

[garfield69]

@Js41637 find the arm package at this temporary location https://github.com/SchizoDuckie/DuckieTV/releases/tag/1.1.6
however, the osx.js is not set up correctly for multiple arch, as after packaging the x64, if fails to begin the arm64, with

Packaging: DuckieTV-202405101613-OSX-arm64.pkg
/home/garfield69/duckietv-builder/node_modules/shelljs/src/common.js:401
      if (config.fatal) throw e;
                        ^
Error: cp: no such file or directory: /home/garfield69/duckietv-builder/platforms/osx/build/*
    at Object.error (/home/garfield69/duckietv-builder/node_modules/shelljs/src/common.js:110:27)
    at /home/garfield69/duckietv-builder/node_modules/shelljs/src/cp.js:246:14
    at Array.forEach (<anonymous>)
    at _cp (/home/garfield69/duckietv-builder/node_modules/shelljs/src/cp.js:243:11)
    at /home/garfield69/duckietv-builder/node_modules/shelljs/src/common.js:384:25
    at /home/garfield69/duckietv-builder/platforms/osx.js:95:17
    at Array.map (<anonymous>)
    at Object.packageBinary (/home/garfield69/duckietv-builder/platforms/osx.js:82:27)
    at /home/garfield69/duckietv-builder/duckietv-builder-package-binaries.js:37:15
    at Array.map (<anonymous>)

I was able to circumvent by reordering the architectures from x64,arm64 to arm64,x64, but that meant that the x64 packaging fails instead.