Crash when edit text

[bepolymathe]

I have a crash when I try to edit a file (after clicking on the file and then moving the cursor to the text).

Debug: Web rendering engine used: QWebView
Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.
Running manuskript version 0.9.0.
Found translation in settings: manuskript_fr.qm
Loaded translation from settings: manuskript_fr.qm.
Loading: /home/manu//RECC.msk
Detected file format version: 1. Zip: True.
Le projet /home/manu/RECC.msk a été chargé.
Fatal Python error: Segmentation fault

Current thread 0x00007f238e5b7740 (most recent call first):
  File "/usr/share/manuskript/manuskript/main.py", line 145 in launch
  File "/usr/share/manuskript/manuskript/main.py", line 158 in run
  File "/usr/bin/manuskript", line 30 in <module>
Erreur de segmentation (core dumped)

Is there a way to solve this problem?

[worstje]

I am on Windows myself and haven't experienced that.

Is this an official 0.9.0 release? And what linux distribution are you using?

This backtrace doesn't show anything of interest; the last thing it shows is the start-up process for the Qt library. But you've clearly already been interacting with the window. What version of Qt is on your system?

[bepolymathe]

I am under Fedora 29, official 0.9.0 release Manuskript. Qt5 installed

The problem is that the command "manuskript --console" doesn't explain more...

[gedakc]

It would seem that you are using Wayland instead of the traditional X11 on GNU/Linux.

Have you tried doing what the console messages suggest?

Warning: Ignoring XDG_SESSION_TYPE=wayland on Gnome. Use QT_QPA_PLATFORM=wayland to run on Wayland anyway.

To test, open a terminal window, export QT_QPA_PLATFORM=wayland, and then invoke manuskript from the terminal window

[bepolymathe]

I have tested this but the problem remains the same...

How can we go back?

[bepolymathe]

Maybe I spoke too quickly... it looks better. I continue the tests....

[bepolymathe]

No, the problem remains the same... i confirm.

Maybe appear after i tried to click on the icon "fullscreen"

[gedakc]

@bepolymathe please try to identify the exact set of steps that cause the crash.

I am unable to reproduce the issue. I have tried Manuskript 0.9.0 on Fedora 29 (64-bit) and even clicked on Fullscreen and I do not experience any crashes. I even tried changing the language setting to French and still no crashes.

[bepolymathe]

It is difficult to say what is causing the problem. I open a project (with the same problem) and when I approach the smile of the "fullscreen" icon it crashes... The proof in video

Link to see video

[gedakc]

@bepolymathe it is possible that the issue is with the specific project you are using.

Can you try creating a new project to see if the issue occurs?

Also you might consider uploading the Manuskript project that crashes so that we can try to re-create the issue.

[bepolymathe]

Same problem with new projet --» New projet
And the projet itself --» Projet

[gedakc]

Can you provide answers to the questions that @worstje originally asked for?

Did you install from RPM, run from source code, etc?

What software versions of Python and Qt are you using?
See Help -> About.

[bepolymathe]

Yes of course.

Installed from RPM version and for the rest...

[gedakc]

Interesting. I am unable to reproduce the issue, but my Fedora 29 VM has:

Python 3.7.0
PyQt 5.11.2
Qt 5.11.2

[bepolymathe]

I'm not crazy then ;-)

Maybe too fresh Python version ?

[gedakc]

I did an Internet search on "qt.qpa.wayland: Wayland does not support QWindow::requestActivate()" that you reported in an earlier comment and get lots of matches.

Quote from Comparing Qt Widgets App under Gnome wayland using platform wayland-egl to xcb:

qt.qpa.wayland: Wayland does not support QWindow::requestActivate()

This means your window tried to grab focus in the compositor, which is not allowed in wayland. Don't create a bug for it, there's nothing we can do.

Quote from Qt Creator / QTCREATORBUG-20400: Fails to go into Full Screen on Wayland:

This should be fixed when QtCreator starts using Qt 5.12

As a workaround, you can try to set QT_WAYLAND_SHELL_INTEGRATION=xdg-shell-v5 or QT_WAYLAND_SHELL_INTEGRATION=wl-shell.

Depends on your compositor whether it's supported.

It seems there are issues with Qt, Wayland, and the compositor. One user reported switching to KDE to avoid the issue. You might also consider downgrading to earlier versions of Python, PyQt, and Qt.

EDIT: Another user worked around a similar issue in Flatpak using XWayland instead of Wayland.

[bepolymathe]

Thank you for that clarification. That's a pity. I hope this problem will be fixed because other distributions will switch to Wayland later this year.

Is there a Flatpak version of Manuskript?

[gedakc]

Manuskript does run under Wayland. The problem you encountered appears to be a problem with the versions of Qt, Wayland, and the compositor. Manuskript runs properly on my Fedora 29 VM with Wayland, and the above mentioned Qt versions.

Can you try the workarounds listed above to see if they help in your situation?

For example:
export QT_WAYLAND_SHELL_INTEGRATION=xdg-shell-v5
or
export QT_WAYLAND_SHELL_INTEGRATION=wl-shell
before invoking manuskript.

[bepolymathe]

With "export QT_WAYLAND_SHELL_INTEGRATION=xdg-shell-v5" --» same problem
With "export QT_WAYLAND_SHELL_INTEGRATION=wl-shell" --» same problem

[bepolymathe]

After upgrading to Fedora 30... problem seems be solve. Why ? I don't know

[gedakc]

@bepolymathe thanks for reporting back that manuskript 0.9.0 works for you on Fedora 30.

My guess is that Fedora 30 includes newer versions of Qt that may include some bug fixes.

Would you please provide the software versions of Python and Qt are you are now using?
See Help -> About.

[bepolymathe]

Yes, new version of Qt

[gedakc]

It seems that Qt was updated from 5.11.3 to 5.12.1 with the upgrade from Fedora 29 to 30.

It is possible that the cause of the issue was a problem with Qt 5.11.3. In my testing with Qt 5.11.2 the crash did not occur.

Shall we close this issue as resolved?

[bepolymathe]

Yes, we can close. Thank you.