Tk Source Code

View Ticket
Login
Ticket UUID: 69b48f427e94899ad5127cf1580558b99b73b448
Title: Test "textTag-18.1" fails since Win10 Creator Falls update
Type: Bug Version: 8.6.8
Submitter: oehhar Created on: 2018-01-09 13:27:31
Subsystem: 18. [text] Assigned To: fvogel
Priority: 5 Medium Severity: Minor
Status: Closed Last Modified: 2020-01-25 17:14:46
Resolution: Fixed Closed By: fvogel
    Closed on: 2020-01-25 17:14:46
Description: (text/x-fossil-wiki)
Initial report:

textTag-18.1 failed for 8.6.8 as with the rc.

Here is the log:

<verbatim>
==== textTag-18.1 TkTextPickCurrent tag bindings FAILED
==== Contents of test case:

    text .t -width 30 -height 4 -relief sunken -borderwidth 10
-highlightthickness 10 -pady 2
    pack .t

    .t insert end " Tag here " TAG " no tag here"
    .t tag configure TAG -borderwidth 4 -relief raised
    .t tag bind TAG <Enter>  {lappend res "%x %y tag-Enter"}
    .t tag bind TAG <Leave>  {lappend res "%x %y tag-Leave"}
    bind .t <Enter> {lappend res Enter}
    bind .t <Leave> {lappend res Leave}

    set res {}
    # Bindings must not trigger on the widget border, only over
    # the actual tagged characters themselves.
    event gen .t <Motion> -warp 1 -x 0 -y 0 ; update
    event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
    event gen .t <Motion> -warp 1 -x 25 -y 25 ; update
    event gen .t <Motion> -warp 1 -x 20 -y 20 ; update
    event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
    event gen .t <Motion> -warp 1 -x 25 -y 25 ; update
    return $res

---- Result was:
{25 25 tag-Enter} {20 20 tag-Leave} {25 25 tag-Enter}
---- Result should have been (exact matching):
Enter {25 25 tag-Enter} {20 20 tag-Leave} {25 25 tag-Enter}
==== textTag-18.1 FAILED
</verbatim>

   *   This test never failed for other Tk versions on my radar [http://wiki.tcl.tk/37529]
   *   tcl/tk 8.5.8 dist in folder c:\test
   *   O/S: WIndows 10 64bit GER
   *   Compiler: MS.VC6++ with PSDK 2003SP1
   *   Command line:

<verbatim>
nmake -f makefile.vc test TCLDIR=c:\test\tcl8.6.8 TESTFLAGS="-verbose bte" > testlog_tk8.6.8.txt 2>&1
</verbatim>

<h1>Remark by Francois</h1>

I had a look at the source code: the test itself did not change between 8.6.7 and 8.6.8, nor tkTextTag.c . Besides, I don't see which other change could make the tags behavior wrong in 8.6.7 if they were OK for you in 8.6.7, which you already confirmed).

I have just run the Tk tests again again and for me this test stubbornly refuses to fail, unless I fiddle with the mouse while the tests are running.I can only make it fail by moving the mouse inside the windows that open during the test, for instance I can get:

<verbatim>
==== textTag-18.1 TkTextPickCurrent tag bindings FAILED

<...snip...>

---- Result was:
Enter {25 25 tag-Enter} {20 20 tag-Leave} {23 24 tag-Enter} {20 20 tag-Leave} {25 25 tag-Enter}
---- Result should have been (exact matching):
Enter {25 25 tag-Enter} {20 20 tag-Leave} {25 25 tag-Enter}
==== textTag-18.1 FAILED
</verbatim>

But, again, if the mouse is not over the window that opens during the tests I can get no failure.

Can you try this on your side: start the tests from a location (icon, script...) in your screen that has no intersection with the test window that it opens during the test: doestextTag-18.1 fail?

If that's the cause (i.e. if it fails because your mouse is still at a "wrong" location after you started the tests, then it means two things:

1. It certainly already failed in prevous releases

2. I should look at ruggedization of this test

<h1>Comment by Brian</h1>

I think this test is suspect.
There's no certainty that an Enter event is NOT produced from the action of the first event gen statement since the initial position of the cursor is unknown:

<verbatim>
event gen .t <Motion> -warp 1 -x 0 -y 0 ; update
</verbatim>

I would try changing the test:

<verbatim>
event gen .t <Motion> -warp 1 -x 0 -y 0 ; update ;# Initialize pointer location.
set res {}
# Bindings must not trigger on the widget border, only over
# the actual tagged characters themselves.
event gen .t <Motion> -warp 1 -x 0 -y 0 ; update ;# Should be a no-op now because the previous event will essentially initialize the pointer location.
</verbatim>
User Comments: fvogel added on 2020-01-25 17:14:46: (text/x-fossil-wiki)
A further adjustment of bind-34.3 was needed to robustify this test against KDE screen edges/corners, see [0a767426].

jan.nijtmans added on 2019-11-26 14:41:07:
> Any comments...?

Well, I could't think of anything better than that.

fvogel added on 2019-11-26 12:57:27: (text/x-fossil-wiki)
I have committed something working around this unexpected Win10 bug, see [50aaf7285e].

Any comments...?

fvogel added on 2019-11-23 09:40:21: (text/x-fossil-wiki)
Believe it or not, I'm seeing bind-34.3 now failing on Windows 10:

<verbatim>
==== bind-34.3 -warp works with null or negative coordinates FAILED
==== Contents of test case:

    event generate {} <Motion> -x 0 -y 0 -warp 1
    update idletasks ; # DoWarp is an idle callback
    after 50         ; # Win specific - wait for SendInput to be executed
    set res [winfo pointerxy .]
    event generate {} <Motion> -x -1 -y -1 -warp 1
    update idletasks ; # DoWarp is an idle callback
    after 50         ; # Win specific - wait for SendInput to be executed
    foreach dim [winfo pointerxy .] {
        if {$dim <= 0} {
            lappend res ok
        } else {
            lappend res $dim
        }
    }
    set res

---- Result was:
200 200 ok ok
---- Result should have been (exact matching):
0 0 ok ok
==== bind-34.3 FAILED
</verbatim>

This is because on this Win 10, the following command does not move the mouse pointer at all:

<verbatim>
    event generate {} <Motion> -x 0 -y 0 -warp 1
</verbatim>

Changing either -x or -y to anything else than 0 works. It just seems that SendInput does nothing when input.mi.dx and input.mi.dy are both zero??

The same command works on Vista.

This could be something specific to the version of Win10 I'm running, i.e. specific to Win 10 version 1803 (aka Redstone 4, build 17134.1130 from April 2018), because Harald did not report this in [https://wiki.tcl-lang.org/page/Test+Suite+Log|the test logs wiki page] for his Win10 system.

Anyone else seeing this please report with OS version details please. If it does not show up on recent Win10 versions, as I suspect, then I'll close this (again!), without fix.

fvogel added on 2019-11-19 19:29:29:
Merged by Jan into core-8-6-branch and trunk on 2019-11-15.

fvogel added on 2019-11-14 23:34:53: (text/x-fossil-wiki)
It turns out that the two last commits on this topic are not correct. Try:

<verbatim>
package require Tk
event generate {} <Motion> -warp 1 -x -1 -y -1
</verbatim>

This is supposed to move the mouse cursor at the upper left corner of the primary screen. Observed instead: the mouse cursor, but not at the expected target position.

This makes textTag-18.1 fail sometimes because the preliminary setup of this test does not result in the mouse being off the window in which one wants to observe the <Enter> and other events.

I have added test bind-34.3 that demonstrates the issue.

Reverting commits [8f767ecb] and [fc3f78ec] fixes this and lets bind-34.3 pass, indicating the cause for the issue.

I have proposed a fix, see [14a3b51a].

Impact of this should be on Windows only (not checked in practice, but the problem is in the integer arithmetics [https://core.tcl-lang.org/tk/artifact/e7bfcdb457df896f?ln=371,372|here in the windows specific code].

fvogel added on 2019-10-28 15:50:22:
Thanks for the quick feedback! I'm closing this ticket now.

oehhar added on 2019-10-28 15:31:47: (text/x-fossil-wiki)
Thank you, Francois, for the deep testing.
This is a huge work.

I have made 10 manual test runs of all binding tests with no failures.
So, the test failures are cured for me.

Test details:
I used branch [e9becf44]. This is derived from trunk, so I need TCL 8.7.
It is compiled with TCL 34ea059cbf, which is a tcl8.7 version of 2019-07-27.
I had this one ready-made on my hard disk.

And as usual: Win 10 64 bit compiled as 32 bit with MS-VC6++ PSDK2003SP1.

Thannk you,
Harald

fvogel added on 2019-10-27 14:24:26: (text/x-fossil-wiki)
We have received [https://sourceforge.net/p/tcl/mailman/message/36783632/|reports from Harald Oehlmann] stating that the tests added in the frame of fixing the present bug report could fail _sometimes_ on Win10:


<verbatim>
==== bind-34.2 -warp works relatively to the screen FAILED
==== Contents of test case:

    # Contrary to bind-34.1, we're directly checking screen coordinates
    event generate {} <Motion> -x 20 -y 20 -warp 1
    update idletasks ; # DoWarp is an idle callback
    set res [winfo pointerxy .]
    event generate {} <Motion> -x 200 -y 200 -warp 1
    update idletasks ; # DoWarp is an idle callback
    lappend res {*}[winfo pointerxy .]

---- Result was:
628 651 200 200
---- Result should have been (exact matching):
20 20 200 200
</verbatim>

After careful testing I discovered that I can reproduce failures for bind-34.1 and bind-34.2 on Win10. Most of the time these tests pass, but approximately once in 50 runs one of the two fails and shows obtained results as if the warping didn't happen (mouse cursor coordinates aren't seen as changed).

I have analyzed this a bit in depth with debug printf in the source code, and have found that even when the tests fail the warping really happens in spite of any test failure.

When 'event generating -warp', DoWarp is scheduled as an idle callback, and then the 'update idletasks' coming next in the test services this callback.

This servicing calls TkpWarpPointer, which (now) uses TkSetCursorPos to move the mouse cursor through a call to SendInput.

Even when the test fails, SendInput really is called. Warping happens, but the test doesn't see this.

Next step, SendInput is an OS function that generates an event. This event is notified by the OS to the listening client windows. All this happens very quickly but nevertheless it takes a non infinitely small amount of time, and this time is not always exactly the same. My theory is that when the test fails it is because the OS notifies Tk of the event slightly too late, which causes the test to exit with a failure because the mouse coordinates didn't change quickly enough.

To test this theory I have added a small amount of waiting time (50 ms) after each update idletasks in the concerned tests. Results show that the tests no longer fail for me on Win10 even if run hundreds of times.

This was committed as [e9becf44ab], in core-8-6-branch.

Harald, please test and report back, since you had this failure more often than me. Thanks!

fvogel added on 2019-10-11 17:09:11: (text/x-fossil-wiki)
Thanks for having dealt with this! I have seen your two successive commits [fc3f78ec] and [8f767ecb]. Not sure I understand the latter fix but fact is that bind-* tests do pass for me also on Win10.

jan.nijtmans added on 2019-10-11 08:41:04:
> I'm not very good at this kind of issues.

I am ;-).    Looks like a little rounding indeed helps. Works for me!

fvogel added on 2019-10-10 19:27:17: (text/x-fossil-wiki)
Suspecting integer arithmetics rounding errors [https://core.tcl-lang.org/tk/artifact/668aa0abaa0059b6?ln=367,368|here].

I'm not very good at this kind of issues.

fvogel added on 2019-10-10 19:06:39: (text/x-fossil-wiki)
Harald Oehlmann reports on the Tcl Core list that bind-34.2 fails for him on Windows (version? should be Win10 I think) with MS-VC6++ + PSDK2003SP1 as follows:

<verbatim>
==== bind-34.2 -warp works relatively to the screen FAILED
==== Contents of test case:

    # Contrary to bind-32.2, we're directly checking screen coordinates
    event generate {} <Motion> -x 20 -y 20 -warp 1
    update idletasks ; # DoWarp is an idle callback
    set res [winfo pointerxy .]
    event generate {} <Motion> -x 200 -y 200 -warp 1
    update idletasks ; # DoWarp is an idle callback
    lappend res {*}[winfo pointerxy .]

---- Result was:
20 19 200 200
---- Result should have been (exact matching):
20 20 200 200
==== bind-34.2 FAILED
</verbatim>

So the pointer coordinates are erroneously (20,19) when warping to (20,20), but they are correctly (200,200), when warping to (200,200). There is a difference of 1 unit, in y only, but not always. How come...? That's strange. I don't reproduce this failure on my Vista system nor on my Win10.


In parallel Jan Nijtmans reports on his side, also on the Tcl Core List, that bind-34.1 fails on Windows 10, build 17763:

<verbatim>
==== bind-34.1 -warp works relatively to a window FAILED
==== Contents of test case:

    # In order to avoid platform-dependent coordinate results due to
    # decorations and borders, this test warps the pointer twice
    # relatively to a window that moved in the meantime, and checks
    # how much the pointer moved
    wm geometry .top +200+200
    update
    event generate .top <Motion> -x 20 -y 20 -warp 1
    update idletasks ; # DoWarp is an idle callback
    set pointerPos1 [winfo pointerxy .t]
    wm geometry .top +600+600
    update
    event generate .top <Motion> -x 20 -y 20 -warp 1
    update idletasks ; # DoWarp is an idle callback
    set pointerPos2 [winfo pointerxy .t]
    # from the first warped position to the second one, the mouse
    # pointer should have moved the same amount as the window moved
    set res 1
    foreach pos1 $pointerPos1 pos2 $pointerPos2 {
        if {$pos1 != [expr {$pos2 - 400}]} {
            set res 0
        }
    }
    set res

---- Result was:
0
---- Result should have been (exact matching):
1
==== bind-34.1 FAILED
</verbatim>

I have added a bit of debug info in [2a5ba5ab] since I don't reproduce this one either (be it on Vista or Win10).

fvogel added on 2019-08-28 20:07:59:
Merged to core-8-6-branch and trunk.

marc_culler (claiming to be Marc Culler) added on 2019-08-23 13:48:10:
The two failures on macOS appear to be caused by having a non-empty value for
the DISPLAY environment variable, which is being used to set the -screen option.
Of course the environment variable is intended for X11, not Aqua,  I believe
that the -screen option should be ignored by Aqua.  But apparently it is not
being ignored.

I predict that those two tests would pass if the DISPLAY variable were unset
before runnng the tests.

I won't be able to test this, however, for several weeks.

fvogel added on 2019-08-23 06:25:33: (text/x-fossil-wiki)
OK, thanks for your tests on macOS.

Regarding tests frame-2.15 and frame-2.16, I think you addressed these failure with [73c1d599]. It's however strange for me that they fail because I think Marc Culler had zero failure on Mojave even without [73c1d599].

jan.nijtmans added on 2019-08-22 22:13:57:
Tried it on MacOS (Mojave).  Only two tests failed (frame-2.15 and frame-2.16), but those fail too without this patch.

Just for the record, those were the only 2 failing tests:

==== frame-2.15 toplevel configuration options FAILED
==== Contents of test case:

    toplevel .t -width 200 -height 100 -screen $env(DISPLAY)
    wm geometry .t +0+0
    string compare [.t configure -screen] "-screen screen Screen {} $env(DISPLAY)"

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: couldn't connect to display "/private/tmp/com.apple.launchd.vIx6IuN8mM/org.macosforge.xquartz:0"
    while executing
"toplevel .t -width 200 -height 100 -screen $env(DISPLAY)"
    ("uplevel" body line 2)
    invoked from within
"uplevel 1 $script"
---- errorCode: TK DISPLAY CONNECT
==== frame-2.15 FAILED



==== frame-2.16 toplevel configuration options FAILED
==== Contents of test case:

    toplevel .t -width 200 -height 100 -screen $env(DISPLAY)
    wm geometry .t +0+0
    .t configure -screen another

---- Result was:
couldn't connect to display "/private/tmp/com.apple.launchd.vIx6IuN8mM/org.macosforge.xquartz:0"
---- Result should have been (exact matching):
can't modify -screen option after widget is created
==== frame-2.16 FAILED

fvogel added on 2019-08-22 18:46:09:
New tests bind-32.2, bind-32.3 also pass on Linux.

Can't check on macOS right now, if someone could try for me...?

fvogel added on 2019-08-22 15:44:52: (text/x-fossil-wiki)
I noticed that the test suite had no test to check for the <code>-warp</code> correct functioning, therefore I have now added such tests in [a7cbbd2a1c].

Rennuing these new tests made me discover an error in the calculation using the new implementation for Windows, that I have fixed in [46f75c8ad3].

Tests (including bind-32.2, bind-32.3, textTag-18.1) now do pass, at least on Windows10.

ALso, I have checked that the new Windows implementation with SendInput() produces the same results as the old one that used SetCursorPos(), including in the multiple monitors case with negative screen coordinates.

fvogel added on 2019-08-20 14:48:30: (text/x-fossil-wiki)
I was a bit tired to see this test fail while waiting for a more or less hopeless fix from Microsoft (googling seems to prove there is still no such fix from them), therefore I have proposed a fix [16e230c3bf] in Tk, based on not using SetCursorPos anymore and replacing this call by SendInput.

This works well for me (on Win10): textTag-18.1 no longer fails, and there is no new failure in the test suite. Moreover, the following small test script now produces the expected very close time stamps between the Motion and Enter events:

<verbatim>
  package require Tk
  bind . <Enter> {puts "Enter: [clock milliseconds]"}
  bind . <Motion> {puts "Motion: [clock milliseconds]"}
  event generate . <Motion> -warp 1 -x 10 -y 10
</verbatim>

Any comments?

oehhar added on 2018-11-19 11:17:22: (text/x-fossil-wiki)
Within the tests of tcl8.6.9 (around 10 test runs), this test failed for all of them.

This is MS-VC6++ PSDK2003SP1, 32bit, Win PRO 10 64bit GER 2018-04.

fvogel added on 2018-10-17 21:22:55: (text/x-fossil-wiki)
We now have received conflicting reports (on the tcl-core list) about this ticket:

 - [https://sourceforge.net/p/tcl/mailman/message/36440105/|Eric] and [https://sourceforge.net/p/tcl/mailman/message/36440544/|Harald] both report that the current version of the test does PASS on Win10 (April 2018 update i.e. version 1803). And [https://sourceforge.net/p/tcl/mailman/message/36440823/|Harald] confirmed several times on the tcl-core list, based on as many runs of the test.

 - [https://sourceforge.net/p/tcl/mailman/message/36443324/|Ashok] confirms his findings below: the current version of the test does NOT pass on his Win10 box (Build 17134.345, which is another name for the April 2018 Update, aka 1803)

For me the added 'update' that went in the test to fix it on macOS (see commit [745b4344] prompted by ticket [e20d5ca7cd]) should not have been enough to fix the test on Win10 because this would not be compatible with Ashok's analysis of the root cause (a change of the Win API SetCursorPos function, that now delays  the Windows WM_MOVEMOUSE message triggering). It is also not compatible with the tests made below in this ticket: update alone was not enough to let it pass, some delay ('after 50') shall be added as well. In short, for me the test should still NOT pass and I'm puzzled with these contradictory reports.

fvogel added on 2018-06-17 12:03:44: (text/x-fossil-wiki)
From discussion in the chat: Ashok tested with the "April 2018 Update" of Windows 10 (that is build 17134) and reports that this bug is not yet fixed by Microsoft.

So let's wait and see the status in the next scheduled update (end of 2018). There already is a preview build of this update, available to MS subscribers (build 17666), if anyone has this please report.

Aside of this testing, I have found a recently posted [https://www.youtube.com/watch?v=zEXPD18zE1s|video on Youtube], that shows the problem quite well IMO.

fvogel added on 2018-06-17 07:05:42:
Is there any change on this with the "April 2018 Update" of Win 10?

fvogel added on 2018-03-04 22:04:49:
Ticket set to 'Pending' status since we're now waiting for a fix from Microsoft.

Many many thanks to Ashok for his work on this!

oehhar added on 2018-02-21 09:32:43: (text/x-fossil-wiki)
Ashok,

great that you are working on this !

I can confirm, that the bug arised with the Creators Fall Update. It was not present before. I tested with tcl 8.6.7.

Thank you,
Harald

apnadkarni added on 2018-02-21 09:10:15: (text/html)
And a Google for SetCursorPos on Windows 10 shows the following potentially relevant links:

https://discourse.libsdl.org/t/win10-fall-creators-update-breaks-mouse-warping/23526/6

https://bugs.chromium.org/p/chromium/issues/detail?id=781182#c15

https://social.msdn.microsoft.com/Forums/sqlserver/en-US/72d2c30e-0689-4c80-bf02-dcbc33b7b7de/problems-with-getcursorpos-and-setcursorpos-when-running-directx11-on-windows-10?forum=vcgeneral

https://github.com/octalmage/robotjs/issues/77

Many of these are related to the mouse position values being incorrect (which is not what we are seeing) but some details therein seem relevant. It seems clear that *something* has changed drastically in SetCursorPos. As noted in the Chromium ticket, Microsoft has indicated a fix in a future release. My inclination would be to wait and see if the problem gets fixed.

The first link also suggests a workaround using SendInput instead of SetCursorPos but given there are other reports on earlier systems that suggest the latter is better than the former makes me hesitate to try this change for fear of breaking earlier versions.

Finally, the bug reports mention Windows 10 Fall Creators edition. I wonder if anyone still is running an earlier Windows 10 edition and see if the test fails there as well. This is difficult as thanks to Microsoft's auto update.

apnadkarni added on 2018-02-21 08:38:48:
Further developments:

Adding updates and [after] delays, similar to as shown by Harald's earlier experiment, shows that the Enter event is in fact generated but the binding fires AFTER the other bindings. To reduce the noise, got rid of the tag bindings and only tracked Enter events and added time stamps. It turns out at that on earlier versions of Windows, the Enter event fires within a millisecond of the generated <Motion> event. On Win 10, it fires anywhere up to 30 ms (in my trials) after the <Motion> event.

In effect what seems to be happening is that the SetCursorPos call which triggers the Windows WM_MOVEMOUSE message does so after some delay in Windows 10 compared to earlier versions, perhaps a bug or by design (collapsing mouse movement?). The consequence is that in the test case, the WM_MOVEMOUSE message arrives "long" after the other bindings are fired and the <Enter> event binding fires last (given an addition [after 50] at the end of the test.

Harald's experimental changes that result in a PASS case can be explained by this.

A quick experiment:

(win) 50 % bind . <Enter> {puts "Enter: [clock milliseconds]"}
(win) 51 % bind . <Motion> {puts "Motion: [clock milliseconds]"}
(win) 52 % event gen . <Motion> -warp 1 -x 10 -y 10
Motion: 1519202197166
Enter: 1519202197172

Again, *after* moving the mouse out of the . toplevel:

(win) 53 % event gen . <Motion> -warp 1 -x 10 -y 10
Motion: 1519202204446
Enter: 1519202204467

The same code on Win 7 shows 0/1 ms between the time stamps.

apnadkarni added on 2018-02-21 07:55:27:
Just some notes on the code path for future reference. These may or may not be relevant for the issue being investigated:

The event generation commands invoke the <Motion> event handler code *synchronously* due to the lack of a -when option.

The motion event handler then queues a DoWarp through the *idle* event queue. Note unlike the Motion events, this is not synchronous.

DoWarp in turn uses the Win32 API SetCursorPos to set the mouse position.

This in turn results in Windows generating a WM_MOUSEMOVE event. This is handled in the Tk message loop and gets translated into first an <Enter> event.

Thus bind scripts fire in the order <Motion> (synchronous call from event gen) followed by <Enter> (via Idle loop->DoWrap/SetCursorPos->Windows message loop->Enter). This differs from real user interaction in that in the latter case, the <Enter> event fires before the <Motion> event. However, for the purpose of this test I do not think this matters as the test comparisons do not look at <Motion> events at all.

fvogel added on 2018-02-17 13:40:41:
apn was kind enough to test and report the following on Win 10 Pro: textTag-18.1 fails on all the following variations:

With VS 2017 x64:
 - Tcl/Tk 8.6.8
 - core-8-6-branch
 - Tcl/Tk 8.6.7
 - Tcl/Tk 8.6.4
 - Tcl/Tk 8.6.3

With VC 6 x86:
 - Tcl/Tk 8.6.0
 - Tcl/Tk 8.5.19

From that I conclude that something changed in Windows 10, not in Tcl/Tk, and this something needs to be understood IMO since it now delays *some* events, but not all.

oehhar added on 2018-02-06 13:33:01: (text/x-fossil-wiki)
Booted my old Laptop with Vista and bouble-checked the test suite for tcl/tk 8.6.8 [http://wiki.tcl.tk/37529].

On Tk there are no failing tests at all.

oehhar added on 2018-02-05 17:38:00: (text/x-fossil-wiki)
Francois,

thank you for the questions.

> Let's sum up what we know at this point:

> 1. Test textTag-18.1:

>     ~ fails for you on Windows 10 Pro 64 bit GER, MSVC6++, Platform SDK 2003SP1, Makfile.vc, build option:threads 

>     ~ passes for you on Windows Vista Pro 32 bit GER, MSVC6++, Platform SDK 2003SP1, Makfile.vc 

> Could this be due to the build option:threads in the Win10 build you created? Could you try without this option?

It is always build with threads enabled. Remark also, that both builds are 32 bit.
Sorry, so I did not try without the option ``threads''. If you insist, I will do it.

> 3. You mentioned that 'add "after 50;update" after the last event gen -> the lost "Enter-event" fires at the end'. This is very strange. In this test, could you confirm that the result really was:

> {{25 25 tag-Enter} {20 20 tag-Leave} {25 25 tag-Enter} Enter}

yes

> And, with my instrumented test version, that it was:

> {Motion_0,0 Motion_10,10 Motion_25,25 {25 25 tag-Enter} Motion_20,20 {20 20 tag-Leave} Motion_10,10 Motion_25,25 {25 25 tag-Enter} Enter}

<verbatim>
==== textTag-18.1 TkTextPickCurrent tag bindings FAILED
==== Contents of test case:

    text .t -width 30 -height 4 -relief sunken -borderwidth 10  -highlightthickness 10 -pady 2
    pack .t

    .t insert end " Tag here " TAG " no tag here"
    .t tag configure TAG -borderwidth 4 -relief raised
    .t tag bind TAG <Enter>  {lappend res "%x %y tag-Enter"}
    .t tag bind TAG <Leave>  {lappend res "%x %y tag-Leave"}
    bind .t <Enter> {lappend res Enter}
    bind .t <Leave> {lappend res Leave}

    set res {}
    # Bindings must not trigger on the widget border, only over
    # the actual tagged characters themselves.
lappend res [font actual [.t cget -font]]
    lappend res Motion_0,0   ; event gen .t <Motion> -warp 1 -x 0  -y 0  ; update
    lappend res Motion_10,10 ; event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
    lappend res Motion_25,25 ; event gen .t <Motion> -warp 1 -x 25 -y 25 ; update
    lappend res Motion_20,20 ; event gen .t <Motion> -warp 1 -x 20 -y 20 ; update
    lappend res Motion_10,10 ; event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
    lappend res Motion_25,25 ; event gen .t <Motion> -warp 1 -x 25 -y 25 ; update
        after 50;update
        return $res

---- Result was:
{-family {Courier New} -size 10 -weight normal -slant roman -underline 0 -overstrike 0} Motion_0,0 Motion_10,10 Motion_25,25 {25 25 tag-Enter} Motion_20,20 {20 20 tag-Leave} Motion_10,10 Motion_25,25 {25 25 tag-Enter} Enter
---- Result should have been (exact matching):
Enter {25 25 tag-Enter} {20 20 tag-Leave} {25 25 tag-Enter}
==== textTag-18.1 FAILED
</verbatim>

> How is this possible? This "Enter" event generated by the first "event generate" at position -x 0 -y 0 would be blocked in the event loop whereas the "Enter" and "Leave" events from tags would trigger??

It looks like.

> 4. You said that making the following change:

>    event gen .t <Motion> -warp 1 -x 0 -y 0 ; update
>    event gen .t <Motion> -warp 1 -x 10 -y 10 ; update;after 50;update

> makes it pass. This also looks very strange. The "Enter" event is generated by the first of the above two > lines, not by the second one. So can you check if the test also pass when you write:

>    event gen .t <Motion> -warp 1 -x 0 -y 0 ; update;after 50;update
>    event gen .t <Motion> -warp 1 -x 10 -y 10 ; update

No, this does not help with the originaly test. But if an "update" is also inserted after "set res {}" (as in current trunk), then it passes with this modification.

But putting only "update;after 50;update" after "set res {}" will not help.

So:
Pass:
<verbatim>
    set res {}
    # Bindings must not trigger on the widget border, only over
    # the actual tagged characters themselves.
    event gen .t <Motion> -warp 1 -x 0 -y 0 ; update
    event gen .t <Motion> -warp 1 -x 10 -y 10 ; update;after 50;update
</verbatim>
Fail:
<verbatim>
    set res {}
    # Bindings must not trigger on the widget border, only over
    # the actual tagged characters themselves.
    event gen .t <Motion> -warp 1 -x 0 -y 0 ; update;after 50;update
    event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
</verbatim>
Pass:
<verbatim>
    set res {}
    update
    # Bindings must not trigger on the widget border, only over
    # the actual tagged characters themselves.
    event gen .t <Motion> -warp 1 -x 0 -y 0 ; update;after 50;update
    event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
</verbatim>
Fail:
<verbatim>
    set res {}
    update;after 50;update
    # Bindings must not trigger on the widget border, only over
    # the actual tagged characters themselves.
    event gen .t <Motion> -warp 1 -x 0 -y 0 ; update
    event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
</verbatim>

> 5. With no added "after 50;update" at all, does the test pass if you add "focus -force .t" right between "pack .t" and "update ; # map the window ..." ?

The trunk version (one update more) fails:
<verbatim>
    text .t -width 30 -height 4 -relief sunken -borderwidth 10 \
      -highlightthickness 10 -pady 2
    pack .t
	focus -force .t
    update ; # map the window, otherwise -warp can't be done
    
    .t insert end " Tag here " TAG " no tag here"
    .t tag configure TAG -borderwidth 4 -relief raised
    .t tag bind TAG <Enter>  {lappend res "%x %y tag-Enter"}
    .t tag bind TAG <Leave>  {lappend res "%x %y tag-Leave"}
    bind .t <Enter> {lappend res Enter}
    bind .t <Leave> {lappend res Leave}

    set res {}
    # Bindings must not trigger on the widget border, only over
    # the actual tagged characters themselves.
    event gen .t <Motion> -warp 1 -x 0 -y 0 ; update
    event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
    event gen .t <Motion> -warp 1 -x 25 -y 25 ; update
    event gen .t <Motion> -warp 1 -x 20 -y 20 ; update
    event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
    event gen .t <Motion> -warp 1 -x 25 -y 25 ; update
    return $res
}
</verbatim>

> 6. With no added "after 50;update" at all, does the test pass if you add "focus -force .t ; update" right between "pack .t" and "update ; # map the window ..." ?

fails too

7. Could you build the revised_text Tk branch and try this test on your Win 10? This is to check whether some issue of the legacy text widget got perhaps fixed in the revised version. 

[https://core.tcl.tk/tk/info/c410f6f0450b2d40]

<verbatim>
nmake -f makefile.vc release test TCLDIR=c:\test\tcl8.6.8 TESTFLAGS="-file textTag.test"
...
Tests began at Mon Feb 05 18:35:42 +0100 2018
textTag.test


==== textTag-18.1 TkTextPickCurrent tag bindings FAILED
==== Contents of test case:

    text .t -width 30 -height 4 -relief sunken -borderwidth 10  -highlightthickness 10 -pady 2
    pack .t

    .t insert end " Tag here " TAG " no tag here"
    .t tag configure TAG -borderwidth 4 -relief raised
    .t tag bind TAG <Enter>  {lappend res "%x %y tag-Enter"}
    .t tag bind TAG <Leave>  {lappend res "%x %y tag-Leave"}
    bind .t <Enter> {lappend res Enter}
    bind .t <Leave> {lappend res Leave}

    set res {}
    update
    # Bindings must not trigger on the widget border, only over
    # the actual tagged characters themselves.
    event gen .t <Motion> -warp 1 -x 0 -y 0 ; update
    event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
    event gen .t <Motion> -warp 1 -x 25 -y 25 ; update
    event gen .t <Motion> -warp 1 -x 20 -y 20 ; update
    event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
    event gen .t <Motion> -warp 1 -x 25 -y 25 ; update
    return $res

---- Result was:
{25 25 tag-Enter} {20 20 tag-Leave} {25 25 tag-Enter}
---- Result should have been (exact matching):
Enter {25 25 tag-Enter} {20 20 tag-Leave} {25 25 tag-Enter}
==== textTag-18.1 FAILED


Tests ended at Mon Feb 05 18:35:43 +0100 2018
</verbatim>

fvogel added on 2018-02-04 20:43:22: (text/x-fossil-wiki)
Thank you for your clear answer.

The failure must not be due to processing of warping at idle time. Calling 'update' processes the idle callbacks as well if I understand the man page correctly. And if processing at idle time would be the issue, then we would have problems with all the "event generate" lines, not just the first one.

This is really puzzling to me, and I'm slowly running out of ideas about what's going on here. The fact that I cannot reproduce (I have no Win10) does not favour quick fixing.

Let's sum up what we know at this point:

1. Test textTag-18.1:

  ~ fails for you on Windows 10 Pro 64 bit GER, MSVC6++, Platform SDK 2003SP1, Makfile.vc, build option:threads

  ~ passes for you on Windows Vista Pro 32 bit GER, MSVC6++, Platform SDK 2003SP1, Makfile.vc

Could this be due to the build option:threads in the Win10 build you created? Could you try without this option?

3. You mentioned that '<i>add "after 50;update" after the last event gen -> the lost "Enter-event" fires at the end</i>'. This is very strange. In this test, could you confirm that the result really was:
<verbatim>
{{25 25 tag-Enter} {20 20 tag-Leave} {25 25 tag-Enter} Enter}
</verbatim>
And, with my instrumented test version, that it was:
<verbatim>
{Motion_0,0 Motion_10,10 Motion_25,25 {25 25 tag-Enter} Motion_20,20 {20 20 tag-Leave} Motion_10,10 Motion_25,25 {25 25 tag-Enter} Enter}
</verbatim>
How is this possible? This "Enter" event generated by the first "event generate" at position -x 0 -y 0 would be blocked in the event loop whereas the "Enter" and "Leave" events from tags would trigger??

4. You said that making the following change:
<verbatim>
    event gen .t <Motion> -warp 1 -x 0 -y 0 ; update
    event gen .t <Motion> -warp 1 -x 10 -y 10 ; update;after 50;update
</verbatim>
makes it pass. This also looks very strange. The "Enter" event is generated by the first of the above two lines, not by the second one. So can you check if the test also pass when you write:
<verbatim>
    event gen .t <Motion> -warp 1 -x 0 -y 0 ; update;after 50;update
    event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
</verbatim>

5. With no added "after 50;update" at all, does the test pass if you add "focus -force .t" right between "pack .t" and "update ; # map the window ..." ?

6. With no added "after 50;update" at all, does the test pass if you add "focus -force .t ; update" right between "pack .t" and "update ; # map the window ..." ?

7. Could you build the revised_text Tk branch and try this test on your Win 10? This is to check whether some issue of the legacy text widget got perhaps fixed in the revised version.

oehhar added on 2018-02-01 21:04:13: (text/x-fossil-wiki)
 Francois,

thank you for the message. I try, in detail, answer your two questions below. The result is always a failing test.

Sorry, no other ideas about that.
Harald

<h1>Q1: Are you absolutely sure it does not pass simply by addition of "update" after packing .t?</h1>

<h2>Modify 8.6.8 distribution</h2>

   *   take tcl/tk8.6.8 distribution
   *   insert line 1558 into "textTag.test" with "update" 

<verbatim>
--- C:/test/tk8.6.8/tests/textTag.test.ori	Wed Dec 06 16:25:08 2017
+++ C:/test/tk8.6.8/tests/textTag.test	Thu Feb 01 14:43:47 2018
@@ -1751,14 +1751,15 @@
     .t tag configure TAG -borderwidth 4 -relief raised
     .t tag bind TAG <Enter>  {lappend res "%x %y tag-Enter"}
     .t tag bind TAG <Leave>  {lappend res "%x %y tag-Leave"}
     bind .t <Enter> {lappend res Enter}
     bind .t <Leave> {lappend res Leave}
 
     set res {}
+    update
     # Bindings must not trigger on the widget border, only over
     # the actual tagged characters themselves.
     event gen .t <Motion> -warp 1 -x 0 -y 0 ; update
     event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
     event gen .t <Motion> -warp 1 -x 25 -y 25 ; update
     event gen .t <Motion> -warp 1 -x 20 -y 20 ; update
     event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
</verbatim>

   *    Run test 

<verbatim>
nmake -f makefile.vc test TCLDIR=c:\test\tcl8.6.8 TESTFLAGS="-files texttag.test"
...
---- Result was:
{25 25 tag-Enter} {20 20 tag-Leave} {25 25 tag-Enter} Enter
---- Result should have been (exact matching):
Enter {25 25 tag-Enter} {20 20 tag-Leave} {25 25 tag-Enter}
==== textTag-18.1 FAILED
</verbatim>

<h2>copy in trunk test file</h2>

   *   take tcl/tk8.6.8 distribution
   *   copy file "textTag.test" from trunk [db04f1ae] to "textTagTrunk.test" 

<verbatim>
nmake -f makefile.vc test TCLDIR=c:\test\tcl8.6.8 TESTFLAGS="-file texttagtrunk.test"
...
---- Result was:
{25 25 tag-Enter} {20 20 tag-Leave} {25 25 tag-Enter}
---- Result should have been (exact matching):
Enter {25 25 tag-Enter} {20 20 tag-Leave} {25 25 tag-Enter}
==== textTag-18.1 FAILED
</verbatim>

<h1>Q2:Does it happen with current branch "core-8-6-branch"?</h1>

   *   Take tcl 8.6.8 distribution
   *   Take Tk [745b4344]
   *   Compile and run texttag test file 

<verbatim>
C:\test\tk-745b4344\win>nmake -f makefile.vc release test TCLDIR=c:\test\tcl8.6.8 TESTFLAGS="-file texttag.test"
...
---- Result was:
{25 25 tag-Enter} {20 20 tag-Leave} {25 25 tag-Enter}
---- Result should have been (exact matching):
Enter {25 25 tag-Enter} {20 20 tag-Leave} {25 25 tag-Enter}
==== textTag-18.1 FAILED
</verbatim>

fvogel added on 2018-01-28 22:09:29: (text/x-fossil-wiki)
Are you absolutely sure it does not pass simply by addition of "update" after packing .t?

See [e20d5ca7cd]: the -warp is ignored when the window is not mapped. This is now fixed in core-8-6-branch (and trunk)

Could you please test again in the vanilla bleeding-edge core-8-6-branch?

Pecause after studying the [https://core.tcl.tk/tk/artifact/1baa549b0a06a428?ln=3452,3474|relevant code] I don't see why this test would still fail for you. I must be missing something, but what??

Could the fact that warping is processed at idle time be a problem?

oehhar added on 2018-01-15 08:03:04: (text/x-fossil-wiki)
Hi Francois,
thank you for the homework.
Nice catch with MacOS ;-)

<h1>Add additional update in test</h1>

Ticket [f5903b29] includes an update just before the event generate sequence.
This is to cure the same phenomenon on Mac-OS.

This modification does not make the test pass for me.

I have tested the whole test file from trunk ([d1cee38d] ) and only to insert this line.

<h1>Does the "Enter"-event disappear or is it delayed</h1>

Tests to check, if the Enter-event is just delivered later:

   *   add "update;update;update" after the last event gen -> no change
   *   add "after 50;update" after the last event gen -> the lost "Enter-event" fires at the end

<h2>Test enhancement with event ordering test and font check</2>

Result is:
<verbatim>
{-family {Courier New} -size 10 -weight normal -slant roman -underline 0 -overstrike 0} Motion_0,0 Motion_10,10 Motion_25,25 {25 25 tag-Enter} Motion_20,20 {20 20 tag-Leave} Motion_10,10 Motion_25,25 {25 25 tag-Enter}
</verbatim>

Thank you,
Harald

fvogel added on 2018-01-14 19:39:46: (text/x-fossil-wiki)
OK.

I have seen this before, but only for macOS: [e20d5ca7cd].

I could fix this by [f5903b29]. This fix is in trunk and revised_text only (the test failed on macOS in trunk and revised_text only, not in core-8-6-branch, for an unknown reason). It seems your Win10 OS now exposes the same problem of unreliability of this test textTag-18.1.

So I would like you to try two things:

1. Apply [f5903b29] in your 8.6.8 version and provide test result.

2. If step 1. does not resolve the problem, apply the following patch and provide the result of the test.

<verbatim>
Index: tests/textTag.test
==================================================================
--- tests/textTag.test
+++ tests/textTag.test
@@ -1755,16 +1755,17 @@
     bind .t <Leave> {lappend res Leave}

     set res {}
     # Bindings must not trigger on the widget border, only over
     # the actual tagged characters themselves.
-    event gen .t <Motion> -warp 1 -x 0 -y 0 ; update
-    event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
-    event gen .t <Motion> -warp 1 -x 25 -y 25 ; update
-    event gen .t <Motion> -warp 1 -x 20 -y 20 ; update
-    event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
-    event gen .t <Motion> -warp 1 -x 25 -y 25 ; update
+    lappend res [font actual [.t cget -font]]
+    lappend res Motion_0,0   ; event gen .t <Motion> -warp 1 -x 0  -y 0  ; update
+    lappend res Motion_10,10 ; event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
+    lappend res Motion_25,25 ; event gen .t <Motion> -warp 1 -x 25 -y 25 ; update
+    lappend res Motion_20,20 ; event gen .t <Motion> -warp 1 -x 20 -y 20 ; update
+    lappend res Motion_10,10 ; event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
+    lappend res Motion_25,25 ; event gen .t <Motion> -warp 1 -x 25 -y 25 ; update
     return $res
 } -cleanup {
     destroy .t
 } -result {Enter {25 25 tag-Enter} {20 20 tag-Leave} {25 25 tag-Enter}}
</verbatim>

oehhar added on 2018-01-14 16:26:53: (text/x-fossil-wiki)
I have no clue neither.

Nevertheless, I had the observation (by manual operation), that the "Enter"-event may appear after different moveto-commands.

Si it might be beneficial for the test, to also check which event fires after which command.

E.G. something like:
<verbatim>
    lappend res M00 ; event gen .t <Motion> -warp 1 -x 0 -y 0 ; update
    lappend res M10-10 ; event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
    lappend res M2525 ; event gen .t <Motion> -warp 1 -x 25 -y 25 ; update
    lappend res M2020 ; event gen .t <Motion> -warp 1 -x 20 -y 20 ; update
    lappend res M1010 ; event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
    lappend res M2525 ; event gen .t <Motion> -warp 1 -x 25 -y 25 ; update</verbatim>

and insert the appended values to the result...

Just a thought, not important, but eventually to find a clue what is really happenning...

fvogel added on 2018-01-13 10:17:40:
So this is not a regression.

Root cause is an unreliable test, or perhaps an underlying OS behaviour change.

Before applying the suggested additional "after 50; update" I really would like to understand what's wrong with the current version of the test, and why it passes on all Linuxes, and on Vista and Win7 but no longer on Win10 (whatever the Tk version is).

Any idea?

oehhar added on 2018-01-09 21:44:18: (text/x-fossil-wiki)
I repeated with 8.6.7 today:

   *   test now fails !
   *   may also be cured by "after 50;update"

Sorry,
Harald

oehhar added on 2018-01-09 14:27:53: (text/x-fossil-wiki)
Thank you for the remarks:

<h1>Initial mouse cursor position</h1>

<verbatim>
nmake -f makefile.vc test TCLDIR=c:\test\tcl8.6.8 TESTFLAGS="-verbose bte -file textTag.test -match textTag-18.1"
</verbatim>

The test fails for me independent on the initial mouse position. After the test, the mouse is located up-left.
The test is up-left. The terminal is bottom-right.
When I put the mouse top-left or bottom-right before starting the test, it always fails.

<h1>Other observations</h1>

The line in the setup:
<verbatim>
event generate {} <Motion> -warp 1 -x -1 -y -1; update
</verbatim>
goes to position -1,-1. This position may only exist in a two screen setup.
This time, I tried the tests in a single screen setup.

So, I try to move it out somewhere on the screen:
<verbatim>
event generate {} <Motion> -warp 1 -x [expr [winfo screenwidth .]-1] -y [expr [winfo screenheight .]-1]; update
</verbatim>
This did not help.

Then I tried Brians proposition:
insert the following in Line 1756 of texttag.test:
<verbatim>
event gen .t <Motion> -warp 1 -x 0 -y 0 ; update ;# Initialize pointer location.
</verbatim>

Still same result.

Then I tried to move Brians line above the bind commands in Line 1754 and 1752, same result.

As the initial "Enter" event to the text widget is missing, I tried to make manual tests with wish 8.6.7 and wish8.6.8:
<verbatim>
% text .t -width 30 -height 4 -relief sunken -borderwidth 10 \
      -highlightthickness 10 -pady 2
.t
% pack .t
% .t insert end " Tag here " TAG " no tag here"
% .t tag configure TAG -borderwidth 4 -relief raised
% bind .t <Enter> {puts Enter}
% event gen .t <Motion> -warp 1 -x -1 -y -1
% event gen .t <Motion> -warp 1 -x 0 -y 0
Enter
% event gen .t <Motion> -warp 1 -x 10 -y 10
</verbatim>

The text "Enter" is only outputted in tk8.6.7, not in tk8.6.8.
When I manually move into the widget with the mouse, the text is shown in both versions.
When I then repeat the event generate commands, it works again for both versions.

It turned out, that speed is crucial, e.g. how quick you type. It is crucial for tcl8.6.7 and 8.6.8, so the manual test is instable for both versions.

I tried to add "tkwait visibility .t", or "after 50;update" at any place. It turned out, that modifying line 1761 as follows let pass the test for me:
<verbatim>
    event gen .t <Motion> -warp 1 -x 10 -y 10 ; update;after 50;update
</verbatim>

The modified whole test body:
<verbatim>
    text .t -width 30 -height 4 -relief sunken -borderwidth 10 \
      -highlightthickness 10 -pady 2
    pack .t
    
    .t insert end " Tag here " TAG " no tag here"
    .t tag configure TAG -borderwidth 4 -relief raised
    .t tag bind TAG <Enter>  {lappend res "%x %y tag-Enter"}
    .t tag bind TAG <Leave>  {lappend res "%x %y tag-Leave"}
    bind .t <Enter> {lappend res Enter}
    bind .t <Leave> {lappend res Leave}

    set res {}
    # Bindings must not trigger on the widget border, only over
    # the actual tagged characters themselves.
    event gen .t <Motion> -warp 1 -x 0 -y 0 ; update
    event gen .t <Motion> -warp 1 -x 10 -y 10 ; update;after 50;update
    event gen .t <Motion> -warp 1 -x 25 -y 25 ; update
    event gen .t <Motion> -warp 1 -x 20 -y 20 ; update
    event gen .t <Motion> -warp 1 -x 10 -y 10 ; update
    event gen .t <Motion> -warp 1 -x 25 -y 25 ; update
    return $res
</verbatim>

I hope this helps to find the issue.