Tk Source Code

View Ticket
Login
Bounty program for improvements to Tcl and certain Tcl packages.
Tcl 2018 Conference, Houston/TX, US, Oct 15-19
Send your abstracts to tclconference@googlegroups.com
or submit via the online form by Aug 20.
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: Pending Last Modified: 2018-06-17 12:03:44
Resolution: None Closed By: nobody
    Closed on:
Description:

Initial report:

textTag-18.1 failed for 8.6.8 as with the rc.

Here is the log:

==== 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
  • 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:
nmake -f makefile.vc test TCLDIR=c:\test\tcl8.6.8 TESTFLAGS="-verbose bte" > testlog_tk8.6.8.txt 2>&1

Remark by Francois

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:

==== 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

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

Comment by Brian

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:

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

I would try changing the test:

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.

User Comments: fvogel added on 2018-06-17 12:03:44:

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 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:

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:

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:

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:

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}

==== 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

> 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:

    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
Fail:
    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
Pass:
    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
Fail:
    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

> 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:

    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
}

> 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

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


fvogel added on 2018-02-04 20:43:22:

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 '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}
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}
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:

    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

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:

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

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

Modify 8.6.8 distribution

  • take tcl/tk8.6.8 distribution
  • insert line 1558 into "textTag.test" with "update"
--- 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
  • Run test
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

copy in trunk test file

  • take tcl/tk8.6.8 distribution
  • copy file "textTag.test" from trunk [db04f1ae] to "textTagTrunk.test"
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

Q2:Does it happen with current branch "core-8-6-branch"?

  • Take tcl 8.6.8 distribution
  • Take Tk [745b4344]
  • Compile and run texttag test file
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


fvogel added on 2018-01-28 22:09:29:

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 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:

Hi Francois, thank you for the homework. Nice catch with MacOS ;-)

Add additional update in test

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.

Does the "Enter"-event disappear or is it delayed

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

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

Result is:

{-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}

Thank you, Harald


fvogel added on 2018-01-14 19:39:46:

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.

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}}


oehhar added on 2018-01-14 16:26:53:

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:

    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

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:

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:

Thank you for the remarks:

Initial mouse cursor position

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

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.

Other observations

The line in the setup:

event generate {} <Motion> -warp 1 -x -1 -y -1; update
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:

event generate {} <Motion> -warp 1 -x [expr [winfo screenwidth .]-1] -y [expr [winfo screenheight .]-1]; update
This did not help.

Then I tried Brians proposition: insert the following in Line 1756 of texttag.test:

event gen .t <Motion> -warp 1 -x 0 -y 0 ; update ;# Initialize pointer location.

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:

% 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

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:

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

The modified whole test body:

    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

I hope this helps to find the issue.