Tk Source Code

The reason for the test failures is straightforward.  The failing tests use dobg,
which uses popen to create a Tcl interpreter running in a new process.  But the
mac port does not support embedding windows into containers created in a
different process.  It does support embedding windows into containers created
by a different interpreter running in the same process.  So what is needed is to
write variants of these failing tests which use a slave interpreter rather than
call dobg.

Changing the title of this ticket since unixEmbed-7.1 is the remaining issue
on all platforms - it fails on linux and tests a function which is not
implemented on the others.

unixEmbed-7.1a was constrained to {unix notAqua} in [02ca3773].

Branch bug-58665b91dd is left open to deal with comments below from Marc.

The current tip de9ae7135b of bug-58665b91dd passes all unixEmbed tests except for 7.1 and 7.1a (plus 9.2 on unix).

The test unixEmbed-7.1 and its slave interpreter variant 7.1a are meant to test whether the function TkpForwardKeyEvent correctly forwards key events to the container window in the case where the embedded window does not have focus. In fact, however, TkpForwardKeyEvent is implemented as a no-op on macOS or Windows, so it could not correctly forward events on those platforms. There is an implementation on unix. However, on both unix and macOX the TkpForwardKeyEvent function is never called during the tests 7.1, 7.1a, 7.2, or 7,2a which are supposed to be testing it. This is possibly related to other issues related to focusing windows and may indicate bugs in the generic code.

I planning to merge the bug-58665b91dd branch, leaving these failing tests in place and leaving this ticket open until we better understand why TkpForwardKeyEvent does not get called, even on unix.

The analysis below turned out to be wrong.  There were configure events being
generated, but not the ones that the test is looking for.  Fixing this required
some changes to the place manager.  These changes are include in [c22c402b] and
(for macOS) [d58bb5c5].  The platform specific changes for unix and macOS will
also be replicated for Windows in a future commit.

My tests indicate that the <Configure> event which the unixEmbed-6.2a test
expects to see is, in fact, being generated.

There is a common feature in tests unixEmbed-6.2a and unixEmbed-7.1a.  In both
cases a slave interpreter binds an event to a command which writes to a
variable. Then a command is executed within the slave interpreter which
generates that event.  The test evaluates the variable in the call to
slave eval to see whether the event was processed.  In both of those tests the
answer is no: the variable is empty, indicating that the event was not
processed.  This is the case on both macOS and unix. Both OS's fail those two
tests in exactly the same way - the test variable is empty.  But independent
testing indicates that the events (in 6.2a at least) are in fact being
generated correctly.

I suspect that the reason the events do not get processed within the eval
command has something to do with how slave interpreters interact with the
event loop.  But it must be subtle, since unixEmbed-6.1a does something almost
identical to what unixEmbed-6.2a does, yet it still passes.

It's true that on Mojave unixEmbed-5.3a now passes (and unixEmbed-7.2a as well BTW), however unixEmbed-8.1a now fails for me.

unixEmbed-5.3a now passes on Mojave.

About unixEmbed-6.2a:

Actually instrumentation on macOS shows that, contrary to what I said below, Tk_GeometryRequest really calls the requestProc. That requestProc is TopLevelReqProc, which in turn schedules an idle call to UpdateGeometryInfo.

unixEmbed-5.1a now passes on Linux with [10c6a3f1].

Analysis of unixEmbed-6.2a failure seems to show that the Configure event is not triggered by .t1 configure -width 300 -height 120 because the .t1 toplevel already has the reqwidth/height. This code prevents it.

I could let unixEmbed-3.2 pass by adding update commands in that test.

Also I could reduce the number of failures on Linux by propagating changes in TkpTestembedCmd to the unix version of it.

At [2fc0a92e], status of failing unixEmbed-* tests as I see it is as follows:

• Linux Debian 8: 2.4, 5.1a, 6.2a, 7.1a
• macOS Mojave: 5.3a, 6.2a, 7.1a, 7.2a
• Windows: no failure (all tests are skipped)

Probably the Linux new failures from the unixEmbed.test file can be fixed by propagating the changes in TkpTestembedCmd fom macosx/tkMacOSXEmbed.c to the unix version of it in unix/tkUnixEmbed.c

That bugfix branch bug-58665b91dd got merged to core-8-6-branch and trunk, and the branch was closed.

Not sure what the status of unixEmbed-3.2 currently is.

I still see several unixEmbed-* failures on macOS.

On Linux Debian 8 I see new failures (previously only unixEmbed-9.2 failed).

I have already sent all logs by private email.

The bug-58665b91dd branch adds tests that use slave interpreters and marks the
tests which call dobg as notAqua.  The testembed function is modified to provide
more appropriate support for the tests on macOS.  (In particular, on macOS there
are no wrappers for toplevel windows, so the wrapper ID is set to the empty
string and tests that check this are adjusted.)

The unixEmbed-3.2 test still fails, but that appears to be identifying a genuine
bug with the way that the geometry command works with an embedded window on the
mac.