GitHub Community
Regression: Safari 26.5.2: Dragging images from Snagit into Issues/Projects Markdown editor fails (file=0) #202290
Replies: 10 comments
-
|
💬 Your Product Feedback Has Been Submitted 🎉 Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users. Here's what you can expect moving forward ⏩
Where to look to see what's shipping 👀
What you can do in the meantime 💻
As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities. Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐ |
Beta Was this translation helpful? Give feedback.
-
|
try to save the image from Snagit to your Desktop or any folder then drag it from Finder into the GitHub editor copy the image in Snagit with Command+C and paste it into GitHub with Command+V.. |
Beta Was this translation helpful? Give feedback.
-
|
@lrreynolds solid bug report. The ile=0 / "POST requires exactly one file upload" bit is the smoking gun: Safari + Snagit is handing GitHub a drag payload with no usable file part, while Finder/Preview/Chrome still send a real file. Workarounds that should unblock you today:
This looks like a Safari 26.5.2 + third-party drag source regression (GitHub upload API is doing the right thing when it gets zero files). Tagging it for Issues/Projects + Safari is the right call. If you can, note Snagit version too. That trio (Safari build + Snagit build + ile=0) is perfect for whoever picks this up. |
Beta Was this translation helpful? Give feedback.
-
|
Yes I can drag to the desktop and then using finder drag the file into github. This works. I have not been able to use copy / paste from snagit because they store thumbnails in a different format but dragging seems to convert them to png or jpgOn Jul 18, 2026, at 8:33 PM, Minsky ***@***.***> wrote:
try to save the image from Snagit to your Desktop or any folder then drag it from Finder into the GitHub editor copy the image in Snagit with Command+C and paste it into GitHub with Command+V..
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
That confirmation helps narrow it down further. If Finder -> GitHub works in Safari, and Snagit -> GitHub fails only when dragging directly, then the failure is probably in the drag payload that Safari exposes to GitHub’s editor, not in GitHub’s attachment endpoint generally. The most useful extra evidence would be the exact Snagit build plus a tiny local HTML drop-zone test to inspect the drag event: <!doctype html>
<meta charset="utf-8">
<body>
<div id="drop" style="border:1px solid #ccc;padding:40px">drop here</div>
<pre id="out"></pre>
<script>
const out = document.querySelector('#out');
document.querySelector('#drop').addEventListener('dragover', e => e.preventDefault());
document.querySelector('#drop').addEventListener('drop', e => {
e.preventDefault();
const files = [...e.dataTransfer.files].map(f => ({
name: f.name,
type: f.type,
size: f.size
}));
const items = [...e.dataTransfer.items].map(i => ({
kind: i.kind,
type: i.type
}));
out.textContent = JSON.stringify({ files, items }, null, 2);
});
</script>
</body>If direct Snagit drag in Safari shows something like: { "files": [], "items": [...] }or a file with size That is the kind of browser/app interop detail GitHub or TechSmith can reproduce quickly. For now, the safest workaround is exactly what you confirmed: export/drop to Finder first, then drag the actual file into GitHub. Copy/paste not working from Snagit is also useful to mention, because it suggests Snagit’s clipboard payload may be a thumbnail/internal format rather than a standard image file payload that GitHub’s editor accepts. |
Beta Was this translation helpful? Give feedback.
-
|
The original tests were using both an old version of Snagit and the latest version. Both results were identical.
I did the drop test in Safari with a local drop test file using the latest version of Snagit Version 2026.2.0 (2026.77)
I tested the drag payload using a local HTML drop-zone in Safari. Direct dragging from Snagit exposes one valid, non-zero image/png File in both DataTransfer.files and DataTransferItem.getAsFile(). webkitGetAsEntry() also returns a valid file entry.
Finder and Preview drags expose substantially the same payload and work in GitHub. Therefore, the failure does not appear to be caused by Safari exposing an empty or zero-byte Snagit file. The file is valid at the DOM drop event, but GitHub’s uploader subsequently sends a request containing zero files.
Additional investigation
I created a local HTML page that inspects the drop event. In both Safari 26.5.2 and Chrome, dragging directly from Snagit produces:
DataTransfer.files.length === 1
DataTransfer.items.length === 1
a valid File object
type: image/png
non-zero file size
DataTransferItem.getAsFile() returns the same valid file
webkitGetAsEntry() returns a valid file entry (Safari)
Therefore, Safari is exposing a valid File object during the drop event. Despite this, GitHub’s upload request ultimately reaches the server with zero uploaded files, resulting in:
POST requires exactly one file upload per request.
ArgumentValue: 0
This suggests the failure occurs after the browser’s drop event, within GitHub’s upload handling for Safari.
here are the results of those tests in order.
Snagit to safari

Finder to safari

Preview thumbnail to safari

Snagit to chrome

… On Jul 19, 2026, at 7:35 AM, Yimin Du ***@***.***> wrote:
That confirmation helps narrow it down further.
If Finder -> GitHub works in Safari, and Snagit -> GitHub fails only when dragging directly, then the failure is probably in the drag payload that Safari exposes to GitHub’s editor, not in GitHub’s attachment endpoint generally.
The most useful extra evidence would be the exact Snagit build plus a tiny local HTML drop-zone test to inspect the drag event:
<!doctype html>
<meta charset="utf-8">
<body>
<div id="drop" style="border:1px solid #ccc;padding:40px">drop here</div>
<pre id="out"></pre>
<script>
const out = document.querySelector('#out');
document.querySelector('#drop').addEventListener('dragover', e => e.preventDefault());
document.querySelector('#drop').addEventListener('drop', e => {
e.preventDefault();
const files = [...e.dataTransfer.files].map(f => ({
name: f.name,
type: f.type,
size: f.size
}));
const items = [...e.dataTransfer.items].map(i => ({
kind: i.kind,
type: i.type
}));
out.textContent = JSON.stringify({ files, items }, null, 2);
});
</script>
</body>
If direct Snagit drag in Safari shows something like:
{ "files": [], "items": [...] }
or a file with size 0, that matches GitHub’s file=0 / “exactly one file upload” error very closely. Then the bug report can say:
Safari 26.5.2 + Snagit VERSION direct drag exposes no usable File object / zero-byte file in DataTransfer.files.
Finder drag exposes one valid PNG/JPG File object.
Chrome direct Snagit drag exposes one valid file.
That is the kind of browser/app interop detail GitHub or TechSmith can reproduce quickly.
For now, the safest workaround is exactly what you confirmed: export/drop to Finder first, then drag the actual file into GitHub. Copy/paste not working from Snagit is also useful to mention, because it suggests Snagit’s clipboard payload may be a thumbnail/internal format rather than a standard image file payload that GitHub’s editor accepts.
—
Reply to this email directly, view it on GitHub <#202290?email_source=notifications&email_token=ANZKSKNAY7UDTAIS4XSMMT35FTFC7A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZWHA4DOMRVUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17688725>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANZKSKPSNKUAA3NXBVKZY635FTFC7AVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMBUGU2DCNJQUF3AE>.
You are receiving this because you were mentioned.
|
Beta Was this translation helpful? Give feedback.
-
|
Thanks for running the drop-zone test so thoroughly. That result rules out the most obvious hypothesis: Safari is exposing a valid, non-zero With the same Snagit drag working in Chrome, and Finder/Preview drags working in Safari, this is now a strong minimized interoperability regression rather than a general attachment or network problem. The most useful summary for GitHub staff is:
I would add that compact matrix to the original post if possible and keep the Finder-export workaround for now. You have already isolated this far enough that the remaining investigation belongs in GitHub's editor/uploader implementation; repeatedly changing Snagit or browser settings is unlikely to add much more signal. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks, I did some additional testing and this is what I have concluded from the results.
GitHub receives a valid File object during the drop event (DataTransfer.files.length === 1, correct filename, MIME type, and non-zero size). The subsequent multipart/form-data request includes a file part with the correct filename and Content-Type: image/png, but the body of that part contains no PNG data before the terminating boundary. Amazon S3 rejects the request with:
POST requires exactly one file upload per request.
ArgumentValue: 0
Figure 1. Dragging a PNG directly from Snagit into a GitHub issue in Safari results in an upload failure.

Figure 2. GitHub generates a multipart/form-data upload request, but the server returns HTTP 400.

Figure 3. Amazon S3 rejects the upload because the request contains no uploaded file content.

Figure 4. The multipart request contains a file part with the correct filename and MIME type, but no image data before the terminating boundary.

… On Jul 19, 2026, at 8:36 AM, Yimin Du ***@***.***> wrote:
Thanks for running the drop-zone test so thoroughly. That result rules out the most obvious hypothesis: Safari is exposing a valid, non-zero image/png File, and the failure happens later in GitHub's Safari upload path.
With the same Snagit drag working in Chrome, and Finder/Preview drags working in Safari, this is now a strong minimized interoperability regression rather than a general attachment or network problem. The most useful summary for GitHub staff is:
Safari 26.5.2 + Snagit 2026.2.0 (2026.77)
DataTransfer.files.length === 1 with a valid non-zero PNG
getAsFile() and webkitGetAsEntry() both succeed
GitHub subsequently submits zero files and receives ArgumentValue: 0
the equivalent Snagit drag works in Chrome
Finder and Preview drags work in Safari
I would add that compact matrix to the original post if possible and keep the Finder-export workaround for now. You have already isolated this far enough that the remaining investigation belongs in GitHub's editor/uploader implementation; repeatedly changing Snagit or browser settings is unlikely to add much more signal.
—
Reply to this email directly, view it on GitHub <#202290?email_source=notifications&email_token=ANZKSKLCUIFGJPA6R77D6TD5FTMIHA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZWHA4TANZYUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17689078>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANZKSKNA5GSCNADWBSNZMUT5FTMIHAVCNFSNUABIKJSXA33TNF2G64TZHMZTAMJVG4ZTGNBUHNCGS43DOVZXG2LPNY5TCMBUGU2DCNJQUF3AE>.
You are receiving this because you were mentioned.
|
Beta Was this translation helpful? Give feedback.
-
|
That is excellent evidence and narrows the failure down another layer. The browser drop event contains a valid non-zero The remaining fault is most consistent with GitHub's Safari upload code consuming or serializing this particular
I would add that exact conclusion to the original post. If you capture a HAR or network export for a GitHub/TechSmith report, redact cookies, authorization headers, signed upload URLs, and query parameters before sharing it publicly. A sanitized comparison of only the multipart structure is enough. At this point you have a reproducible client-side event, the generated request, and a working control case. That should be sufficient for GitHub to investigate; I do not think more end-user configuration changes are warranted. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your feedback confirming my results. If you wouldn’t mind since I have no real experience making this type of report to github and this whole discussion and the subsequent follow up testing was far beyond my technical expertise but I relied on a model and your suggestions to dig into this so if you pass this on to the appropriate people in the most appropriate form I would sincerely appreciate it.I am now going back to using these tools and the workaround I have to complete what I was doing when this issue became a headache. Hope it gets resolved…On Jul 19, 2026, at 9:46 AM, Yimin Du ***@***.***> wrote:
That is excellent evidence and narrows the failure down another layer. The browser drop event contains a valid non-zero File, and GitHub constructs a multipart part with the expected filename and Content-Type, but the file payload becomes empty before the terminating boundary. That makes an S3-side problem unlikely: S3 is correctly rejecting the empty upload it receives.
The remaining fault is most consistent with GitHub's Safari upload code consuming or serializing this particular File/blob incorrectly after the drop event. The comparison matrix is now especially strong:
Snagit -> Safari -> GitHub: metadata present, multipart file body empty
Finder/Preview -> Safari -> GitHub: upload succeeds
Snagit -> Chrome -> GitHub: upload succeeds
I would add that exact conclusion to the original post. If you capture a HAR or network export for a GitHub/TechSmith report, redact cookies, authorization headers, signed upload URLs, and query parameters before sharing it publicly. A sanitized comparison of only the multipart structure is enough.
At this point you have a reproducible client-side event, the generated request, and a working control case. That should be sufficient for GitHub to investigate; I do not think more end-user configuration changes are warranted.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
🏷️ Discussion Type
Bug
💬 Feature/Topic Area
Issues
Body
Since upgrading to macOS 26.5.2 / Safari 26.5.2, dragging PNG screenshots directly from Snagit into the GitHub Issue editor no longer works.
The same workflow worked previously.
Dragging the same image from Finder works correctly in Safari
Dragging the same image from Preview works correctly in Safari
The same Snagit drag also works in Chrome.
In Safari Github reports
The network request shows this error:
InvalidArgumentPOST requires exactly one file upload per request.
file
0
Additional observations:
Guidelines
Beta Was this translation helpful? Give feedback.
All reactions