#186 Scary bringToFront bug in connection with TeX error browsing

[Joachim Kock]

Scary bringToFront bug in connection with TeX error browsing

I see sometimes that after a tex run, when I press Ctrl-W to browse
errors, the effect is that the list of error lines is inserted into the
tex source window instead of the TeX Console window! (Quite
scary: unless you are quick and do Undo, you risk losing the content
of your tex file!)

There has been no change to the corresponding code in tetexComm for
nearly 10 years, and the symptoms are also more like a core problem.

The relevant proc is [TeX::tetexComm::displayErrorsAndWarnings].
In there I then inserted a debugging alertnote as follows:

bringToFront $texConsole
   alertnote [win::Current]
text delete [minPos] [maxPos]

between the potential window change and the damaging text operation.
What happens then is that the alertnote reports the full path of the
tex source window, but after clicking OK, the warning list is
actually inserted into the TeX Console.

Surely some asynchronous stuff is taking place, confirmed by the
following experiment:

bringToFront $texConsole
   set ::A [win::Current]
text delete [minPos] [maxPos]

In this case, the damaging text is inserted into the tex source
window, which is also the value of ::A. The difference between the
two scenarios suggests that [bringToFront] has some delay, and that
the alertnote takes enough time for the current window to become
up to date. In fact, here is something funny:

bringToFront $texConsole
   alertnote [win::Current]
   alertnote [win::Current]
text delete [minPos] [maxPos]

will give two alerts, the first reporting the path of the tex source
file and the second reporting "TeX Console".

To add to the mystery, the TeX Console is obviously frontmost at
the time Ctrl-W is invoked, so I don't see how the tex source window
could be involved at all.

[Bernard Desgraupes]

Hi Joachim,
I cannot reproduce the problem. I tried on three different versions of the system (Maverick, High Sierra and Mojave). I've added debugging calls in the core to print out the ordered windows and everything looks fine.
As a workaround, we could make the code safer in the proc [TeX::tetexComm::displayErrorsAndWarnings] by adding -w options like for instance:

text delete -w $texConsole [minPos -w $texConsole] [maxPos -w $texConsole]

But this is just a workaround, not a fix in case there is indeed a race condition (inside Cocoa?) as your experiments suggest.

[Bernard Desgraupes]

I have introduced the suggested fix (workaround).
Changes committed to the repository (rev. 1548).

[Bernard Desgraupes]

Resolved as fixed but will still investigate regarding possible race condition between makeKeyAndOrderFront and orderedWindows Cocoa methods.