Overview
Artifact ID: | ccba653749a014cbc90b9241f89cc8def3b24febdea078aedae41049f70ac2e9 |
---|---|
Ticket: | b947864419c55e7278b87fcc9d701a914cb7914a
clipboard-4.1, -4.2, -4.4 fail on macOS |
User & Date: | fvogel 2018-07-08 20:20:14 |
Changes
- assignee changed to: "fvogel"
- icomment:
All these three tests fail because the last statement <b>"clipboard get"</b> returns an empty string instead of the expected error <b>"CLIPBOARD selection doesn't exist or form "STRING" not defined"</b>. An instrumented interactive test session provides some insight: <verbatim> % clipboard clear TkClipInit: clipboardActive set to FALSE Tk_ClipboardClear: clipboardActive is FALSE XSetSelectionOwner: clipboardActive is FALSE, changing owner Tk_ClipboardClear: clipboardActive set to TRUE % clipboard append Test Tk_ClipboardAppend: clipboardActive is TRUE % selection clear -selection CLIPBOARD XSetSelectionOwner: clipboardActive is TRUE ClipboardLostSel: clipboardActive set to FALSE % puts "!![clipboard get]!!" Tk_GetSelection: entering Tk_GetSelection: selection owned by some other process TkSelGetSelection: entering tkProvidePasteboard: clipboardActive is FALSE TkSelGetSelection: before calling proc, string is !!!! !!!! % </verbatim> <i>(Note that testing this clipboard feature is prone to errors: you must either run the test from the test suite, or type everything by hand (as opposed to copy/pasting) otherwise the clipboard soon gets mangled by the test of the pasted commands).</i> From the above log I think that testing dispPtr->clipboardActive is missing in the macOS version of TkSelGetSelection, which is therefore my fix proposal [b4c5f163]. With this patch clipboard-4.[124] no longer fail on macOS.
- login: "fvogel"
- mimetype: "text/x-fossil-wiki"
- resolution changed to: "Fixed"