Key press (arrow keys) cause loss of focus

[Axel Spoerl]

@Perdrix
Do I understand this right, your colums are

• time
• event class
• event type
• class of the event receiver
• (don't understand what the last column is).

What looks odd at first glance, is QFusionStyle consuming QEvent::FocusIn.
OTOH the table view seems to get the focus event, but for some reason it's propagated to the fusion style immediately.

To isolate the problem:

• which Qt version are we talking about?
• on which OS is this happening?
• is it OS specific at all?
• could you please add the output of QApplication::focusWidget() and yourTableView->focusWidget() to each line of the debugging output?
• how exactly is the dock widget being undocked? setFloating(true), or dragged out of the main dock? If the latter: Was it tabbed or not?
• what happens, if you hover the undocked dock widget (the one containing the table view) over another floating dock widget?

[Perdrix]

@Axel-Spoerl Hi Axel, Happy Christmas to you.

This is Qt 6.6.1, but also happens on 6.5.1

The last column (details column) contains interesting stuff to do with the event:

e.g. for a Focus Event it is filled as follows:

        switch (focusEvent->reason())
        {
        case Qt::MouseFocusReason:
            details += "Mouse action";
            break;
        case Qt::TabFocusReason:
            details += "Tab pressed";
            break;
        case Qt::BacktabFocusReason:
            details += "Backtab pressed";
            break;
        case Qt::ActiveWindowFocusReason:
            details += "Window System";
            break;
        case Qt::PopupFocusReason:
            details += "Popup";
            break;
        case Qt::ShortcutFocusReason:
            details += "Buddy shortcut";
            break;
        case Qt::MenuBarFocusReason:
            details += "Menu bar";
            break;
        case Qt::OtherFocusReason:
            details += "Other";
            break;
        }

This is all on Windows (11). I've not yet finished making the code portable.

I added this after the switch statement shown above:

       //
               // Add the value of QApplication::focusWidget()
               //
               QObject* object{ nullptr };
               object = QApplication::focusWidget();
               if (nullptr != object)
               {
                   className = object->metaObject()->className();
                   if (!this->widgetPointerToID.contains(className) || !this->widgetPointerToID[className].contains(object))
                   {
                       this->widgetPointerToID[className][object] = this->widgetPointerToID[className].size();
                   }
                   id = this->widgetPointerToID[className][object];
                   className += " " + QString::number(id);
                   details += ";" + className;
               }
               else details += ";nullptr";
        
               //
               // Add the value of tableView->focusWidget
               //
               object = this->tableView->focusWidget();
               if (nullptr != object)
               {
                   className = object->metaObject()->className();
                   if (!this->widgetPointerToID.contains(className) || !this->widgetPointerToID[className].contains(object))
                   {
                       this->widgetPointerToID[className][object] = this->widgetPointerToID[className].size();
                   }
                   id = this->widgetPointerToID[className][object];
                   className += " " + QString::number(id);
                   details += ";" + className;
               }
               else details += ";nullptr";        

The dock window was manually undocked by double-clicking its title bar. It isn't a tabbed dock widget.

Nothing much happens when I move that undocked dock widget over another undocked dock widget it just sits above it in Z-Order.

And finally we get the linked file (below) converted from a csv to an xls file.

http://www.perdrix.co.uk/DSSEvents%202023-12-26T16-56-55.xls

[Perdrix]

@Axel-Spoerl For further information this is what the code I use does as the image starts to load and on completion. All the controls referenced here are in the "central widget" the main window, not the dock widget.

Starting to load:

//
// Display the "Loading filename" with red background gradient while loading in background
//
ui->information->setStyleSheet(
	"QLabel { background: qlineargradient(spread:pad, x1:0, y1:0, x2:1, y2:0,"
	"stop:0 rgba(252, 251, 222, 0), stop:1 rgba(255, 151, 154, 255)) }");
ui->information->setText(tr("Loading %1", "IDS_LOADPICTURE")
	.arg(fileName));
//
// No longer interested in signals from the imageView object
//
ui->picture->disconnect(editStars, nullptr);
ui->picture->disconnect(selectRect, nullptr);

pToolBar->setVisible(false); pToolBar->setEnabled(false);
editStars->setBitmap(nullptr);

When the image completes loading:

//
// The image we want is available in the cache
//
m_LoadedImage.m_Image = pImage;
m_LoadedImage.m_pBitmap = pBitmap;
if (m_GammaTransformation.isInitialized())
    ApplyGammaTransformation(m_LoadedImage.m_Image.get(), m_LoadedImage.m_pBitmap.get(), m_GammaTransformation);
ui->picture->setPixmap(QPixmap::fromImage(*(m_LoadedImage.m_Image)));

if (frameList.isLightFrame(fileToShow))
{
	editStars->setLightFrame(fileName);
	editStars->setBitmap(pBitmap);
	if (pToolBar->rectAction->isChecked())
	{
		editStars->rectButtonPressed();
		selectRect->rectButtonPressed();
	}
	else if (pToolBar->starsAction->isChecked())
	{
		editStars->starsButtonPressed();
		selectRect->starsButtonPressed();
	}
	else if (pToolBar->cometAction->isChecked())
	{
		editStars->cometButtonPressed();
		selectRect->cometButtonPressed();
	}
	pToolBar->setVisible(true); pToolBar->setEnabled(true);
}
else
{
	pToolBar->setVisible(false); pToolBar->setEnabled(false);
	editStars->setBitmap(nullptr);
};

CBilinearParameters		Transformation;
VOTINGPAIRVECTOR		vVotedPairs;
if (frameList.getTransformation(fileName, Transformation, vVotedPairs))
					editStars->setTransformation(Transformation, vVotedPairs);
ui->information->setStyleSheet(
    "QLabel { background: qlineargradient(spread:pad, x1:0, y1:0, x2:1, y2:0,"
    "stop:0 rgba(138, 185, 242, 0), stop:1 rgba(138, 185, 242, 255)) }");
ui->information->setText(fileName);

The loss of focus on the table view happens just after the code for completion of loading is finished (IOW the table view retains focus and selection until just after loading has finished).

[Axel Spoerl]

Hi @Perdrix,
happy Christmas to you to and all the best for upcoming 2024!

Sorry for asking the dock widget stuff. My initial thought was that you are suffering from a long standing bug, where a manually undocked dock widget may end up wrapped in an invisible QDockWidgetGroupWindow. Besides crashing when hovered over another floating dock, it is well known for mangling the focus chain. But that doesn't seem to be the case here. Just btw, this (and a whole bunch of other fixes) make dock widgets pretty stable from 6.5 onward.

I can't figure anything fishy in the code.

I downloaded and inspected the Excel file. Thanks for the explanations thereof. However, it doesn't seem to contain qDebug() << QApplication::focusWidget(); and qDebug() << targetWidget::focusWidget(). Would be great if you could add those into the diagnostic output. The former will tell us, when the table view has lost focus. The latter will tell us, if a focus or a broken chain has gotten in our way.

Cheers
Axel

[Perdrix]

@Axel-Spoerl said in Key press (arrow keys) cause loss of focus:

I downloaded and inspected the Excel file. Thanks for the explanations thereof. However, it doesn't seem to contain qDebug() << QApplication::focusWidget(); and qDebug() << targetWidget::focusWidget(). Would be great if you could add those into the diagnostic output. The former will tell us, when the table view has lost focus. The latter will tell us, if a focus or a broken chain has gotten in our way.

I'm puzzled too , the focus change events all have a details section containing the reason for the focus change, then the class name QApplication::focusWidget() and then class name of myTableView->focusWidget():

e.g.: Window System;QScrollArea 0;QTableView 0

I've modified the code to use a QDebug object to display the object pointer returned by focusWidget() calls.

The updated xls file is here:

www.perdrix.co.uk/DSSEvents%202023-12-28T15-41-51.xlsx

David

[Axel Spoerl]

@Perdrix
Hi David,

hm, that looks like the table view consumes a straight forward QEvent::FocusOut. That must originate from somewhere.
To figure that out, I'd set a break point on the focus out event handler and look at the call stack. Someone is stealing focus here. Much grief is caused by focus thieves.

Cheers
Axel

[Perdrix]

@Axel-Spoerl QT version 6.6.1: Here's the call stack at the time the event filter receives that FocusOut event:

It's not at all clear to me why it is doing that.

If there's information you need me to dig out from that call stack please let me know.

David

[Axel Spoerl]

@Perdrix
Hi David,

the gui event dispatcher sends posted events, which makes it forward window system events. The first of those causes a focus change. It doesn't result from the application's main thread, because we don't see any postEvent()in the call stack. AFAIK, that can have two possible reasons:

• The window manager decides, that another application gets focus. It can be anything from the debugger to a system popup or a logging window receiving output to display.
• The focus widget disappears (it gets hidden or destroyed) and the focus chain is broken, which is why the next focus widget can't be established.

It would be helpful to know the values of QWidget * focus, Qt::FocusReason reasonin Line 1539 - 6 lines down from the break point. The widget will probably be nullptr, because that's where we end up. The focus reason will not tell us what exactly is going on, but it will tell us why the focus was changed.

[Perdrix]

@Axel-Spoerl I put this in my Event Logging code:

    case QEvent::FocusOut:
        inputType = FOCUS;
        eventType = "FocusOut";
        if (tableView == obj) __debugbreak();
        break;

When the breakpoint is hit I think the relevant part of the call stack is:

where the focus change is being driven from QGuiApplicationPrivate::processActivatedEvent() at line 2562. At that point in the code, newFocus is a null pointer and previousFocusObject -> my table view object.

So why is the code forcing a focus change?

David

[Axel Spoerl]

@Perdrix
That baffles me. Can you step into Qt code?
Or isolate the issue in a minimal reproducer?

[Perdrix]

@Axel-Spoerl I can step into and put breakpoints into the Qt code.

Please tell me where you want the breakpoints and what information you need

[Axel Spoerl]

@Perdrix
If you can compile Qt, throw a qDebug() << __FUNCTION__ << typeinto the c'tor of QFocusEvent (qevent.cpp:1562).
Set a break point there and continue, unless it's a QEvent::FocusOut. If it's the FocusOut, that eventually steals focus, the call stack will tell who it is.

[Perdrix]

@Axel-Spoerl :

The reason in the focus event is 3 (Qt::ActiveWindowFocusReason).

This was invoked indirectly from line 1940 in QApplicationPrivate::notifyActiveWindowChange()

David

[Axel Spoerl]

@Perdrix said in Key press (arrow keys) cause loss of focus:

The reason in the focus event is 3 (Qt::ActiveWindowFocusReason).

That's interesting. What's the QWidget *focus argument pointing to?
Shouldn't be nullptr with ActiveWindowFocusReason...

[Perdrix]

@Axel-Spoerl It's pointing to a QScrollArea object (which could be the scroll area in the other dock widget)

[Axel Spoerl]

@Perdrix
Getting more and more interesting.
Could you assign a QObject::objectName()to the suspicious scroll area? That will become visible in the debugger, so you can easily identify which one it is. Looks like the arrow key event gets delivered to another dock widget, which then consumes the event in an attempt to scroll. Eventually it gets focus as a stray bullet.

[Perdrix]

@Axel-Spoerl The variable focusWidget set at line 1937 in QApplicationPrivate::notifyActiveWindowChange() points to the QMainWindow derived class for the application. The code then calls setActiveWindow() for that.

By the time this all gets to the actual Event Filter code the object to which focus is being given is the scroll area that belongs to the "other" dock widget.

I can recreate the problem without use of arrow keys - just clicking on a row in the table view selects it and starts the loading of the image. Just after the loading of the image completes, the focus is lost. The code that executes in my application on completion of loading the image was posted earlier in this thread.

[Perdrix]

@Axel-Spoerl I found the problem!!!

The code that was called on completion of loading of the image contained the following:

if (pToolBar->rectAction->isChecked())
{
	editStars->rectButtonPressed();
	selectRect->rectButtonPressed();
}
else if (pToolBar->starsAction->isChecked())
{
	editStars->starsButtonPressed();
	selectRect->starsButtonPressed();
}
else if (pToolBar->cometAction->isChecked())
{
	editStars->cometButtonPressed();
	selectRect->cometButtonPressed();
}

each of the xxxxButtonPressed() member functions called activateWindow(); which in the end resulted in the table view losing focus. I removed the activateWindow(); calls and now it works as it should.

Thank you so much for your help - without it I would probably still be struggling with this for many weeks to come.

[Axel Spoerl]

@Perdrix
Hi David,
glad that the issue is resolved!
Thanks for letting me know - was a pleasure.
Cheers
Axel