Starting about one month ago, I have been unable to upload any graphics on Discourse. I get the typical progress information below the composing pane—20%, 40%, 100% uploaded. But once that finishes, the composing pane shows something along these lines (I entered this as preformatted text so everything would show):
[Uploading: Screen Shot 2022-06-14 at 10.58.16 AM.png…]()
and the finished message pane for the same thing will show:
Uploading: Screen Shot 2022-06-14 at 10.58.16 AM.png…
But at that point, no uploading activity is still underway. Obviously, the content that is supposed to be in parentheses isn’t uploading. Waiting for hours doesn’t change anything.
This occurs on a Mac running macOS v10.15.7 and Safari Version 15.5 (15613.2.7.1.9, 15613). When Discourse is accessed on the same machine via Firefox, everything functions normally.
Sorry, but that video was so horribly produced I couldn’t follow it. Nevertheless, I think I found the “Console.” If I try to upload a JPG image named Joss-Main to the message I am currently composing in Safari, this is the result:
Logging in via Firefox and continuing on the same topic, I can upload a screen shot of the Safari Console window. Everything in the Console window appeared after dragging that one image to the composing pane (while in Safari). As you can see, the screen shot image uploads in Firefox just fine:
Given you are using a super recent browser we can try to reproduce here. Assigining it internally to tech advocates so we can see if anyone else can reproduce the issue on Safari 15.5. At the moment I can not even test it on browserstack it is so recent (albeit 100% supported).
Can you upload the problem image here, or is it every single image?
We’ve tried for a simple repro but unfortunately have not been able to replicate it so far. There was another similar topic where the issue turned out to be something to do with a ClearURL browser extension, but I’m not sure that’s helpful here? MacOS Firefox image upload error - #16 by jimkleiber
Hi @JammyDodger sorry for the slow response, I’m about to conduct a test on my friends version of safari to see if it will pop anything out. @tut Out of interest what device are you using?
My guess is that somehow this version of Safari has bugs with it. This API being flagged “deprecated” is causing all sorts of pain cause browser tend to break it a bit?
We don’t use execCommand when going from upload placeholders → URLs, so I don’t think that’s the cause here. (We can’t easily switch, because execCommand("insertText") requires the textarea to have focus, and uploads may finish when you don’t have the textarea focused).
It’s technically deprecated from the web standards, but there is not yet any alternative for the insertText command. From MDN:
The Clipboard API can be used instead of execCommand in many cases, but execCommand is still sometimes useful. In particular, the Clipboard API doesn’t replace the insertText command, which you can use to programmatically replace text at the cursor while preserving the undo buffer (edit history) in plain textarea and input elements.
Given the widespread use, it seems incredibly unlikely that browsers are going to drop support for this without first providing an alternative and a deprecation window.
Ok wow, this is a weird one! Safari is replacing the ... (three periods) with an ellipses character …. That then breaks our later attempt to replace the placeholder with the true url.
@tut can you open your system preferences → Keyboard → Text, and see whether you have a replacement configured there. If I add a ... → … replacement, then I can reproduce the same issue in Safari on my machine:
(yours may look slightly different due to the older macOS version)
So yeah, this seems quite likely - sorry for discarding that idea earlier @sam. Looks like Safari is applying OS-level text replacements to text that we add via execCommand("insertText",. I wonder if that’s a new thing in Safari 15.5, or whether it’s always been the case and we just haven’t noticed
@david, I have no such substitution set up under Keyboard preferences. Now that I know what to look for, however, I can confirm that the substitution occurs. I can actually see it happen as I type. And I can verify it by using the back arrow. When I get to the ellipses character, the cursor jumps back over all three periods that were entered as separate characters.
The same thing happens in Notes, Preview, Messages, and Mail, but not Calendar, Maps, Photos, or (obviously) Firefox. So it seems to be an app-specific thing, not a system-level one.
. Looks like Safari is applying OS-level text replacements to text that we add via 