Cura: Cannot sign-in to Ultimaker Cloud in Cura 4.2.1 from Ubuntu 19.04

[darkernoise]

Application version

4.2.1
Platform

Ubuntu 19.04 64bit

Printer

an Ender 3 profile was selected

Reproduction steps

Open the official Cura AppImage file in Ubuntu 19.04, running standard Gnome 3 Desktop.
Click the "Sign In" button to the right of the "Marketplace" button
When the dialog box opens, hover over the "Sign In" button and notice that it changes color
Click the button

Actual results

Nothing happens

Expected results

Sign-in panel should have displayed allowing selection of Ultimaker account.

Additional information

https://i.imgur.com/D9O5YgL.png
CE3_square.zip
cura_log_clean.zip

[ChrisTerBeke]

I don't see anything in the logs that point to an error. The authorization callback server is started, and one second later the application is told to shut down (cleanly). Not sure though what is telling Cura to shut down.

[darkernoise]

Hello ChrisTerBeke. I agree. I don't see any issue in the log either. Though, the issue is that neither of the button presses for "Sign In" Or "Create Account" function. It is as if the events for those buttons are not registered. I have tested the same thing in Windows and it works there. This appears to be an issue with the AppImage on Ubuntu only.

[ChrisTerBeke]

I'm running the AppImage on Ubuntu (18.04) myself and it works. Maybe it's something in only the very latest Ubuntu version that's different?

[darkernoise]

A little Google-fu led me to this: https://unix.stackexchange.com/questions/417160/mouse-clicks-do-not-work-correctly-in-qt-applications

I am running a Dell XPS 15 with a touchscreen and it sounds like there is an issue with QT support of touchscreens. I tested by touch-tapping the "Sign In" and "Create Account" buttons and sure enough, they don't work via tapping either. I will do some more research.

[darkernoise]

I have followed the threads I could find around QT clicks not registering. Here is my xinput list:

xinput --list
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ SYNA2393:00 06CB:7A13 Touchpad id=14 [slave pointer (2)]
⎜ ↳ Microsoft Microsoft® 2.4GHz Transceiver v7.0 Consumer Control id=21 [slave pointer (2)]
⎜ ↳ Logitech MX Master id=24 [slave pointer (2)]
⎜ ↳ Microsoft Microsoft® 2.4GHz Transceiver v7.0 Mouse id=26 [slave pointer (2)]
⎜ ↳ Microsoft Microsoft® 2.4GHz Transceiver v7.0 Consumer Control id=27 [slave pointer (2)]
⎜ ↳ Wacom HID 488E Pen eraser id=20 [slave pointer (2)]
⎜ ↳ Wacom HID 488E Pen stylus id=12 [slave pointer (2)]
⎜ ↳ Wacom HID 488E Finger id=13 [slave pointer (2)]

I tried the suggestion of xinput disable on 20, 12, and 13, all the Wacom inputs. Though, that did not solve the problem. Also, followed another suggestion which was to try double-click. That does not work either. Anyway, it sounds likely that the problem is likely upstream and not a Cura problem. Though, I don't know how Ultimaker will feel about users of their app not being able to sign-in.

When I get time, I will setup a source environment to debug further.

[darkernoise]

Here is one more piece of info: When I execute the AppImage via a terminal, this error message occurs on click:

cannot open path of the current working directory: Permission denied

I tested dropping the AppImage into the user home directory and chmod 777 on the file. The same error message still occurs on click. Though, that error, nor information about it, is not in the cura.log.

[darkernoise]

Here is more info yet. I mounted the AppImage and copied the source to another dir and then chown to the run user. When I execute the script from a terminal this way, here is the error information visible:

mkdir: symbol lookup error: mkdir: undefined symbol: mode_to_security_class
mkdir: symbol lookup error: mkdir: undefined symbol: mode_to_security_class
mkdir: symbol lookup error: mkdir: undefined symbol: mode_to_security_class
mkdir: symbol lookup error: mkdir: undefined symbol: mode_to_security_class
mkdir: symbol lookup error: mkdir: undefined symbol: mode_to_security_class
/snap/chromium/784/usr/lib/chromium-browser/chrome: symbol lookup error: /snap/chromium/784/usr/lib/x86_64-linux-gnu/libpangoft2-1.0.so.0: undefined symbol: FcWeightToOpenType

[darkernoise]

If it helps, the issue I am seeing sure looks a lot like this: https://github.com/Ultimaker/Cura/issues/3072

[LipuFei]

We current use the webbrowser module for that "Sign in" button. I see that most other modules are using QDesktopServices.openUrl() instead. I'll change it to QDesktopServices and create a Linux AppImage. @darkernoise Could you help us testing this fix? I'll send you the link to download that AppImage when it's done. Thanks in advance.

[LipuFei]

Hi @darkernoise , could you test this AppImage for us?

Download link: https://we.tl/t-LBm5KJdE5S

[darkernoise]

Hello LipuFei,

Sure, I will test it thoroughly this evening and report back.

[darkernoise]

Hello LipuFei,

I am afraid that there is a still a problem. None of the Help menu items, nor the sign-in options are working. I am still getting the error:

qml: TableViewSelection: index out of range
cannot open path of the current working directory: Permission denied

I am not that familiar with QT in an AppImage, but could this be that the AppImage is running in a Sandboxed environment and is not being allowed to open an external path reference?

If I test this code, for example, it works fine when run from the command line:

`import sys
from PyQt5.Qt import QDesktopServices, QUrl, QGuiApplication

if __name__ == '__main__':
app = QGuiApplication(sys.argv)
url = QUrl('http://www.google.com')
QDesktopServices.openUrl(url)`

I am sorry that this is not a solution, but I hope this helps.

[darkernoise]

If it helps, I tested the following:

• To rule out config file permissions. Closed the app, deleted the directory : ~/.local/share/cura, opened Cura again, and tested. The result is the same error.

• Installed Firefox since QT has different source options per Browser. - No Change

• As a test, tried opening the AppImage via sudo. Thankfully, this is checked for and not allowed.

• Logged in via Mate instead of Gnome 3, the default for Ubuntu 19.04 : No Change

Also, looking at the documentation here:

https://doc.qt.io/qt-5/qdesktopservices.html in section "Detailed Description", it says:

The user's desktop settings control whether certain executable file types are opened for browsing, or if they are executed instead. Some desktop environments are configured to prevent users from executing files obtained from non-local URLs, or to ask the user's permission before doing so.

I do not see an authorization dialog. Could this interface between QT and Ubuntu 19.04 be the issue?

[LipuFei]

Hi @darkernoise , the error qml: TableViewSelection: index out of range can be ignored. The other message cannot open path of the current working directory: Permission denied says something about your current working directory. Could you tell where you put the downloaded AppImage and how you ran it? Which directory were you in? etc.

[darkernoise]

LipuFei, I have figured out the root of the problem: Chromium 75.0.3770.100. If I switch the default web browser to Firefox, then the QT.URL links work correctly. Apparently there is a security setting or something of the sort that is blocking this in Chromium.

So for now, work-around is : switch default browser in settings of Ubuntu to Firefox while signing-in or accessing help.

I will some additional research to see if there is a way to fix the issue with Chromium.

[LipuFei]

Hi @darkernoise, I tested the AppImage I uploaded in https://github.com/Ultimaker/Cura/issues/6194#issuecomment-521131263 on Ubuntu 18.04.3 LTS and 19.04, both freshly installed with Chromium as the default browser. On Ubuntu 19.04, the Chromium version is 76.0.3809.100. When I click "Sign In", in both cases, Chromium was opened with the correct sign in page. I also tried all "Help" menu items and they all worked.

I uploaded the AppImage again here. Could you try it again? Thanks.
Link: https://we.tl/t-2vgnzuXwEW

[darkernoise]

Hello LipuFei,

I upgraded my Chromium to 76.0.3809.100 as you did. Though, my problem persists. As a test, I

Created a VirtualMachine via VirtualBox with a clean install of Ubuntu 19.04
Installed Chromium via the Ubuntu Application Store
Downloaded Cura 4.2.1 via the AppImage

With the above completely clean VM, the help menu and sign-in features do not work with Chrome 76.0.3809.100. As a test, I would like to see what happens when you run this very same VM. Do you have a location I can upload this VM?

Edited: I also installed the AppImage you linked above into the VM. It does not work with Chrome either. Both Cura versions have links on the VM desktop. The file size is ~5gb.

[darkernoise]

Hello LipuFei,

Here is a video showing the problem on the VM I emailed you details on how to download. This VM is created from a new Ubuntu 19.04 installation. I applied updates and then installed the following: Chromium, Cura 4.2.1 (and the test version), and Kazam to record the video. As you will see, if the default Browser is Chromium, the URL links do not work. Though, when switched to Firefox, they do:

https://youtu.be/I9aEU5Iexvw

As you will see in the VM, this is Chromium Version 76.0.3809.100 (Official Build) snap (64-bit)

[LipuFei]

Hi @darkernoise , thanks for the video! I found out why it worked in my case: I used apt install chromium-browser instead of installing it via the Ubuntu Application Store (via snap). I'm working on a fix now.

As for the Help menu items, I don't really know what happened. Does other menu items such as "Preferences" work for you?

[LipuFei]

The browser issue is fixed in f4dc9cc6a. I've also made another AppImage. Could you try it?

Link: https://we.tl/t-FhGiAs0dX2

[LipuFei]

JIRA ticket: CURA-6727

[LipuFei]

Made another fix https://github.com/Ultimaker/Cura/commit/4762711c3374c8f6372e5d8ec73fedb52baf59da

Link for the new AppImage: https://we.tl/t-m9qPrMZIGx

[darkernoise]

Hi @LipuFei . I am pleased to report that browser linking in the Ubuntu 19.04 Chrome Snap is now working correctly. Nice job! I tested the Help menu items as well as the Sign In and all work. Thank you very much for your hard work and attention on this!