Unable to login to Tidepool from the application on Linux

[amos1969]

I'm using Kubuntu 24.10.

I can launch the app after following the instructions in this previous issue.

Clicking on the Login button in the app then opens the page at app.tidepool.org for me to login at, which I'm able to do, but then clicking on the Launch Uploader button does not return me to the application properly. As expected it opens up an xdg-open dialogue window:

Initially clicking on the open button gave me a complex error as it didn't know what to open, but after finding the desktop file I manually copied it from the resources/linux folder in the project to ~/.local/share/applications folder and made it executable I now get the following error:

The contents of the uploader.desktop file changes when I make it executable. The initial version in the repo has:

[Desktop Entry]
Type=Application
Name=Tidepool Dev Uploader
MimeType=x-scheme-handler/tidepooluploader;

but when I make it executable it changes to:

[Desktop Entry]
Comment[en_GB]=
Comment=
Exec=''
GenericName[en_GB]=
GenericName=
MimeType=
Name[en_GB]=Tidepool Dev Uploader
Name=Tidepool Dev Uploader
Path=
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
X-KDE-SubstituteUID=false
X-KDE-Username=

I tried adding the MimeType line back in manually but it has no effect.

I copied the udev rule file across to the correct place too but obviously haven't gotten that far yet.

Basically once I log in to the website in the browser (Chrome) I am unable to return to the application as it doesn't recognise the tidepooluploader protocol and therefore doesn't know how to handle it.

Any ideas as to how to proceed?

[gniezen]

Hi @amos1969 ! I'm using Ubuntu as well, so I'm hopeful you'll be able to get this working. Start by deleting the uploader.desktop you copied to ~/.local/share/applications and run scripts/start-linux.sh from your main uploader folder. That should install a new uploader.desktop correctly.

[amos1969]

Thanks @gniezen that got me somewhat further.

I had to edit line 10 of the start-linux.sh script to remove the extra . as the script doesn't change the directory, so the path to the desktop file wasn't being found relative to the current directory. A better solution would probably be to use the value in SCRIPT_DIR to find the resources one. After doing that, it correctly copies the desktop file across and starts the app, with some errors showing:

Uploader.desktop is installed.
Using the default environment, which is now production.
Starting Main Process...
(node:24958) ExperimentalWarning: Importing JSON modules is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
<i> [webpack-dev-server] Project is running at:
<i> [webpack-dev-server] Loopback: http://localhost:3005/, http://[::1]:3005/
<i> [webpack-dev-server] On Your Network (IPv4): http://192.168.1.132:3005/
<i> [webpack-dev-server] Content not from webpack is served from '/home/amos/Projects/Health/uploader/dist' directory
<i> [webpack-dev-server] 404s will fallback to '/index.html'
Crash logs can be found in: /home/amos/.config/Electron/Crashpad
Last crash report: null
An error occurred:  Error: Invalid header: Does not start with Cr24
    at crxToZip (/home/amos/Projects/Health/uploader/node_modules/unzip-crx-3/dist/index.js:32:15)
    at /home/amos/Projects/Health/uploader/node_modules/unzip-crx-3/dist/index.js:69:32
    at callHanler (/home/amos/Projects/Health/uploader/node_modules/yaku/lib/yaku.js:719:16)
    at tryCatcher (/home/amos/Projects/Health/uploader/node_modules/yaku/lib/yaku.js:436:32)
    at /home/amos/Projects/Health/uploader/node_modules/yaku/lib/yaku.js:575:38
    at flush (/home/amos/Projects/Health/uploader/node_modules/yaku/lib/yaku.js:478:17)
    at processTicksAndRejections (node:internal/process/task_queues:77:11)
<i> [webpack-dev-middleware] wait until bundle finished: /dist/renderer.dev.js
[25007:0515/161242.267292:ERROR:CONSOLE(1)] "Request Autofill.enable failed. {"code":-32601,"message":"'Autofill.enable' wasn't found"}", source: devtools://devtools/bundled/core/protocol_client/protocol_client.js (1)
[25007:0515/161242.267342:ERROR:CONSOLE(1)] "Request Autofill.setAddresses failed. {"code":-32601,"message":"'Autofill.setAddresses' wasn't found"}", source: devtools://devtools/bundled/core/protocol_client/protocol_client.js (1)
Uploading only new records

The app window opens showing the console and a warning overlay (for missing devices I guess):

Closing the overlay shows me the window:

If I click on the button to login, it takes me to the webpage, to login.

The button to login in the app becomes greyed out in the process:

Once I login and click on the button marked Launch Uploader, the dialogue opens and I click on the Open Tidepool Dev Uploader button, at which point a second Tidepool object appears in the bottom panel for a few seconds as it tries to open/detect the open app.

After a few seconds that second Tidepool object disappears from the panel, the button in the app becomes available again and the bottom two entries in the console window in the app are duplicated

but the app remains logged out.

It feels like progress but still not quite there yet.

The behaviour is the same whether I try it in the development, release-2.62.0 or v2.61.0 branches.

[gniezen]

You only have to run start-linux.sh once. From then on you can use yarn dev to run Uploader. First thing is to make sure you're using the right Node.js version - just run nvm use if you have nvm installed. Then delete node_modules and app/node_modules and run yarn to reinstall dependencies, before running yarn dev.

[amos1969]

I spotted the nvm use command and had already used it. I just tried it following your steps (I had missed that there was another node_modules folder to delete in app). Here's the output from running it with yarn dev:

❯ yarn dev  
Using the default environment, which is now production.
Starting Main Process...
(node:56537) ExperimentalWarning: Importing JSON modules is an experimental feature and might change at any time
(Use `node --trace-warnings ...` to show where the warning was created)
<i> [webpack-dev-server] Project is running at:
<i> [webpack-dev-server] Loopback: http://localhost:3005/, http://[::1]:3005/
<i> [webpack-dev-server] On Your Network (IPv4): http://192.168.1.132:3005/
<i> [webpack-dev-server] Content not from webpack is served from '/home/amos/Projects/Health/uploader/dist' directory
<i> [webpack-dev-server] 404s will fallback to '/index.html'
Crash logs can be found in: /home/amos/.config/Electron/Crashpad
Last crash report: null
An error occurred:  Error: Invalid header: Does not start with Cr24
    at crxToZip (/home/amos/Projects/Health/uploader/node_modules/unzip-crx-3/dist/index.js:32:15)
    at /home/amos/Projects/Health/uploader/node_modules/unzip-crx-3/dist/index.js:69:32
    at callHanler (/home/amos/Projects/Health/uploader/node_modules/yaku/lib/yaku.js:719:16)
    at tryCatcher (/home/amos/Projects/Health/uploader/node_modules/yaku/lib/yaku.js:436:32)
    at /home/amos/Projects/Health/uploader/node_modules/yaku/lib/yaku.js:575:38
    at flush (/home/amos/Projects/Health/uploader/node_modules/yaku/lib/yaku.js:478:17)
    at processTicksAndRejections (node:internal/process/task_queues:77:11)
[56593:0515/170957.917800:ERROR:CONSOLE(1)] "Request Autofill.enable failed. {"code":-32601,"message":"'Autofill.enable' wasn't found"}", source: devtools://devtools/bundled/core/protocol_client/protocol_client.js (1)
[56593:0515/170957.917857:ERROR:CONSOLE(1)] "Request Autofill.setAddresses failed. {"code":-32601,"message":"'Autofill.setAddresses' wasn't found"}", source: devtools://devtools/bundled/core/protocol_client/protocol_client.js (1)
<i> [webpack-dev-middleware] wait until bundle finished: /dist/renderer.dev.js

Sadly the result is exactly the same as before.

[gniezen]

Ah, I forgot that we recently started using corepack and you should run corepack enable before you run yarn. Not sure if that will resolve your issue.

The "Does not start with Cr24" error is strange - I can't reproduce it on my side, and it seems to have something to do with extensions that are only used for development/debugging purposes.

If you have a look at scripts/start-linux.sh again, you'll see there's a comment at the end to add &> /tmp/uploader.txt to the last line. Would you mind doing that and then try running it again? Then we can see what happens after you logged in and it passes back to the Uploader again, which I suspect is where the real issue is.

[amos1969]

It failed in the same way as before (I think I'd previously spotted the corepack enable command and run it, but have run it again). Attached should be the uploader.txt file after it fails.

uploader.txt

[gniezen]

Okay, I can see

Error: listen EADDRINUSE: address already in use :::3005

in the log. That means there is already an instance of Uploader open?

I also see

xdg-mime: application argument missing

which makes me wonder if there's still an issue with your uploader.desktop. Here's what mine looks like:

[Desktop Entry]
Type=Application
Name=Tidepool Dev Uploader
MimeType=x-scheme-handler/tidepooluploader;
Exec=sh -c "/home/gerrit/Code/tidepool/uploader/scripts/start-linux.sh %u"
X-Desktop-File-Install-Version=0.27

[amos1969]

There is an instance of uploader open as that's where I'm launching the login process from. I start the app, click on the login button, get redirected to Chrome to login and then it fails to reconnect to the app when I click to open, once I've logged in in the browser.

My uploader.desktop matches yours:

[Desktop Entry]
Type=Application
Name=Tidepool Dev Uploader
MimeType=x-scheme-handler/tidepooluploader;
Exec=sh -c "/home/amos/Projects/Health/uploader/scripts/start-linux.sh %u"
X-Desktop-File-Install-Version=0.27

[gniezen]

What does xdg-mime query default x-scheme-handler/tidepooluploader return?

You may need to run xdg-mime default uploader.desktop x-scheme-handler/tidepooluploader to register it properly, as it should return uploader.desktop. If that works, we should add it to the script.

[amos1969]

It appears to already be registered:

I reran the second command on the off chance it would make difference but launching the app and doing the whole login rigmarole still had exactly the same effect.

One thing I did notice is that after logging in, in the browser, after a few seconds the app window will regain focus, but without successfully logging in.

[amos1969]

I just noticed in the console in the app that there's a warning about a missing prop for LoggedInUser in the propTypes declaration (where it is set as required) even though at that point the user won't be logged in anyway. Not sure if this is relevant or not:

[gniezen]

No, I don't think the warning is relevant.

Okay, let's a different approach. If you run yarn dev-web, it should run Uploader inside your browser, instead of in a separate app. So you wouldn't need deep linking to work for logging in. Caveat: this only works with Chrome, and doesn't support OneTouch meters on Linux yet.

[gniezen]

Hi @amos1969 , just checking yarn dev-web worked for you?