Any chance of a bisect?  Shouldn't need to bisect anything more than tqt3, tdelibs, and tdebase.  A lot of changes have gone in in the past 14 days, and many from people other than me, so I have no idea which patch could have done this. :-)

It does smell like a focus update issue at first glance, but the bisect will help determine if any changes to TQt3 caused it.

Thanks!

>Any chance of a bisect?
I am in the process of isolating the introduction. I have not updated my office system since August 25 and does not have the bug. My laptop is the only system I have updated TDE with the many recent patches. Thus, until I know more later today all I know is the bug was introduced after Aug. 25.

Not a strict focus issue. When returning to Konsole I have to move the cursor to restore the solid block. Mere returning focus to Konsole does not restore the cursor.

(In reply to Darrell from comment #2)
> >Any chance of a bisect?
> I am in the process of isolating the introduction. I have not updated my
> office system since August 25 and does not have the bug. My laptop is the
> only system I have updated TDE with the many recent patches. Thus, until I
> know more later today all I know is the bug was introduced after Aug. 25.

OK, sounds good.  Thanks!

Restoring tqt3, tdelibs, tdebase from Aug. 25 results in a solid cursor (no bug). I have only two package sets since Aug. 25. Superficially, looks like the bug is in tdebase. I can use tqt3 and tdelibs from my most recent package set but need to use the Aug. 25 tdebase to avoid the bug. Using tdebase from the two recent package sets results in the bug.

The package set I built after Aug. 25 is dated Sep. 29. Not a true bisect but that seems to reduce the possibilities to tdebase between Aug. 25 and Sep. 29.

As we have seen several times in the past, that time frame does not necessarily mean the bug was introduced with a recent patch in tdebase, but a recent patch in tqt3, tdelibs, or tdebase could have unmasked a long-time latent bug in tdebase. I mention that tidbit because I do not see anything obvious in the tdebase commits between Aug. 25 and Sep. 30.

The cursor can somewhat self-heal when blinking is enabled, similar to moving the cursor.

* Open Konsole.
* Enable blinking.
* Open a new app.
* Return to Konsole.
* Momentarily the cursor will be an outline and then with the first blink restore to solid.

Can you help confirm the bug is in TQt3 by building TQt3 from the sources available on Aug. 25 while keeping the rest of TDE on the latest GIT sources?  You should not have to rebuild anything other than TQt3 for this test; if the bug is truly in TQt3 then the regression should disappear.

Thanks!

I already did that, as mentioned in comment 5. I tested tqt3, tdelibs, tdebase from Aug. and my most recent package set. I mixed the three packages in various combinations. Using the recent package set and tqt3 from Aug. results in no change in the bug. The problem seems to be in tdebase. That is, I can use my most recent tqt3 and tdelibs but I need to revert to the Aug. tdebase to retain a solid block cursor. On the surface seems the bug was introduced into tdebase between Aug. 25 and Sep. 29.

(In reply to Darrell from comment #8)
> I already did that, as mentioned in comment 5. I tested tqt3, tdelibs,
> tdebase from Aug. and my most recent package set. I mixed the three packages
> in various combinations. Using the recent package set and tqt3 from Aug.
> results in no change in the bug. The problem seems to be in tdebase. That
> is, I can use my most recent tqt3 and tdelibs but I need to revert to the
> Aug. tdebase to retain a solid block cursor. On the surface seems the bug
> was introduced into tdebase between Aug. 25 and Sep. 29.

Sorry, must have missed that.  Been processing an awful lot of reports lately. :-)

Any chance of bisecting tdebase then while holding tqt3 and tdelibs constant?

Thanks!

>Any chance of bisecting tdebase then while holding tqt3 and tdelibs constant?
Other than package sets, I don't know how to do that.

My first package set after Aug. 25 was Sept. 29. Testing the Sept. package sets results in the bug. Thus. from my package sets all I know is the bug appeared between approximately Aug. 25 and Sept. 29.

I don't see any tdebase commits during that period that seem related to the bug.

Here is what I get when I attempt a git bisect between the two dates:

git bisect start
git bisect good dff276fb
git bisect bad aa71cdc5

Bisecting: 16 revisions left to test after this (roughly 4 steps)
[efdf0bbcd37d5aaa05649437b286aeecfd38c617] Improved code for workaround for Qt/Tde/X? bug for handling Meta key as Alt key in terminal emulation after restored sessions. This relates to bug 1026.

That commit is from May and not between Aug. 25 and Sept. 29. I do not pretend to understand the git bisect process.

I don't pretend to understand the bisect thing, but reversing commit efdf0bbc 2014-05-16 and rebuilding tdebase eliminates the artifact. I rebuilt all core modules from tqt3 to tdebase and installed those packages. The cursor stays solid when toggling repeatedly between konsole and other apps.

Although I accept commit efdf0bbc might be the culprit, I would like to learn what happened between Aug. 25 and Sept. 29 that somehow unmasked or exposed a flaw in commit efdf0bbc. I am inclined to think a tqt3 commit during that period exposed a problem with the commit?

(In reply to Darrell from comment #11)
> I don't pretend to understand the bisect thing, but reversing commit
> efdf0bbc 2014-05-16 and rebuilding tdebase eliminates the artifact. I
> rebuilt all core modules from tqt3 to tdebase and installed those packages.
> The cursor stays solid when toggling repeatedly between konsole and other
> apps.

Thanks a bunch for tracking that down!

> Although I accept commit efdf0bbc might be the culprit, I would like to
> learn what happened between Aug. 25 and Sept. 29 that somehow unmasked or
> exposed a flaw in commit efdf0bbc. I am inclined to think a tqt3 commit
> during that period exposed a problem with the commit?

I don't think we need to look outside tdebase.  For instance, in the original efdf0bbc commit (https://git.trinitydesktop.org/cgit/tdebase/commit/?id=efdf0bbcd37d5aaa05649437b286aeecfd38c617) I see that the focus in hander was modified.  Then I see a major rework of Konsole's VT hander in a commit Sept. 15 (https://git.trinitydesktop.org/cgit/tdebase/commit/?id=3e7f4492e641b36751e356dcefb059be4bc823cb), which is exactly in the time period you specify and could very easily have interacted badly with the focus handler modification.

Let me look a bit further...

This should be fixed in GIT hash d8d566b.  The author of commit efdf0bbc has aberrantly returned from the event handler (easy to do as all the other event handler traps returned from the handler), blocking the focusInEvent call and preventing cursor redraw.

There is now a note in the source so that this won't be reintroduced at a later date. :-)

Thanks for reporting, and for tracking down the faulty commit!

*** Bug 2120 has been marked as a duplicate of this bug. ***

Looks good here. Thanks.