# 桌面 Safari 中“附加文件”选项无响应

**URL:** <https://meta.discourse.org/t/attach-a-file-option-unresponsive-in-desktop-safari/393639>\
**Category:** Bug\
**Tags:** uploads, chat\
**Created:** [2026年一月16日 05:47 UTC](https://meta.discourse.org/t/attach-a-file-option-unresponsive-in-desktop-safari/393639 "2026-01-16T05:47:25Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![zogstrip](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/zogstrip/32/512781_2.png) [@zogstrip](https://meta.discourse.org/u/zogstrip)\
**Post date:** [2026年一月16日 15:34 UTC](https://meta.discourse.org/t/attach-a-file-option-unresponsive-in-desktop-safari/393639/3 "2026-01-16T15:34:10Z")

</div>

Safari 是新的 IE 浏览器了 :sadpanda:

> <https://github.com/discourse/discourse/pull/37179>
>
> The file picker wasn't opening when clicking "Attach a file" from the chat compo…ser dropdown menu on desktop Safari.
> 
> Safari requires programmatic file input clicks to happen synchronously within the user gesture event chain. The previous code used \`await closeFn()\` before calling \`button.action()\`, which broke this chain by deferring execution to a new microtask. Safari no longer considered the subsequent \`.click()\` to be user-initiated.
> 
> The fix removes the async/await to keep both calls synchronous within the original click handler.
> 
> This issue cannot be caught by automated tests because our system specs use Chrome, which is more permissive with user activation (allowing a ~5 second window after user interaction). Safari's stricter requirements only manifest in that specific browser.
> 
> References:
> \- https://meta.discourse.org/t/393639
> \- https://webkit.org/blog/13862/the-user-activation-api/
> \- https://macwright.com/2022/07/11/activation.html

---

_[View the full topic](https://meta.discourse.org/t/attach-a-file-option-unresponsive-in-desktop-safari/393639)._