Bug 1774762

Summary: Qt Creator: cannot drag & drop widgets in Wayland
Product: [Fedora] Fedora Reporter: Andrea <mariofutire>
Component: mutterAssignee: Florian Müllner <fmuellner>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 31CC: fmuellner, gnome-sig, helio, itamar, jadahl, jgrulich, jreznik, kde-sig, manisandro, otaylor, philip.wyett, rdieter, walters
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-07-02 08:16:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Andrea 2019-11-20 21:38:20 UTC
Description of problem:

When running in a wayland session one cannot drag & drop widgets in Qt Creator to design the UI

Version-Release number of selected component (if applicable):

Fedora 31 fully updated, Qt Creator 4.10.2

How reproducible:

Always

Steps to Reproduce:
1. Create a new Qt Widget Application with all default settings
2. Open the mainwindow.ui Form
3. Drag Drop any widget

Actual results:

In Wayland, the drop is rejected

Expected results:

Under X11, the widget is added to the Form

Comment 1 Jan Grulich 2019-11-21 07:52:03 UTC
Is this in Gnome wayland session? I cannot reproduce in Plasma Wayland session and it also works for me under Weston, which indicates it might be a bug in Mutter.

Comment 2 Andrea 2019-11-21 08:00:45 UTC
It is indeed a GNOME session. Forgot to say.

Wayland I tried GNOME
X11 I tried GNOME Classic

Comment 3 Andrea 2019-11-22 20:25:29 UTC
I think you can add another odd behaviours:

text cursor disappears every now and then.

By changing focus a few times it comes back.

Comment 4 Andrea 2019-11-24 15:49:03 UTC
Do I need to open a new bug report for mutter?

Comment 5 Jan Grulich 2019-11-25 13:14:52 UTC
I opened upstream bug: https://bugreports.qt.io/browse/QTBUG-80303

We will see if it's a bug in Qt or Mutter.

Comment 6 Andrea 2019-11-26 22:23:35 UTC
I have tried again downloading the debug info.
But I dont really know if/where the report was uploaded. The crash tool is very sparse with useful information.

Comment 7 Andrea 2019-11-26 22:24:56 UTC
Comment 6 is about a different issues.
Ignore it.

Comment 8 Andrea 2019-12-09 08:36:17 UTC
There are other odd behaviours of Qt applications in GNOME Wayland:

QMainWindow::restoreState() and QMainWindow::restoreGeomerty() do not work.

They do work with -platform xcb.

I think Qt on GNOME Wayland is just not ready.

Comment 9 Jan Grulich 2019-12-09 09:01:28 UTC
(In reply to Andrea from comment #8)
> There are other odd behaviours of Qt applications in GNOME Wayland:
> 
> QMainWindow::restoreState() and QMainWindow::restoreGeomerty() do not work.
> 
> They do work with -platform xcb.
> 
> I think Qt on GNOME Wayland is just not ready.

I'm not sure if this is intentional, because in my opinion windows on Wayland shouldn't be able to position or resize themself, but I might be wrong. 

I saw there are some patches on review which will add support for maximize/minimize/fulscreen for the clients, which should at least partially solve your problem.

Comment 10 Andrea 2019-12-09 09:13:04 UTC
Fine, if it turns out to be a feature rather than a bug, I am not going to argue (here).
I will try to read about the principles behind this decision and how the whole wayland thing work as a whole.

Comment 11 Andrea 2019-12-09 09:28:27 UTC
It is very strange as in Plasma / Wayland (not just Plasma, but the Plasma on Wayland) it behaves correctly.
Not sure what to make of it.

Comment 12 Fedora Update System 2019-12-10 13:43:33 UTC
FEDORA-2019-690a29587a has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2019-690a29587a

Comment 13 Fedora Update System 2019-12-11 01:41:48 UTC
qt5-qtbase-5.12.5-2.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-690a29587a

Comment 14 Jan Grulich 2019-12-11 09:42:27 UTC
I would like to add that this issue looks to be a Mutter bug: https://gitlab.gnome.org/GNOME/mutter/issues/965

Not everything is QWayland fault.

Comment 15 Fedora Update System 2019-12-12 01:54:22 UTC
qt5-qtbase-5.12.5-2.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.

Comment 16 Andrea 2019-12-14 15:59:33 UTC
It "does work" now but I think it is simply because it does not run on wayland by default.

If I start qt creator with "-platform wayland" it still does not work.

These are the release notes for the new package

* Tue Dec 10 2019 Jan Grulich <jgrulich> - 5.12.5-2
  - Blacklist some applications from being used on Wayland
  - QMimeData: Prefer UTF-8 when multiple charsets are available

I think QT Creator has simply been blacklisted...

Comment 17 Jan Grulich 2019-12-15 07:01:10 UTC
QtCreator has been blacklisted until this is fixed in Mutter. Either we can close this with thw workaround I did or I close it as a bug in Mutter. Anyway there is nothing else I can do.

Comment 18 Andrea 2019-12-15 13:08:03 UTC
The only thing Fedora could consider in the future is blacklist *all* Qt application.
If drag & drop is deemed a *key* feature of Qt applications then I think this applies.


And the whole point is really to push for the Mutter bug to be fixed as a top priority.
As one of the main distros using GNOME I am sure Fedora voice has a big weight in Mutter's bug triage.

Comment 19 Sandro Mani 2020-02-13 15:16:05 UTC
This is now fixed upstream in master [1] and in 3.34 branch [2]. Reassigning to mutter for consideration whether to backport the patch.

[1] https://gitlab.gnome.org/GNOME/mutter/commit/ffad55c66f5b131cdaa92ef61c44d99b7c7312b5
[2] https://gitlab.gnome.org/GNOME/mutter/commit/666bd25005511684ba44fab693ce44772730c372

Comment 20 Sandro Mani 2020-07-02 08:16:20 UTC
F31 has mutter-3.34.6-1.fc31 which I believe contains the fix.