if (!lineEditorWidget->isModified())
        return; // Ignore second signal.
    lineEditorWidget->setModified(false);
    // Do something with the text. 

i.e. you must clear the flag before doing something (which will invoke a dialog or similar) to prevent second, re-entrant call of editingFinished.

• I see this bug was actually first reported in 2005. Is this 14-years-to-fix a record for a Qt bug? :)

• In the bug report link there is a workaround posted by a poster. I would like to implement this, as there is no chance of moving to a newer Qt version (I only use whatever Qt was released with the Linux version I use, so probably not until Ubuntu 20.04). It reads as follows:

I had to work around this bug once again today (Qt 5.6.1).
.
QLineEdit has a isModified interface. You can set this to true when editingFinished is emitted the first time and ignore the signal if and when it is emitted the second time.
.
You can also use this to ignore editingFinished if the text hasn't actually changed (i.e. the QLineEdit simply lost focus).
.
This is my slot/lambda:

connect(
 lineEditorWidget,
 &QLineEdit::editingFinished,
 this,
[this, lineEditorWidget]()
{ if (!lineEditorWidget->isModified()) return; // Ignore second signal. lineEditorWidget->setModified(false); // Do something with the text. } 
);

Reading what he has written I am trying to confirm what his code really means to implement. Given the layout of his commented lines, do I presume this is intended to read as follows:

{
    if (!lineEditorWidget->isModified())
        return; // Ignore second signal.
    // Do something with the text. 
    lineEditorWidget->setModified(false);
}

Thus we only setModified(false) after we have finished our slot code? If editingFinished is re-raised (by something) whilst we are inside the slot doing something with the text, we would execute our code again? As I typed this, I'm thinking he does genuinely mean

    lineEditorWidget->setModified(false);
    // Do something with the text. 

which is different (you do the math): it ignores editingFinished being called a second time while inside the first editingFinished, it's a "only do this once per modification, regardless of when editingFinished is called"?

He also says:

You can set this to true when editingFinished is emitted the first time

but the code does not do that, does he mean the Qt framework is doing this, not us? https://doc.qt.io/qt-5/qlineedit.html#modified-prop :

The modified flag is never read by QLineEdit; it has a default value of false and is changed to true whenever the user changes the line edit's contents.

The issue has been fixed for Qt 5.14.

As for the assignment, look at the history ;-)

It might be QTBUG-40.

Looks like similar wording. And look who's been assigned to fix it! :) But it's been there since 2010 (the 40th bug ever found), surely it would have been fixed by now? :)

However, note my findings/example code --- in my case I am claiming this only happens if the Return key is pressed to cause the QLineEdit::editingFinished, I don't know if that's relevant or a special case? (Oh actually I think that's what the example in the 17 Jan '19 post says.)

A workaround (depending on your use case) is to use returnPressed() signal instead.

It's deliberately editingFinished because the user might tab out, or click elsewhere, or.... Funnily enough, in the current case the user may well have used a QCompleter to populate the line edit and finish editing, so again he doesn't have to press Return. I just promised my stakeholders that these line edits would respond correctly to not pressing Return to finish editing!

For now I've put in a "prevent-re-entrancy" flag on my editingFinished while the dialog is displayed to avoid bad behaviour, but I was hoping for a "nicer hack"? :)

It might be QTBUG-40.

Help/fix/workaround, please? :)

I've encountered the same thing today :-) SOunds like a bug to me, but I have not checked the bugtracker for it yet.

A workaround (depending on your use case) is to use returnPressed() signal instead.