Bug 363548

Summary: file area becomes inaccessible for the mouse after opening a file on hidpi screen when using a multi monitor setting
Product: [Applications] dolphin Reporter: moert09
Component: view-engine: generalAssignee: Dolphin Bug Assignee <dolphin-bugs-null>
Status: REOPENED ---    
Severity: grave CC: brian, danielkza2, d_p_leone, elvis.angelaccio, faure, grumpfl, hsanson, kde, kdebugtracker, mads, mailad34, martijnvdc, miabraha, nate, pauloedgarcastro, romuluspb, rrockers, seanvk, simonandric5, wim.delvaux, yannick.leteigner, yuxin.ma1989
Priority: NOR    
Version: 16.12.2   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In: 5.35
Sentry Crash Report:

Description moert09 2016-05-26 13:28:24 UTC
I am currently facing a really annoying bug. I am using a laptop with a hidpi screen and a resolution of  3200x1800 pixles. So it is necessary to do screen scaling. Since qt 5.5 I used the QT_DEVICE_PIXEL_RATIO environment variable to scale qt5 applications but qt5.6 broke this option. With qt5.6 to achieve similar results I use QT_SCREEN_SCALE_FACTORS (same happens when using QT_AUTO_SCREEN_SCALE_FACTOR).

Now, when I have connected a second monitor (extended) and have dolphin on the laptop screen and open a file using double click (or single click when configured in the system settings), the file area and the left panel become completely unresponsive to any mouse event (no hover no click). It is like there is a invisible rectangle above the areas. The funny part is, when I drag dolphin to the second screen, everything behaves normal again, as long as it stays on the second screen. If I drag it back to the laptop it is unusable again.
When dolphin is on the second screen, and a file is launched, dolphin behaves normal, but when the window is dragged to the laptop it does not work again.
To resolve this behavior dolphin has to be restarted, but if a file is opened via double click it is unresponsive again.

This does not happen if the file is opened via the context menu and the location bar, toolbar and info panel are always working. Interestingly I am always able to use the keyboard to navigate to other folders/files and open them with enter, so only mouse mouse events are blocked.

Reproducible: Always

Steps to Reproduce:
1. export QT_SCREEN_SCALE_FACTORS="2;2" in /etc/profile.d
2. connect second screen
3. open dolphin on your (main??) screen
4. open a file with double click

Actual Results:  
dolphins file area and left panel do not respond to mouse events anymore

Expected Results:  
you should be able to use the mouse to open files and folders

Below you can find a screenshot of the inaccessible areas:
http://i.imgur.com/rfQGjuH.png
Comment 1 moert09 2016-05-26 13:30:58 UTC
the actual dolphin version is 16.04.1
Comment 2 pauloedgarcastro 2016-07-19 11:15:19 UTC
Exactly the same behaviour here.
The only QT_* variables defined are:

$ set | grep QT_
QT_DEVICE_PIXEL_RATIO=2
QT_IM_MODULE=xim

The issue doesn't happen if I unset QT_DEVICE_PIXEL_RATIO.

Dolphin Version 15.12.3

Using:
KDE Frameworks 5.23.0
Qt 5.6.1 (built against 5.6.0)
The xcb windowing system
Comment 3 Michael 2016-07-27 00:31:19 UTC
I'm getting the same thing with current KDE Neon. (Plasma 5.6.1, Frameworks 5.24.0, Dolphin 16.04.2)

On my center monitor, mouse clicks register correctly on the right half of the Dolphin window but not on the left half.
Comment 4 Michael 2016-07-27 01:13:10 UTC
Took a closer look at this bug since I'd quite like it fixed.

In KItemListController.cpp around line 529, the function: 

bool KItemListController::mousePressEvent(QGraphicsSceneMouseEvent* event, const QTransform& transform)

does not seem to be receiving any mouse events when clicking on the left half of the view after the bug is triggered. Debug output is generated from clicks in this part of the screen before opening a file, but after opening a file the debug output is gone.
Comment 5 Michael 2016-07-29 12:53:00 UTC
Also a usable workaround for me on Neon:

export QT_SCREEN_SCALE_FACTORS= && dolphin %u
Comment 6 Martijn 2016-10-17 10:03:35 UTC
I have the same problem but the cause is different. I simply have to hover the cursor around a bit and it will randomly stop receiving mouse events. 
When this happens, SOME of the files/folders that are listed will still be able to receive the events. It seems to be completely random.
Comment 7 d_p_leone 2016-12-05 22:53:58 UTC
I'm getting hit by the same bug.
System:
- Debian Stretch (testing)
- KDE Plasma 5.8.2
- dual screen setup (one hidpi, one regular 1920x1200)

Same symptom as described by everybody else: an area within the dolphin window becomes unresponsive to mouse clicks.  I can still use the cursor keys to change the currently selected file and open a file by hitting return. But the window is unresponsive to mouse clicks.
Comment 8 auxsvr 2016-12-17 18:42:45 UTC
*** This bug has been confirmed by popular vote. ***
Comment 9 Kai Uwe Broulik 2017-01-01 18:50:29 UTC
I can confirm when I run dolphin with QT_SCREEN_SCALE_FACTORS="2;2" but when I run it with QT_SCREEN_SCALE_FACTORS="2;1" it resizes and re-scales fine when I move it to the other screen. Very weird.
Comment 10 Kai Uwe Broulik 2017-01-01 19:46:12 UTC
This bug is so absurd. The bug does not happen if I don't pass a window to the "new KRun" call in DolphinViewContainer.

It passes "this", ie. the DolphinViewContainer widget, which has status bar, KUrlNavigator as well as the DolphinView (one of the affected QGraphicsViews). I traced it down in KRun to KStartupInfo. If I remove the KStartupInfo::sendChange(id, data); call in KRun the bug does not happen.

CC'ing David F (as KRun guru) and Martin G (as KWindowSystem guru) - I have no idea how this happens. The docs for KStartupInfo say it's the "top level widget", so perhaps it should be DolphinMainWindow (indeed, if for testing f I pass KMainWindow::memberList().first()) and not the view container? I don't see how this could end up keeping mouse events (stuff like "window became (in)active" arrive fine) from the graphics views?! It even affects the places sidebar which is *not* in the affects DolphinViewContainer but has its own afaics.
Comment 11 Martin Flöser 2017-01-01 19:53:08 UTC
My theory: due to the scaling Qt did not create a native window. But once KStartupInfo is used the wid is needed, thus a window gets created and that is stealing the events.
Comment 12 Kai Uwe Broulik 2017-01-03 17:10:09 UTC
Yup, Qt creates native windows. We do winId() on the DolphinViewContainer which will apparently causes Qt to create a native window chain up until the first window it encounters.

When I set WA_DontCreateNativeAncestors I suddenly get a mirror of the DolphinViewController positioned at 0,0 in the Dolphin window. I can't reproduce with a minimal test case, though.

Seems embedded widgets are (also) broken in this setup, e.g. System Settings QML stuff or KMail WebEngineView...
Comment 13 Elvis Angelaccio 2017-04-03 21:52:00 UTC
*** Bug 378402 has been marked as a duplicate of this bug. ***
Comment 14 Elvis Angelaccio 2017-04-04 08:47:12 UTC
*** Bug 378155 has been marked as a duplicate of this bug. ***
Comment 15 Sean V Kelley 2017-04-14 16:35:41 UTC
Same issue:

OpenSUSE Tumbleweed
dolphin 16.12.3

Laptop: 4K display
Attached Display: 4K display

Using hidpi scaling factor of 2 in KDE

Only able to open a single file using Dolphin on the Attached Display.  Further attempts to open another file on the Attached Display is blocked.  Only work around, use context menu each time I open a file OR close Dolphin, relaunch Dolphin and open file.

However, on the laptop display when attached or not attached to the external 4K display I can freely open files, multiple.


This is super annoying.

Sean
Comment 16 icie 2017-05-09 06:36:21 UTC
I have met this issue since several months ago. Currently the bug is still reproducible on my desktop.

Spec:
Kubuntu 17.04 with Plasma 5.9.4 and Dolphin 16.12.3-0ubuntu2
Two Dell 4K Monitors
Set QT_SCREEN_SCALE_FACTORS=2

On primary screen the dolphin performs fine, however when opening a file on secondary screen the file area becomes freezed.
Comment 17 Kai Uwe Broulik 2017-05-31 10:11:51 UTC
If you can, please try this patch: https://phabricator.kde.org/D6046
Comment 18 David Faure 2017-06-03 09:55:08 UTC
Git commit e10f44d87270ca6f8e509a99f6df17c8a31fbfa8 by David Faure, on behalf of Kai Uwe Broulik.
Committed on 03/06/2017 at 09:54.
Pushed by dfaure into branch 'master'.

Workaround for QTBUG-59017

CHANGELOG: Addressed an issue where certain elements in applications (e.g. Dolphin's file view) would become inaccessible in high-dpi multi-screen setup
FIXED-IN: 5.35
Differential Revision: https://phabricator.kde.org/D6063

M  +11   -3    src/widgets/krun.cpp

https://commits.kde.org/kio/e10f44d87270ca6f8e509a99f6df17c8a31fbfa8
Comment 19 Brian Mastenbrook 2017-06-23 14:34:08 UTC
If I'm reading the release notes (https://www.kde.org/announcements/kde-frameworks-5.35.0.php) correctly, the fix in #18 is in KDE Frameworks 5.35.0, which is now in Neon User Edition. However, I'm still having trouble with Dolphin. In fact, it's now worse - the dolphin window is unresponsive on the second monitor even without having opened a file via double click.
Comment 20 Kai Uwe Broulik 2017-06-23 14:36:25 UTC
Is that always or only after launching an app?
Comment 21 Brian Mastenbrook 2017-06-23 14:40:07 UTC
I'm not sure I understand the question. For clarity, here's my setup: I'm using a laptop with an internal 4K display and an external 4K monitor, both of which have a scaling factor of 2. The external display is set as primary. When I run dolphin, the default window with my home directory appears on the external display. I can't select any items in the file view or sidebar, though the address bar and toolbar remain responsive. If I drag the window so that it is entirely on the internal display, I can select and open files and directories as usual. However, when I drag the window back to the external display, I can no longer select or open items again.
Comment 22 icie 2017-06-30 02:23:38 UTC
I have ever met Brian's issue when I applied the patch to KDE frameworks<5.35.0 to the packages from Kubuntu-ci. The file area becomes non-clickable when I drag the Dolphin window into the secondary 4k monitor, even before launching any app.

Today I upgraded from the Kubuntu-ci repository where the framework 5.35.0 has already landed, and all the bugs were gone. Thanks very much for the developers' effort.
Comment 23 Mads 2017-07-05 12:10:04 UTC
(In reply to Brian Mastenbrook from comment #21)
> I'm not sure I understand the question. For clarity, here's my setup: I'm
> using a laptop with an internal 4K display and an external 4K monitor, both
> of which have a scaling factor of 2. The external display is set as primary.
> When I run dolphin, the default window with my home directory appears on the
> external display. I can't select any items in the file view or sidebar,
> though the address bar and toolbar remain responsive. If I drag the window
> so that it is entirely on the internal display, I can select and open files
> and directories as usual. However, when I drag the window back to the
> external display, I can no longer select or open items again.

Do you still have this issue?
Comment 24 Brian Mastenbrook 2017-07-05 21:20:40 UTC
(In reply to Mads from comment #23)
> Do you still have this issue?

Yes, I do. I'm running Neon User Edition and just did an apt update / dist-upgrade, and logged out and in again.

Should I file a new bug?
Comment 25 Mads 2017-07-05 23:17:31 UTC
Is the system running with Qt 5.9.1?
Comment 26 Brian Mastenbrook 2017-07-05 23:27:37 UTC
(In reply to Mads from comment #25)
> Is the system running with Qt 5.9.1?

No; as far as I can tell that hasn't rolled out to Neon User Edition yet.
Comment 27 Mads 2017-07-05 23:43:39 UTC
If I understand this correctly, then the patch mentioned here is just a workaround for an underlying qt issue that has been fixed in qt 5.9.1... So you might want to wait until it rolls out or get it installed in a way or another
Comment 28 Mads 2017-07-06 06:57:17 UTC
Hm I did some testing myself now, and I don't get this bug either. On one computer I have Qt 5.7.1 with KDE frameworks 5.35.0 and dolphin 17.04.2 (everything on Gentoo), and I don't see this bug (with 2x 4k monitors). On another computer we first tested with Qt 5.7.1 and then afterwards with Qt 5.9.1, kde-frameworks 5.35.0 and dolphin 17.04.2 (also everything on Gentoo and with 2x 4k monitors), the bug happens everytime, we've yet to manage to click on a icon in dolphin on the external (primary) monitor yet...

The differences between the computers is that one is an XPS15 9550, the other is a XPS15 9560, and the 9560 one has a pretty recently built Gentoo system on it.

Is there a component that needs rebuilding against new Qt other than kio and dolphin that we haven't rebuilt?
Comment 29 Mads 2017-07-06 07:13:34 UTC
Sorry for spamming the bug report, but I did some more testing - there was a difference between the computers, because one screen ran with QT_SCREEN_SCALE_FACTORS 1 on the non-primary monitor and 2 on the external/primary, and the other (the one showing the bug) ran with QT_SCREEN_SCALE_FACTORS 2 on both monitors. When I changed to 2 on both monitors, I see the bug on both systems.

So the bug is still there with Qt 5.7.1/5.9.1 and kde frameworks 5.35.0 (again, if anything needs rebuilding after upgrading from Qt 5.7.1 to 5.9.1 outside of kio and dolphin, then please do tell..)

we use the modesetting driver for X if it's relevant.
Comment 30 Kai Uwe Broulik 2017-07-06 14:09:11 UTC
I just tried with Qt 5.9.1 and now the file area is completely inaccessible on second monitor, not just after launching a file. Meh.
Comment 31 Elvis Angelaccio 2017-08-12 07:55:20 UTC
*** Bug 383248 has been marked as a duplicate of this bug. ***
Comment 32 Mads 2017-09-04 06:54:24 UTC
kscreen sets the QT_SCREEN_SCALE_FACTORS to "QT_SCREEN_SCALE_FACTORS=eDP-1-1=2;DP-1-1=2;HDMI-1-1=2;DP-1-2=2;HDMI-1-2=2;" on my computer when I have chosen 2 as scaling value. eDP-1 is connected, and DP-1-2 is connected. xrandr also reports that I have the connections DP-1, HDMI-1, DP-2, HDMI-2, DP-1-1, but all of them are disconnected.

So, that QT_SCREEN_SCALE_FACTORS mentions some ports that might have existed some time, but for the time being is not there (e.g. HDMI-1-1 and HDMI-1-2). Might this be the actual issue? Because if I run dolphin with QT_SCREEN_SCALE_FACTORS="2;2", things seems to just work... (Qt 5.9.1, kde frameworks 5.37.0, plasma 5.10.5)
Comment 33 Mads 2017-09-07 10:33:25 UTC
To clarify: dolphin does not appear to have this unclickable file area issue anymore if using:
- kde-frameworks 5.37
- dolphin 17.08.0
- plasma 5.10.0
- Qt 5.9.1
- modesetting ddx
- QT_SCREEN_SCALE_FACTORS="2;2"

There might still be an issue at play, but that might belong to another bugreport (scaling variable set for non-existing outputs (or vice versa) leads to high cpu usage on plasmashell process and erroneous scaling on outputs that are actually connected)
Comment 34 Wim Delvaux 2017-09-07 10:51:15 UTC
and also not if you use context menues to start programs.  It only happens to me if I click directly no a file and then only for certain programs.  E.g. dragon player seems to work, vlc does not
Comment 35 Kai Uwe Broulik 2017-09-07 11:11:28 UTC
@Mads So the issue still persists with KDE Frameworks 5.37 in your normal setup (ie. when you don't set it to 2;2 manually)?
Comment 36 Mads 2017-09-07 11:53:21 UTC
Oh, I managed to not be clear on that, sorry!

No, I can't reproduce the no-clickable issue at all anymore. So for me, this bug is resolved.
Comment 37 Elvis Angelaccio 2017-09-26 18:16:20 UTC
*** Bug 385102 has been marked as a duplicate of this bug. ***
Comment 38 Bobby 2019-10-07 22:18:05 UTC
Unfortunately I'm still getting this bug on:

Operating System: Fedora 30
KDE Plasma Version: 5.15.5
KDE Frameworks Version: 5.59.0
Qt Version: 5.12.4
Kernel Version: 5.2.17-200.fc30.x86_64
OS Type: 64-bit
Processors: 8 × Intel® Core™ i7-8650U CPU @ 1.90GHz
Memory: 15.4 GiB of RAM

With QT_SCREEN_SCALE_FACORS:

QT_SCREEN_SCALE_FACTORS="eDP-1=1.5;DP-1=1.5;HDMI-1=1.5;DP-2=1.5;HDMI-2=1.5;"