Bug 1251

Summary:	Channel configuration popup should not be system-modal
Product:	PulseView	Reporter:	whitequark <whitequark>
Component:	UI	Assignee:	Nobody <nobody>
Status:	CONFIRMED ---
Severity:	major	CC:	soeren
Priority:	Normal
Version:	unreleased development snapshot
Target Milestone:	---
Hardware:	All
OS:	All

Description whitequark 2018-07-23 02:49:29 CEST

Currently, opening a channel configuration popup by clicking on a channel name captures input to the entire X server. In case pulseview hangs, either because it has a bug or, more importantly, because a protocol decoder is being slow, this prevents any actions that can kill pulseview, short of switching to a different VT and logging in.

This is not only highly annoying, but also makes it near impossible to capture stacktraces for pulseview hangs, because while gdb may be attached while in a different VT, you cannot easily copy the stacktrace from a VT and paste it in a browser, and looking up how to do it on the web (the only case when I ever needed to do that is when debugging a pulseview crash) is not possible because the X server is locked by pulseview.

Pulseview should not use system-modal popups. There is no legitimate reason for an application like pulseview to use system-modal popups, and it is disruptive, as shown above.

To the argument that pulseview hangs are just bugs that need to be fixed, I say the following. First, if you are confident that pulseview will never hang again, and can prove this, I'm fine with re-enabling this behavior. Second, how are hangs going to be fixed in the first place when I can't even submit stack traces for hangs because of this issue?

Comment 1 whitequark 2018-07-23 02:50:16 CEST

I'm setting severity to "major" because this directly prevents me from submitting proper reports for pulseview bugs that result in hangs.

Comment 2 Soeren Apel 2018-07-26 07:50:05 CEST

Sounds like a window manager issue to me. PV doesn't (and as a matter of fact, can't) create system-modal windows.

Comment 3 whitequark 2018-07-26 07:52:24 CEST

Sure it can. What it does is captures input system-wide, which, while technically does not make a system-modal window, has the same user-visible impact. The Qt function that does this is called QWidget::grabKeyboard()/QWidget::grabMouse(), I believe; not sure what it does on X11 level.

Comment 4 whitequark 2018-07-26 07:53:51 CEST

The Qt documentation even has the following note:

  Warning: Bugs in mouse-grabbing applications very often lock the terminal. Use this function with extreme caution, and consider using the -nograb command line option while debugging.

I haven't realized that there is a workaround (namely -nograb), which could be useful when capturing a backtrace (well, not if you have an intermittent bug without a good repro, but at least it's something).

Comment 5 Soeren Apel 2018-07-26 08:17:18 CEST

Interesting, I wasn't aware of those calls. However, PV doesn't use them.
So either it's used implicitly through some Qt API or it's not used at all.

I'm not saying that there is no issue for you, I'm just saying that I have no clue where to look and you're the first to perceive this behavior - meaning that I'm not sure PV is at fault here.

Comment 6 whitequark 2018-07-26 08:26:28 CEST

Yes, I think this might be actually a Qt issue. I think it's caused by code in QQuickOverlay::handlePress; here, maybe: https://github.com/qt/qtquickcontrols2/blob/4e11d09fdef369af130c86a81df599ee3273ac7d/src/quicktemplates2/qquickoverlay.cpp#L134. It mentions "modal popups", is there any chance PV can tell Qt to make the popup non-modal? Otherwise you'd have to override this behavior manually.

Comment 7 Soeren Apel 2018-08-15 22:56:37 CEST

PV doesn't (yet) use QtQuick2, though, so the code you linked to doesn't apply.

Again, PV doesn't knowingly use anything system-modal, so it's hard to say what's going on here. It certainly is possible that something within Qt is using/creating system-modal widgets but I don't know of any such thing at the moment.