bugGNU Octave - Bugs: bug #57635, Editor often has focus but no...


bug #57635: Editor often has focus but no cursor until clicking elsewhere and then clicking in editor

Submitted by:  Philip Nienhuis <philipnienhuis>
Submitted on:  Sun 19 Jan 2020 02:28:01 PM UTC  
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error
Status:  Fixed Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  Closed
Release:  dev Operating System:  Any

Add a New Comment (Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( Jump to the original submission)

Wed 27 May 2020 07:22:09 AM UTC, comment #101: 

Thanks for your perseverence in fixing this bug, that at first was quite an elusive one.

The only observation that's still at play is the 2nd one in my original report (after "Perhaps related") which also looks like some sort of focus issue but then on the cascading file popup.
As I see that in Octave-5.2.0 as well I no longer think it is related to the underlying issues fixed here.

Philip Nienhuis <philipnienhuis>
Project Member
Wed 27 May 2020 05:25:50 AM UTC, comment #100: 

I have pushed the patch with changeset http://hg.savannah.gnu.org/hgweb/octave/rev/2b52e473b6ef

Closing the report, we can reopen it in case other related issues are showing up.

Torsten Lilge <ttl>
Project Member
Mon 25 May 2020 10:27:55 PM UTC, comment #99: 

Good news. I also haven't found any problems when tabs are closed or when the autocompletion-popups appear (Linux). Manipulations on the tab, such as sorting, moving or clicking into, look also to be ok.

From my side v04 is fine. A fix that took a lot of hard work from everybody.

Hg200 <hg200>
Sun 24 May 2020 08:28:35 PM UTC, comment #98: 

With the patch of comment #96 the problems seem to be fixed on my Windows PC.
After closing a tab the cursor is back immediately on another tab that gets focus, and the cursor is usable.
Also the autocompletion list popup reacts to the Esc key (before this fix I had to double-click the highlighted word to get rid of it, that was he only "way out" of this popup).

I'll leave it to Hg200 to further scrutinize the new behavior.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 24 May 2020 07:29:56 AM UTC, comment #97: 

Fedora is already hit by the problem. For mxe-octave we have a solution. Whether other major distributions like Ubuntu or Debian will also be affected depends on whether QTBUG-83720 will be fixed in Qt 5.13.x / 5.14.x. If not, the problem will suddenly appear, and it will disappear just as suddenly as soon the distribution updates to Qt >= 5.15.1. However, this period can take some time. I feel like Philip. But in the end, it is a decision whether we want to take the risk that the problem also occurs in Linux distributions other than Fedora, or whether we live with a workaround.

A first test of patch v04 looks promising ;-) But I want to take a little more time for testing because it's convoluted.

Hg200 <hg200>
Sat 23 May 2020 09:13:01 PM UTC, comment #96: 

Attached, patch version 4. I think it is converging now. 

(file #49156)

Torsten Lilge <ttl>
Project Member
Sat 23 May 2020 08:53:51 PM UTC, comment #95: 

It is also stable that is affected when using Qt 5.13 or 5.14. I am currently finishing patch version 4, which now seems to fix all issues.

Torsten Lilge <ttl>
Project Member
Sat 23 May 2020 08:33:23 PM UTC, comment #94: 

For mxe-octave builds that Qt patch can be added to the other Qt fixes (there are several Qt fixes in mxe-octave). Looks much simpler than introducing workarounds as I suggested in comment #54.
Time to notify JohnD (main mxe-octave dev)?

But admittedly for Linux this wouldn't help. Is only dev-octave affected or stable as well?

Philip Nienhuis <philipnienhuis>
Project Member
Fri 22 May 2020 10:23:05 PM UTC, comment #93: 



they have now announced Qt 5.15.1 as fix version. However, the patch is already available on the head of the Qt repository. It fixes void QWidget::setFocusProxy(QWidget * w). Because 5.15.1 is  far in the future, I have merged the patch into the faulty version 5.13.2. Then built Qt and then built Octave against the patched 5.13.2.

Result: All errors have disappeared (closing tab problem and the autocompletion trouble).

My conclusion is that open source is harder than commercial software. In commercial software, you can decide which library version is statically linked and delivered with the executable.

Hg200 <hg200>
Fri 22 May 2020 08:41:27 PM UTC, comment #92: 

Yes, really weird. I have to look for something else for really, i.e., in all cases, cancelling the completion list after an ESC.

Torsten Lilge <ttl>
Project Member
Fri 22 May 2020 08:10:34 PM UTC, comment #91: 

Oh man. "cam<ESC>" is fine. I am crying.

Hg200 <hg200>
Fri 22 May 2020 07:58:55 PM UTC, comment #90: 

I can confirm your result with curl. There still seems to be a problem when there only is one entry in the list. Could you please try something with more than one entry in the list? This seems to work.

Regarding ESC and auto hiding: These are really two different ways since auto hiding does not trigger a signal and has to be detected "manually".

Torsten Lilge <ttl>
Project Member
Fri 22 May 2020 07:34:20 PM UTC, comment #89: 

Hi Torsten,

thanks for the update. Sorry ;-( bad news first: What is not working is when i cancel the autocompletion with the "ESC" key. For example, type "cur<ESC>" and then Ctrl-s. The curious thing is that file_editor::handle_autoc_cancelled is entered, the popup disappears but the Ctrl-key still doesn't work.
But i don't understand: Because in principle, the concept seems to be ok. For example if i write "curls" and then press ctrl-s the file is saved. What's the difference?

The good news is that closing a tab seems to transfer focus correctly ;-)

I plan to do a more detailed code review of the proxy chain maybe tomorrow and will then most likely come back with a bunch of questions.

Best regards Markus

Hg200 <hg200>
Fri 22 May 2020 06:27:54 PM UTC, comment #88: 

I have really forgotten to include the changes for fixing the issues where the auto completion list is not involved. The attached patch v03 now includes this and should also handle the case where the auto completion list is automatically hidden when the entered character is not matching anymore.

(file #49146)

Torsten Lilge <ttl>
Project Member
Mon 18 May 2020 08:26:40 PM UTC, comment #87: 

>> Are other focus issues (e.g. when closing a file) fixed?

No, because this problem is caused by the damaged proxy chain which is set up in file-editor-tab.cc and file-editor.cc. If you run the Qt demo code that I have attached to this bug report: This code demonstrates the tab closing problem, without autocompletion and without using scintilla. The example jams Qt with a simple QTabWidget and a proxy chain as it is used in the Octave GUI. This is really sad.

The problem is solved for me by removing setFocusProxy in file-editor-tab.cc but if i recall correctly there were problems on windows as mentioned in comment #46.

Hg200 <hg200>
Mon 18 May 2020 08:08:05 PM UTC, comment #86: 

Argh, I forgot the auto-hide feature when there are no matches anymore.

Are other focus issues (e.g. when closing a file) fixed?

Torsten Lilge <ttl>
Project Member
Mon 18 May 2020 07:41:17 PM UTC, comment #85: 

Yeah - It does not solve all cases. Prerequisite is an empty editor. Then type

--> Popup disappears and ctrl-s cmd saves the file (ok)

--> Popup disappears and ctrl-s cmd saves the file (ok)

--> Popup disappears when pressing "s" and after this ctrl-s cmd fails to save the file (not ok)

Hg200 <hg200>
Mon 18 May 2020 06:49:46 PM UTC, comment #84: 

Next patch, see attached file, which has to be applied instead of the first patch. When an autocompletion list is cancelled it can still accepted, which partly solves the issue. Of course, any inserted text has to be made undone.

(file #49116)

Torsten Lilge <ttl>
Project Member
Sun 17 May 2020 04:26:57 PM UTC, comment #83: 

You hit it, I can confirm this with the main window minimized. The conclusion is that the main window must get the focus when the editor window is hidden. I have not yet found what fixes the shortcuts during the change of focus between editor and main window. The only solution will be to trigger this pro grammatically. 

Torsten Lilge <ttl>
Project Member
Sun 17 May 2020 03:41:48 PM UTC, comment #82: 

The idea is very good, but it doesn't work reliably: It's hard to describe, but if the editor is undocked and is in the foreground and the GUI is in the background, it actually works. If I only have the editor without any GUI window in the background it doesn't work.

Can you try to minimize all windows (especially the Octave GUI), except the undocked editor window, and then check again?

Hg200 <hg200>
Sun 17 May 2020 02:47:35 PM UTC, comment #81: 

That's really weird, it does on my system, with both, Qt 5.11.3 and 5.13.2.

Torsten Lilge <ttl>
Project Member
Sun 17 May 2020 02:02:03 PM UTC, comment #80: 

If I undock the window (i.e. it's a separate window), I can barely see the flickr, but it's there. However, the command ctrl-s (save) still does not work after I cancel the autocompletion dialog by pressing the ESC key.

So my conclusion is that hiding / activation does not restore the ctrl-xyz keys.

Hg200 <hg200>
Sun 17 May 2020 12:58:43 PM UTC, comment #79: 

so the editor area gets hidden

Ah, you have the editor widget docked, right? I will see, if hide/show can be replaced by another mechanism in this case.

Torsten Lilge <ttl>
Project Member
Sun 17 May 2020 12:33:09 PM UTC, comment #78: 

yeah i agree, commenting out is an easy check ;-)

so the editor area gets hidden as soon as i press ESC when the autocompletion popup is up. looks like hide() works.

Hg200 <hg200>
Sun 17 May 2020 12:06:18 PM UTC, comment #77: 

What happens if you comment out the activate () command. Is the editor hidden?

Torsten Lilge <ttl>
Project Member
Sun 17 May 2020 11:03:21 AM UTC, comment #76: 

void QWidget::hide() is equivalent to setVisible(false)

this change also does not have effect, or change in behaviour:

//hide ();
activate ();

very strange

Hg200 <hg200>
Sun 17 May 2020 10:39:08 AM UTC, comment #75: 

hg id is e74ee2a8b8e2+ tip @ and its qt 5.13.2 from fedora.

I don't see any flickering if ESC is pressed. Looking forward the next question i have inserted assert(false) after hide() and the gui exits. hence hide() is executed.

where is hide() implemented?

Hg200 <hg200>
Sun 17 May 2020 10:22:09 AM UTC, comment #74: 

Hi Hg200, thanks for testing.

That's weird. With which version of Qt have you tested the patch? And does it make a difference if the completion list disappears because one of the proposed entries is accepted or because it is cancelled with ESC? In the latter case, you should see a short flickering since the editor is hidden and shown again.

Torsten Lilge <ttl>
Project Member
Sun 17 May 2020 10:02:52 AM UTC, comment #73: 

Hi Torsten,

the patch does not solve the autocompletion problem at my side. It does not have any effect at all (i.e. short cut's still don't work after the popup disappears). Sorry.

Hg200 <hg200>
Sat 16 May 2020 10:06:01 PM UTC, comment #72: 

Please find attached a patch for testing. I have tested it on Debian with Qt 5.11.3 and 5.13.2. It "manually" sets the focus to the current tab and the related edit-area when the editor (re-)gets focus (e.g., when tab was closed or completion list finished).

When the completion list is cancelled by ESC, the only way I found to re-activate the non-working shortcuts is hiding and re-activating the editor window. As a consequence, there is an extra flickering. That's why I have not pushed the patch to stable yet, but attached it to this comment for testing it beforehand.  

(file #49094)

Torsten Lilge <ttl>
Project Member
Sat 16 May 2020 09:34:49 AM UTC, comment #71: 

Since this issues are present with qt 13 and 14 (see comment #45) and are quite annoying in the daily work with octave, I am wondering whether this bug should be a blocker for 6.1

Torsten Lilge <ttl>
Project Member
Mon 04 May 2020 05:21:20 AM UTC, comment #70: 

@Hg200: Yes, with qt 5.13.2 I can reproduce the missing focus after closing a tab and the missing shortcuts after closing an autocompletion list. Therefore I am able to work on possible solutions now.

Torsten Lilge <ttl>
Project Member
Sun 03 May 2020 08:31:12 PM UTC, comment #69: 

It is actually bug #57969 comment # 2 (not # 6). Autocompletion was the original complaint in # 57969, but the "tab closing" topic was mixed up later. You kindly replied to comment # 6 of bug #57969, but my question was actually related to comment # 2. However, it doesn't matter ;-)

What about disabling the autocompletion at buildtime (#ifdef) if we are within a certain range of Qt version? Btw, were you able to reproduce the behaviour on your system?

Hg200 <hg200>
Sun 03 May 2020 07:36:11 PM UTC, comment #68: 

What I find is that when autocompletion kicks in and has just one suggestion there's no way to escape the popup other than double-click the suggestion. Neither the Enter nor the Escape keys work; in fact no key at all works.
Would that be a new bug, or a new expression of an established bug?

I did not notice failing shortcuts after the autocompletion popup, but it could well be just my ignorance.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 03 May 2020 07:08:56 PM UTC, comment #67: 

@Philip: The auto completion list closes on Esc or by RETURN when the desired expression is selected. The problem is that after the auto completion list is closed, the editor shortcuts are not working until you have clicked with the mouse into the edit area.

Actually, this is the issue which seems to be more difficult to fix than the one with the broken focus after having closed another tab.

Torsten Lilge <ttl>
Project Member
Sun 03 May 2020 06:52:33 PM UTC, comment #66: 

With the "autocompletion problem" you mean that the only way to get rid of the autocompletion popup is to double-click the suggestion?

I failed to notice this in the comments below but yes, this has hit me too when using Octave.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 03 May 2020 06:49:20 PM UTC, comment #65: 

In the mean time I looked at backing out qtbase to 5.13.0 in mxe-octave, but that tuned out to be less easy than I hoped, relating to various patches required with each new qt version.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 03 May 2020 04:47:28 PM UTC, comment #64: 

Since the cursor going dead occurs in cases where Octave is not
involved, such as xterms and gedit it is not likely that a
workaround for the Octave editor can be found. But, it would
be useful if possible. Good luck!

This is on Fedora FC31 latest updates.

Michael Godfrey <godfrey>
Project Member
Sun 03 May 2020 01:25:12 PM UTC, comment #63: 

@Hg200: Thanks for the suggestions. It was sufficient to copy the scintilla include directory "Qsci" into the local qt installation directory.

Torsten Lilge <ttl>
Project Member
Sun 03 May 2020 01:09:19 PM UTC, comment #62: 

i have downloaded QScintilla-2.11.4.tar.gz source and did:

$ cd Qt4Qt5
$ /home/myuser/QTx/bin/qmake
$ make
$ make install

That did install libqscintilla2_qt5 into the local Qt directory.  Maybe that helps too ;-)

Hg200 <hg200>
Sun 03 May 2020 12:47:27 PM UTC, comment #61: 

Hmm. This is a very good question. Just an idea: If you open a virgin terminal. Is


empty? If not, then consider

export PKG_CONFIG_PATH="/home/samplemaker/QTx/lib/pkgconfig:$PKG_CONFIG_PATH"

instead of

export PKG_CONFIG_PATH="/home/samplemaker/QTx/lib/pkgconfig"

becaus you are cutting away the search path.

did configure display following line:

checking for the QScintilla library for Qt 5... -lqscintilla2-qt5

this is happening in acinclude.m4 maybe we can also cheat in this file.

Hg200 <hg200>
Sun 03 May 2020 10:50:59 AM UTC, comment #60: 

@Hg200: My post was misleading. I can successfully compile qt 5.13.2 but configure for octave misses to find qscintilla when updating PKG_CONFIG_PATH to the new qt location.

Torsten Lilge <ttl>
Project Member
Sun 03 May 2020 10:05:14 AM UTC, comment #59: 

1.) I have now build Octave against Qt 5.13.1 and can confirm the bug.
2.) For some reason Octave refused to be built against Qt 5.13.0. But the testcode demonstrating the problem does not show the problem with 5.13.0. I have attached the code to this comment.
3.) The autocompletion problem also disappears when I fall back to 5.12.8. We should also keep an eye on this problem. Users will also complain if the editor becomes locked due to auto-completion.
4.) In the Qt bug report a fix is mentioned for Qt 5.15.1 or later. That's quite a span between Qt 5.13.0 and 5.15.1. And in the end we also have to confirm the effectiveness of the fix to our problem by testing Octave against 5.15.1. But 5.15.1 is not yet out.

If i install Fedoras Octave package (= octave-5.1.0-3.fc31.x86_64.rpm) the bug already arrived there, as i would expect. The package uses the system wide Qt library (5.13.2):

$ ldd /lib64/octave/5.1.0/liboctgui.so
libQt5Widgets.so.5 => /lib64/libQt5Widgets.so.5 (0x00007f13bee37000)
libQt5Gui.so.5 => /lib64/libQt5Gui.so.5 (0x00007f13be8f6000)
libQt5Core.so.5 => /lib64/libQt5Core.so.5 (0x00007f13be330000)

I don't know what a package maintainer will do if Octave is bound to a specifc Qt version.

First of all, Torsten must have the chance to do his tests between Octave and one of the affected Qt versions. Then we will see.

If you want to compile Qt, the commands I used are the same as in comment #44. The only problem I had when building Qt was to make sure that most of the required development packages were installed, which are unfortunately quite a lot. I paid extra attention that the X related packages are installed:

X11 specific:
  XLib ................................. yes
  XCB Xlib ............................. yes
  EGL on X11 ........................... yes

You can also disable modules via configure if you have a specific problem. However, Qt should not depend on Scintilla. That is weird. Can you send me your full configure output via mail?

(file #48993)

Hg200 <hg200>
Sun 03 May 2020 08:19:06 AM UTC, comment #58: 

Yeah good question :-) I realized it but didn't dare to mention.

Add a configure stanza workaround for the affected versions of Qt?
Anyway you are the GUI/Qt expert so it's mostly up to you.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 03 May 2020 07:07:12 AM UTC, comment #57: 

@Philip: But what should be done after having (positively) tested for Qt >= 5.13.1?

If the bug is really related to proxy chains, maybe it is possible to avoid this by only setting the edit area itself as focus proxy and never the related editor tab.

Torsten Lilge <ttl>
Project Member
Sat 02 May 2020 07:46:59 PM UTC, comment #56: 

Sure, but I just fear that working around obscure upstream bugs may be much more trouble than just checking in configure for Qt >= 5.13.1.
Qt 5.13.1 is quite new. E.g. Mageia 7 is still at 5.12.6. What's the Qt version in other distros? In mxe-octave (dependencies kept at bleeding edge by JohnD) it's easy and maybe even wiser to go back to 5.13.0.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 02 May 2020 07:18:51 PM UTC, comment #55: 

@Philip: We can not be sure when this bug will be fixed. So, yes, I will at least have a look into this with the new knowledge from the bug report.

Torsten Lilge <ttl>
Project Member
Sat 02 May 2020 07:05:44 PM UTC, comment #54: 

Going back to Qt < 15.3.1 is also an option?

In mxe-octave Qt was updated to 15.3.1 on Sept. 6 last year:
In comment #38 I noted that this bug starting to hit me between 16 and 23 Sept. last year, and taking into account that I update mxe-octave dependencies only every few weeks this all fits together quite well.

Is it worthwile to try to work around this upstream bug?

The file log for mxe-octave's qtbase.mk is here:
so for windows using with a 10 months old Qt release wouldn't hurt.

Shall I try to make a cross-build using Qt 5.13.0 ?

Philip Nienhuis <philipnienhuis>
Project Member
Sat 02 May 2020 06:34:44 PM UTC, comment #53: 

Hg200, I am trying to follow your instructions in comment #44 in order to install qt 5.13.2 on my system but configure fails to find Qscintilla when doing so. Did you face the same problem and how did you solve it?

Torsten Lilge <ttl>
Project Member
Sat 02 May 2020 05:46:50 PM UTC, comment #52: 

@Hg200: Thank you for the hint to the bug report. This explains why the bug suddenly came up without any changes in the relevant octave source files. With the information of the bug report I will try to find a workaround that also works with the affected qt-versions.

Torsten Lilge <ttl>
Project Member
Sat 02 May 2020 04:22:38 PM UTC, comment #51: 

Updates: There is a pending bug report for setFocusProxy in the Qt tracker. The problem is introduced with Qt 5.13.1, the same version as @Torsten mentioned in comment #39. Beyond this, the report also provides further insight into the behavior of setFocusProxy. I'm not that deep in Qt, but it sounds related:


Furthermore i can reproduce the problem with a small Qt application that only contains QTabWidget and QTextEdit and a proxy chain set up like in the Octave GUI. Therefore I rule out a dependency on QScintilla.

Hg200 <hg200>
Sat 02 May 2020 12:09:24 AM UTC, comment #50: 

I should have added that the hangs tend to happen more if the window that hangs is not fully within the screen.
And, I am pretty sure the in my case this is due to recent
Fedora updates.

Michael Godfrey <godfrey>
Project Member
Sat 02 May 2020 12:04:20 AM UTC, comment #49: 

Using fedora 31 with current updates (qt 5.13.2-2.fc31.x86_64)
I still get unresponsive windows outside of Octave.
This is particularly noticeable when using gedit or just in
an xterm. The window freezes and then after some mouse
movement or clicking it wakes up again. This has been
happening for a few weeks. This suggests that the problem
is not entirely due to Octave.

Michael Godfrey <godfrey>
Project Member
Fri 01 May 2020 02:05:14 PM UTC, comment #48: 

By the way, maybe related:

There was a time that I could consistently crash Octave-7.x.x during startup when, before Octave shows the prompt, I closed the empty Editor tab by clicking its close button.
(I have the undocked editor mostly on a separate screen).
It's a bit elusive as I just tried this with Octave-5.2.0 and an older Octave-6.0.0 and since those tries I can't get Octave to crash anymore. Go figure.

In Octave-5.2.0 I could never provoke such a crash.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 30 Apr 2020 08:40:45 PM UTC, comment #47: 

@Philip: TNX. That would have been my next step to see if a fix comes with a higher Qt version. 5.14 is very new.

Now i have built Octave also against a fresh (local) build of Qt 5.13.2. The problem shows up. So it is not caused by the pre-build package that comes with the distro. The switch between 5.12.8 / 5.13.2 is the only difference that remains.

@Torsten: That is weird.

Hg200 <hg200>
Thu 30 Apr 2020 07:52:04 PM UTC, comment #46: 

@Hg200, I have removed one focus proxy at a time. Then switching foucs from one tab to another by only clicking the tab with the file name does not give input focus to the related edit area.

Torsten Lilge <ttl>
Project Member
Thu 30 Apr 2020 07:22:12 PM UTC, comment #45: 

FWIW, in mxe-octave (f. Windos) Qt is at 5.14.2.
The focus problem is still there.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 30 Apr 2020 06:45:31 PM UTC, comment #44: 

I downloaded qt-everywhere-src-5.12.8.tar.xz. In order not to jam my system installation, I built Qt with the parameter

./configure --prefix=/home/myuser/QTx

and installed it locally. Then I adjusted

export PKG_CONFIG_PATH="/home/myuser/QTx/lib/pkgconfig"

to point Octave to the locally installed Qt and built Octave against Qt 5.12.8.

So here we have it: Problem disappears when I run

./run-octave --gui

Also the ctrl-xyz short cut feature problem dissapears.

Now it could still be a problem with the pre-built Qt that comes with the distro, but I think this likelihood is pretty small.

@Torsten: What was the test procedure? I.e. where did you click? Did you remove only one proxy or both?

Hg200 <hg200>
Wed 29 Apr 2020 07:54:08 PM UTC, comment #43: 

From my tests, both setFocusProxy are required. Otherwise, the edit area gets no focus when clicking into the editor but outside the edit area.

Torsten Lilge <ttl>
Project Member
Mon 27 Apr 2020 09:43:42 AM UTC, comment #42: 

The bug disappears if we either remove line file-editor.cc:969 OR file-editor-tab.cc:266. So it looks like there is some interference between the two proxies as well.

My understanding is that file-editor.cc:969 "resets" the proxy that is installed into the file_editor_tab_widget, so that the focus is forwarded from the file_editor_tab_widget widget to the active file_editor_tab widget. In the file_editor_tab constructor, proxies are installed into each of the file_editor_tab widgets (line file-editor-tab.cc:266) in order to propagate the focus further to the m_edit_areas. A proxy chain is allowed by the API. Remains odd.

Hg200 <hg200>
Sat 25 Apr 2020 07:30:22 PM UTC, comment #41: 

I suppose you tested on Linux. On Windows the bug may have been just looming until it got exposed after Sept. 16 (at least on my system and with my mxe-octave build tree, see below). AFAIR I didn't notice the "inactive cursor issue" last summer, I only noticed much later on.

Qt5.13.1 may have been a factor; maybe together with a lot of editor / debug refactoring that JWE did around mid Sept.
I usually work with an mxe-octave build tree for 2-3 months (only regularly updating dev Octave and some OF packages) and update that build tree itself maybe every 2-3 weeks. So the Qt update in my system may well have occurred only late September.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 25 Apr 2020 12:50:14 PM UTC, comment #40: 

I have just build and tested 2c9795736894. This is from june 2019 and it also shows the problem ;-)

In 2019 I made lots of local builds, always as a fetch from the hg tip of the devel branch and they were all okay until the problem started end of 2019.

I think a Qt update could be a hot candidate. I currently build against libQt5Widgets from V 5.13.2

Hg200 <hg200>
Sat 25 Apr 2020 12:03:50 PM UTC, comment #39: 

Philip, thanks for testing. Weird, at first sight I do not see any changeset neither in octave sources nor in mxe sources that might have introduced the issue (mybe, except for an update to qt 5.13.1 in mxe on Sep 06?).

Hg200, no problem, I can test myself in windows the setFocus/setFocusProxy thing. I didn't realize that you are debugging on Fedora and not on Windows.

The focusInEvent is triggered two times if the tab you are closing does not have focus. It gets focus when you click on the tab and afterwards the focus changes to the remaining tab, which triggers the second focusInEvent.

Torsten Lilge <ttl>
Project Member
Sat 25 Apr 2020 11:16:55 AM UTC, comment #38: 

A first throw at reinstalling old binary installers shows that one from Sep 16 2019 works fine, while another one from Sep 23 2019 has the bug. (Hmmm I expected it was an old bug; but so old ...)

(I used the trick of opening two files in the editor, clicking in one and then closing it ==> other file (tab) has no visible cursor.
Both done in Windows7 and Windows 10, just to be sure.)

Looking at the log there aren't that many candidates. The candidate sequence runs from

  • da1f59fe04b3 try to use consitent ordering for include files in libgui sources


  • 251056aeba5d Align negative numbers correctly with g format (bug #56940)
Philip Nienhuis <philipnienhuis>
Project Member
Sat 25 Apr 2020 08:46:04 AM UTC, comment #37: 

(Philip here.)
Yes I can test if you attach csets here.
Due to build + crossbuild cycle times expect overnight results at the fastest.

Another possibly useful thing to be done is "bisecting" (not the hg stuff). I have a collection of archived mxe-octave crossbuilds that I can reinstall one by one to find out which cset induced the offending behavior.
This bug report dates from mid-January but I'm often quite slow to report, so the change provoking this bug may have occurred much earlier.

Philip Nienhuis <philipnienhuis>
Project Member
Sat 25 Apr 2020 07:36:02 AM UTC, comment #36: 

Hello Torsten,

> Great, Hg200. I have played around a little bit on Linux and have not found any changes in the behavior without the setFocusProxy.

By the looks of it, it seems to solve the problem on linux fedora. But i feel uncomfortable. At least unless i understand a bit more what is happening. Some questions / hints are:

- How should we deal with other setFocusProxy () statements? For example there is another one in file_editor::handle_editor_state_changed. Shall we just remove the one for m_edit_area?
- Why is octave_qscintilla::focusInEvent executed two times if the "patch" is applied? For this please have a look at my test report attached to this comment. It is test No. 2. Could be a tab_change and tab_remove reason?
- Off topic, but I would like to mention that this patch does not fix the bug #57969. Is there really no relation ship between both bugs?


- I can spend a little more time on backtrace investigation. Who is triggering the focusInEvent for what reason? But I will need help to some extent.
- I can't promise any success but i can step with gdb into the FocusProxy.

> Why do you think that setFocus has no effect? When I comment it out (line 954, togehter with setFocusProxy in 266) the focus is not transferred to the edit area whenever the editor or a tab gets activated. Uncommenting setFocusProxy seems to make it work again.

What I want to say is that the "Switching Tab-Test" can pass even though the m_edit_area->setFocus statement is commented. This happens when the FocusProxy is up. Commenting / uncommenting on m_edit_area->setFocus has no effect in this particular scenario because the cursor is presumably restored by a different caller. In the attached test report these are the tests #1 and #3. But you are also right: Of course, it does not imply that m_edit_area->setFocus is a useless statement. For example m_edit_area->setFocus becomes a mandatory statement when the FocusProxy is down (tests #2 and #4). So my wording was unfortunate. Sorry for the mess.

> Could you please test on WIndows whether removing setFocus and leaving setFocusProxy also fixes the issue. Maybe calling setFocus on the focus proxy is a problem.

I don't use windows nor do i have access to a windows computer. Maybe @Philip Nienhuis can do that for us. He reported the problem on windows.

(file #48932)

Hg200 <hg200>
Thu 23 Apr 2020 06:16:29 PM UTC, comment #35: 

Great, Hg200. I have played around a little bit on Linux and have not found any changes in the behavior without the setFocusProxy.

Why do you think that setFocus has no effect? When I comment it out (line 954, togehter with setFocusProxy in 266) the focus is not transferred to the edit area whenever the editor or a tab gets activated. Uncommenting setFocusProxy seems to make it work again.

Could you please test on WIndows whether removing setFocus and leaving setFocusProxy also fixes the issue. Maybe calling setFocus on the focus proxy is a problem.

Torsten Lilge <ttl>
Project Member
Thu 23 Apr 2020 12:13:39 PM UTC, comment #34: 

Short update:

1.) I have found that commenting file-edit-tab.cc:266 solves the problem. In this case I think the widget is setup without focus proxy (?).

if (settings)
  notice_settings (settings, true);
  // setFocusProxy (m_edit_area);

However it has no effect to set m_edit_area -> setFocusPolicy(Qt::StrongFocus) after setFocusProxy (). That was just a try and error.

2.) Add note to my statement in the previous comment "Scenario B, 2.)": octave_qscintilla::focusInEvent is executed but the source is not m_edit_area->setFocus (). The call m_edit_area->setFocus () does not have any effect at all.

Hg200 <hg200>
Thu 23 Apr 2020 07:48:21 AM UTC, comment #33: 

Ahhh - that makes a lot more sense! Thank you for pointing out this small but important difference ;-)

I configured gdb to print a backtrace after a breakpoint is hit and let gdb continue automatically. Because switching between the GUI and the gdb console creates notify-events. It is like you said:

Scenario A:

1.) Two tabs are opened and one is closed with the mouse => m_edit_area->setFocus () is executed twice for the reasons file_editor::active_tab_changed(int) and file_editor::handle_tab_remove_request()
2.) Reimplementation octave_qscintilla::focusInEvent is not triggered. In the GUI the focus is lost.

Scenario B:

1.) Two tabs are opened. Click the tabs with mouse to bring one into foreground => m_edit_area->setFocus () is executed once because of file_editor::active_tab_changed(int)
2.) Reimplementation octave_qscintilla::focusInEvent is triggered. In the GUI the focus is correctly transfered.

This is odd ;-( The implementation of octave_qscintilla::focusInEvent looks correct to me.

Hg200 <hg200>
Wed 22 Apr 2020 08:16:59 PM UTC, comment #32: 

I think file_editor::set_focus is not involved here.

file_editor::activate emits the signal fetab_set_focus. The related slot file_editor_tab::set_focus is activated but it does not result in the edit area of the remaining tab getting focus.

On Linux, octave_qscintilla::focusInEvent is triggered, but not in Windows, although file_editor_tab::set_focus sets the focus for the edit area (octave_qscintilla). From my findings, it is this m_edit_area->setFocus () in file_editor_tab::set_focus which does not work as expected.

Torsten Lilge <ttl>
Project Member
Wed 22 Apr 2020 07:56:08 AM UTC, comment #31: 

First of all, to ensure that this is no GDB artifact (e.g. the BP does not work) i have added assert () to set_focus (), rebuild the source and it never stops running if i open & close tabs. But if i put assert into activate () it stops running.

  void file_editor::activate (void){
    QWidget *fileEditorTab = m_tab_widget->currentWidget ();
    if (fileEditorTab)
      assert (false);

  void file_editor::set_focus (QWidget *fet) {
    assert (false);
    setFocus ();

My thoughts are:

1.) Can somebody confirm that the correct behaviour to set the focus is the slot file_editor::set_focus?

2.) If so, next question is why it is not executed. i.) Reason could be a broken Qt installation. ii.) Or there is a bug in octave lib gui that manifests only in a specific Qt version.

3.) According to Qt docs addTab() or insertTab() is used to put the page widgets into the tab widget. The signal / slot connection is setup in file_editor::make_file_editor_tab (file-editor.c:2459) and it is transfered into the tab widget when *.m files are opened. That is in file_editor::request_open_file and file_editor::add_file_editor_tab.
Vice versa, when a tab is destroyed in file_editor::handle_tab_remove_request the sender object is searched in the tabwidget and then deleted. In file_editor::activate "QWidget *fileEditorTab = m_tab_widget->currentWidget" is used to emit the fetab_set_focus signal to force the focus to the current widget (my guess).

No doubt, i can be wrong. But the idea why the slot is not executed could be a disconnected signal / slot pair in the returned widget. Or the wrong widget is returned. The problem is that following modification does not have any effect (i.e. the focus is still not there when closing a tab):

  void file_editor::activate (void) {
    octave_dock_widget::activate ();

    QWidget *fileEditorTab = m_tab_widget->currentWidget ();
    setFocus ();
    m_tab_widget->setCurrentWidget (fileEditorTab);

Hg200 <hg200>
Wed 22 Apr 2020 05:21:42 AM UTC, comment #30: 

Hg200, thank you very much for digging deeper into this. What do you mean by "_tab_widget->currentWidget is maybe screwed up". Do oyu think that currentWidget does not point to the remaining tab?

Torsten Lilge <ttl>
Project Member
Tue 21 Apr 2020 12:04:05 PM UTC, comment #29: 

checked via gdb: the fetab_set_focus / set_focus connection does not work due to some reason (session attached). in file_editor::activate the "emit fetab_set_focus (fileEditorTab)" is thrown but the slot file_editor::set_focus is not executed. since the signal / slot connection setup is in the scope of file_editor::make_file_editor_tab my question is if m_tab_widget->currentWidget is maybe screwed up:

void file_editor::activate (void)
QWidget *fileEditorTab = m_tab_widget->currentWidget ();

I.e. either not correctly setup in

fileEditorTab = make_file_editor_tab ();
add_file_editor_tab (fileEditorTab, "", index);

or maybe overwritten somewhere else. shall i continue digging into this direction?

(file #48893)

Hg200 <hg200>
Wed 15 Apr 2020 06:11:00 PM UTC, comment #28: 

Hg200, thanks for debugging. Your results confirms that the edit area (octave_scintilla) does not get the input focus. Another indicator for this is that the reimplemented focusInEvent of the first tab is not triggered when the second tab is closed (whereas it is triggered on my Debian system).

The question is what prevents octave_scintilla from getting focus.

Torsten Lilge <ttl>
Project Member
Tue 14 Apr 2020 10:03:56 PM UTC, comment #27: 

Here, it looks as follows:

1.) Open one .m file
2.) Delete the file from another terminal
3.) A popup appears. I press the "close" button
4.) I click into the menu and select: "file -> new script"
5.) A new file is created but there is no cursor in the editor. Typing on the keyboard does not have any effect.

Hence I think it is identical to comment #9.

Because we don't know very much i just started poking around in octave-qscintilla.cc. If i bring the gui into the "broken mode" (procedure described in bug #57969 comment #6) i can see that the cursor_position_changed slot is executed when i click into the broken GUI editor whereas keyPressEvent is not executed when pressing any keys.

(gdb) break octave-qscintilla.cc:1040
Breakpoint 1 at 0x7fcbbcf64bcd: file libgui/src/m-editor/octave-qscintilla.cc, line 1040.
(gdb) cont

=> now move to the gui and close that file-tab which has the current focus so that the gui becomes broken. clicking with the mouse into the remaining file editing area gdb halts:

Thread 1 "lt-octave-gui" hit Breakpoint 1, octave::octave_qscintilla::cursor_position_changed (this=0x1c8d340, line=3, col=0) at libgui/src/m-editor/octave-qscintilla.cc:1040
1040        if (! m_selection.isEmpty ()

If i repeat the procedure with bp at keyPressEvent and if i press the keyboard gdb does not halt:

(gdb)  break octave-qscintilla.cc:1084
Breakpoint 1 at 0x7fbf83127017: file libgui/src/m-editor/octave-qscintilla.cc, line 1084.
(gdb) cont

=> does not halt once the editor becomes broken, even even i click into the editor. gdb will stop once the editor becomes "healed" again.

Hg200 <hg200>
Tue 14 Apr 2020 08:19:43 PM UTC, comment #26: 

Yes I figured that (hidden dialog that I expect to see) but I couldn't see it. Normally it shows up in the Task (Alt-Tab) overview.
I'm building a new Windows 7.0.0, tomorrow I can try if that behaves better.

Philip Nienhuis <philipnienhuis>
Project Member
Tue 14 Apr 2020 07:12:49 PM UTC, comment #25: 

In the meantime I can reproduce the issue when removing one of two tabs.

But when removing an open file, I get the warning dialog that the editor file was removed and how to proceed. Maybe this dialog is hidden by another window in your configuration? When the dialog is active the related editor file is read only and can not be changed.

Torsten Lilge <ttl>
Project Member
Tue 14 Apr 2020 04:56:48 PM UTC, comment #24: 

Another manifestation:

Open some file in the editor.
Then remove the file from the subdirectory (delete or move elsewhere).
Then there's no way the editor will respond to mouse clicks in the text, not even clicking on some other window and then come back.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 10 Apr 2020 02:04:24 PM UTC, comment #23: 

Going back to Qscintilla 2.11.3 didn't solve the issue on my Windows box.
So I suppose that means a Qscintilla issue can be ruled out.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 10 Apr 2020 12:57:53 PM UTC, comment #22: 

That qscintilla might cause this is currently a guess. First, I have to find a way to reproduce this on my systems and then I should be able to find out what is going on.

Torsten Lilge <ttl>
Project Member
Fri 10 Apr 2020 12:13:55 PM UTC, comment #21: 

My pleasure, but what will we do now? Downgrade to earlier Qscintilla, or work around it?

AFAIR I only noted this starting in January, i.e., after the mxe-octave upgrade to Qscintilla 2.11.4; if you wish I can backout the relevant cset in mxe-octave and see if that helps.

Any chances this Qscintilla version might also affect that other elusive issue, bug #57902? That one also started somewhere this year.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 10 Apr 2020 11:35:25 AM UTC, comment #20: 

Philip, thanks for testing. So it can still affect Linux, too, if, e.g. qscintilla verson >= 2.11.4 introduces this issue. The shortcuts not working might have the same cause, i.e. that the focus is not properly transferred to the editor.

Torsten Lilge <ttl>
Project Member
Fri 10 Apr 2020 10:15:24 AM UTC, comment #19: 

I just tried on Mageia Linux, using the very same Octave build that my Windows build is based on.
Result: works fine so can't confirm on Linux.

FWIW, Qscintilla on Mageia-7 is at 2.11.1, while on mxe-octave it is at 2.14.2. Qt on Mageia-7 is probably also a little older the one used in mxe-octave.

Philip Nienhuis <philipnienhuis>
Project Member
Fri 10 Apr 2020 10:02:51 AM UTC, comment #18: 

I just confirmed the procedure in comment #9 below (and bug #57969 comment #6).

I don't know if the original issue of bug #57969 is the same or has the same cause as this one here.

For the time being, let's continue the ineffective cursor here. To me it doesn't matter much but it seems to be convention to close later duplicates and continue on the earliest one.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 09 Apr 2020 10:44:12 PM UTC, comment #17: 

Hello Philip,

1.) In my opinion first part of your original submission "editor has focus but no cursor" sounds similar to my submission bug #57969 comment #6. If i am correct, the problem also occurs on Linux Fedora.

To me it also sounds identical to the anonymous submission comment #9 of this bug report.

2.) I cannot confirm the second part mentioned in your original submission: "greyed (whited) out submenus"

3.) My question to you: There is another problem that is described in bug #57969 comment #2. This deals with autocompletion. Vice versa: Please - can you confirm this on Windows?

PS.: If we all conclude both bug reports are identical we can close one of those. Or do whatever procedure is foreseen in such a case.

Best regards

Hg200 <hg200>
Thu 09 Apr 2020 08:35:35 PM UTC, comment #16: 

So, gentlemen, is this still a Windows-only bug or is it also confirmed on e.g., Linux?

Philip Nienhuis <philipnienhuis>
Project Member
Thu 09 Apr 2020 06:44:24 PM UTC, comment #15: 


rpm -qa | grep qscintilla


I have not seen any problems on Fedora with other programs (e.g. xterm) such as stuck windows. Only trouble with Octave Editor.

Hg200 <hg200>
Thu 09 Apr 2020 01:46:33 PM UTC, comment #14: 

It happens for xterm windows whatever the contents. And, it
may happen for other windows, but I have only noticed it for
xterms. I think that it is a "feature" of a recent upgrade
to Fedora 31...

Michael Godfrey <godfrey>
Project Member
Thu 09 Apr 2020 08:33:00 AM UTC, comment #13: 

That would be a case of going through the mxe-octave file log or use some tool for it.
What I tried:

  • Looked in the mxe-octave file log for tag octave-5.2.0, that was 7e55d4512a62 "Added tag octave-release-5.2.0 for changeset 8c1e1ef46ed2", date = Feb 3 2020;
  • browsed the file log for qscintilla.mk ==> that was changed lastly on Dec. 23 2019 ("src/qscintilla.mk: update to v2.11.4")

==> So I suppose it is v2.11.4

@Hg200: bug #57969 comment #6 might be a duplicate of this bug, or vice versa, or maybe one should depend on the other.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 09 Apr 2020 05:43:07 AM UTC, comment #12: 

@Michael: Does all applications show the issue with frozen issues or just with octave?

@Philip: Do you know which version of QScintilla was sued for the 5.x stable mxe builds?

@Hg200: Which version of QScintilla does Fedora 31 use?

Torsten Lilge <ttl>
Project Member
Wed 08 Apr 2020 11:03:24 PM UTC, comment #11: 

I have noticed with recent updates of Fedora 31 that windows
which are partially off the screen tend to freeze at
least for some time. They do not respond to horizontal mouse
movement, but respond to vertical movement, and then work
normally again. This behavior started a few weeks ago. I
run dnf update fairly regularly. Just a nuisance for me
but I normally use Octave in command line mode.

Michael Godfrey <godfrey>
Project Member
Wed 08 Apr 2020 07:40:36 PM UTC, comment #10: 

I think it is the same as in bug #57969 comment #6.

My question: Can you reproduce also the second problem as described in bug #57969 comment #2 when autocompletion is enabled?

Some more infos:

1.) Since the problem suddenly appeared on my system, I compiled older HG-Id's from the devel branch, that worked once for me. For example 992e702ef0d7 (11 / 2019). These also no longer work. Hence I would say the problem came in with a "dnf update" (fedora package update).

2.) I installed a second computer. Complete fresh Fedora 31. Same problem. The same also with Octave 5.1 and 5.2.

Hg200 <hg200>
Wed 08 Apr 2020 03:09:56 PM UTC, comment #9: 

I can second this problem.

A simple way to reproduce it is as follows:
1) create a new script file or open an existing one,
2) create a new script file or open another existing one,
3) close the second file, the first script is now visible again,
4) try to set the cursor somewhere in the code with the mouse.

Step 4 is impossible now. Using the arrow keys to navigate does not work either.

Interestingly, it is possible to use the mouse to highlight text through dragging while holding the left mouse button or through doubleclicking.

Some technical information:

I have Octave 5.2.0 installed, using https://ftpmirror.gnu.org/octave/windows/octave-5.2.0_1-w64-installer.exe. The computer is a laptop that has Windows 7 as operating system. The editor is on the first screen and docked within the Octave window. I open the script files by doubleclicking on the filenames in the File Brower window.

Mon 20 Jan 2020 01:55:41 PM UTC, comment #8: 

Editor on same screen makes no difference.
It's just that there's no cursor, selecting words by double-clicking works (and copy-paste to somewhere else as well).

Philip Nienhuis <philipnienhuis>
Project Member
Mon 20 Jan 2020 05:28:33 AM UTC, comment #7: 

I can not reproduce this on my virtual windows machine. But I have no second screen. Does this issue also show up when the editor is on the same screen as the main window?

Torsten Lilge <ttl>
Project Member
Sun 19 Jan 2020 08:41:44 PM UTC, comment #6: 

I just noted that also files that are not in a private dir behave the same.
So it is opening through the Recent Editor files list that leads to the buggy behavior.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 19 Jan 2020 08:36:52 PM UTC, comment #5: 

Mru list - isn't that the Recent Editor files list?

Philip Nienhuis <philipnienhuis>
Project Member
Sun 19 Jan 2020 08:07:32 PM UTC, comment #4: 

Reply to comment #3: How do you open the m-file in the private dir, with the open file dialog or via the mru list?

Torsten Lilge <ttl>
Project Member
Sun 19 Jan 2020 05:56:33 PM UTC, comment #3: 

By coincidence I found one that's relatively reliable here:

I got some <share>/octave/m/6.0.0/m/pkg/private/*.m functions in the Recent Editor files list. Opening one of those, while not in the pertinent private dir, leads to this phenomenon.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 19 Jan 2020 05:51:35 PM UTC, comment #2: 

I have the undocked editor pane usually on a second monitor, that's the layout when Octave starts here.
It's when I do s/th like "edit <function>" or "edit <function>.m" that I often see that the editor has focus but no cursor response.
AFAIR the nr. of editor tabs makes no difference, IIRC it already happens with just one tab.

Oh to be complete (maybe it matters): I usually close the default empty tab when Octave starts, I don't like the bright white pane staring at me when there's nothing to edit, I find the empty gray pane less obtrusive.
And I also often have private functions in other tabs, maybe that matters as well?

As I wrote, it's hard to pinpoint a reliable way to reproduce the bug.

Philip Nienhuis <philipnienhuis>
Project Member
Sun 19 Jan 2020 03:23:49 PM UTC, comment #1: 

Philip, can you narrow the cases where the editor but not the active editor tab has focus by the way the editor gained focus (Ctrl-4, menu entry, edit file, ...)?

Torsten Lilge <ttl>
Project Member
Sun 19 Jan 2020 02:28:01 PM UTC, original submission:  

(sorry for my perhaps bad wording in title)

On Windows I often find that the GUI editor with a loaded file has focus but no text cursor and clicking inside he text does not help.
In such a case I can only get a text cursor after clicking anywhere else than in the editor pane, and then click in the editor.

Perhaps related:
When clicking on of the menu items in the Editor's main meny toolbar (e.g., "File") and shift the mouse cursor down to an item with a submenu (e.g., "Recent Editor Files"), the contours of a popup to the right of that item show up but the popup is merely greyed (whited) out until I move the mouse cursor just a tiny little bit. Only then the popup contents are shown.

It could be that some local settings are at play here (delayed focus and hover in the Windows registry) but Octave is the only program that shows the behavior described above.

Philip Nienhuis <philipnienhuis>
Project Member


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #49156:  bug57635_v04.patch added by ttl (9KiB - text/x-patch)
file #49146:  bug57635_v03.patch added by ttl (9KiB - text/x-patch)
file #49116:  bug57635_v02.patch added by ttl (6KiB - text/x-patch)
file #49094:  bug57635_v01.patch added by ttl (4KiB - text/x-patch)
file #48993:  tabwidget_focustest.tar added by hg200 (20KiB - application/x-tar)
file #48893:  session_21_04.txt added by hg200 (2KiB - text/plain)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by hg200 (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Submitted the item)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 13 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-05-27 ttl StatusPatch Submitted => Fixed
        Open/ClosedOpen => Closed
    2020-05-23 ttl Attached File- => Added bug57635_v04.patch, #49156
    2020-05-22 ttl Attached File- => Added bug57635_v03.patch, #49146
    2020-05-18 ttl Attached File- => Added bug57635_v02.patch, #49116
    2020-05-16 ttl StatusConfirmed => Patch Submitted
    2020-05-16 ttl Attached File- => Added bug57635_v01.patch, #49094
    2020-05-04 ttl StatusNone => Confirmed
        Operating SystemMicrosoft Windows => Any
    2020-05-03 hg200 Attached File- => Added tabwidget_focustest.tar, #48993
    2020-04-25 hg200 Attached File- => Added focusInEvent-test_results_v1_2020_04_25.pdf, #48932
    2020-04-21 hg200 Attached File- => Added session_21_04.txt, #48893
    2020-01-19 philipnienhuis SummaryEditor often has focus but no cursor until clicked elsewhere and then clicked in editor => Editor often has focus but no cursor until clicking elsewhere and then clicking in editor

    Back to the top

    Powered by Savane 3.5