Tk Source Code

In EntryElementDraw() (near ttkMacOSXTheme.c:2126)

    if ([NSApp macOSVersion] > 100800) {
	BEGIN_DRAWING(d)
	    switch(kind) {
	    case kHIThemeFrameTextFieldRound:
		DrawEntry(dc.context, bounds, &searchDesign, state, tkwin);
		break;
	    case kHIThemeFrameTextFieldSquare:
		DrawEntry(dc.context, bounds, &entryDesign, state, tkwin);
		break;
	    default:
		return;
	    }
	END_DRAWING
    } else {

I am not aware of a trigger for this code path, but in the default case, is it a bug to return before END_DRAWING?

Thanks for getting this fixed. I neglected to comment here about the bug-1c9965ca-c86b and bug-1c9965ca-c90b branches I proposed. However I would still suggest for anyone interested in a ticket to have a look at its timeline view (with "info" in the URL, as opposed to the non-timeline view with "tktview" in the URL) for a better idea of any related activity.

I have merged this patch into core-9-1-branch, core-9-0-branch and
core-8-6-branch.  So I am closing the ticket.

Thanks Serhiy!

I see that the failure of font-17.5 was addressed today in [bf9aef00].
So I will go ahead and merge this.

Well, the CI run failed because tests font-17.5 and button-16.1 failed.
The failure of font-17.1 has been reported by Torsten Berg on the core list
and the failure of button-16.1 has apparently been addressed. I do not
see font-17.1 failing on my machine, which indicates to me that it is a
sporadic failure, probably caused by a race condition.  I am sure it is
not related to this patch.  So I think it is safe to merge this.

button-16.1 is the test for [1100518], not related to this patch. On Aqua pressing a button does not change its relief (the pressed state is drawn natively), but the test expected "sunken". Fixed in [810f018b3d] (main), [bc39b6753a] (9.0) and [a1edb3c002] (8.6).

I have to correct my statement that I saw no unexpected test errors.
There was one which I have not seen before:

==== button-16.1 button keeps -overrelief after click, Bug 1100518 FAILED
==== button-16.1 FAILED

I doubt that this patch could affect button tests.

Does anyone know anything about that failure?

This looks correct.  I guess the CI will run tonight.  Assuming the CI run
is OK (which it should be - I saw no unexpected test failures on my machine),
I think this can be merged.

Both are bugs: TkMacOSXRestoreDrawingContext() pops the graphics state pushed by TkMacOSXSetupDrawingContext(), releases the clip region and schedules the update of the view, so returning without it leaves an extra saved graphics state, leaks the clip region and misses the update.

A search for other returns between a successful TkMacOSXSetupDrawingContext() and TkMacOSXRestoreDrawingContext() found one more: XCopyArea() (tkMacOSXImage.c) returns BadDrawable without restoring the context if it has no CGContext.

Proposed fix in branch macos-restore-drawing-context: break instead of return in EntryElementDraw(), and restoring the context before returning in TkpDrawAngledCharsInContext() and XCopyArea(). Not tested on macOS.

Hi,
would it be possible to go a little bit further with those findings?

best regards,
nicolas

Spotted another likely instance of this issue in TkpDrawAngledCharsInContext() (tkMacOSXFont.c:1340):

    if (…
	    || !TkMacOSXSetupDrawingContext(drawable, gc, &drawingContext)) {
	return;
    }
    string = [[TKNSString alloc] initWithTclUtfBytes:source length:numBytes];
    if (!string) {
	return;
    }

That looks like a bug to me.