For me that sounds like a bug, but then I would see a topic about it here. So if my forum is the only one, then this must be an issue on my end.
Anyway.
My android users can’t see virtual keyboard if using rich text editor. When changed to markdown everything is fine. iPads and iPhones (Safari/PWA, DiscourseHub) are stuck in markdown, and can’t change to RTE.
This started two days ago, I reckon. My users have tendency to wait before they told me something is broken.
What else… self hosted, 2-container, on latest and upgraded every day and the newest is now 20 mins old at time of writing, safe-mode doesn’t help.
What is my next move? The console and possible errors aren’t an option on mobiles.
(index):1 Access to script at 'https://cdnfoorumi.katiska.eu/assets/br/chunk-coedl1gv.digested.js' from origin 'https://foorumi.katiska.eu' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
prosemirror-editor-opfbo6zd.digested.js:1 GET https://cdnfoorumi.katiska.eu/assets/br/chunk-coedl1gv.digested.js net::ERR_FAILED 200 (OK)
d-editor.gjs:212 Uncaught (in promise) TypeError: Failed to fetch dynamically imported module: https://cdnfoorumi.katiska.eu/assets/br/prosemirror-editor-opfbo6zd.digested.js
Prosemirror is the RTEditor. But I cannot help further than sharing the error message I see.
Off topic: Thanks for the laugh about your “Kisses and animals” category (Sadly the English translations says ‘cats’ instead, so I will stick to the German one )
I don’t understand what I see here, but is the issue S3 and my settings there? If yes why it started recently? One symptom might be that since yesterday I couldn’t write any boards-notes anymore.
But if cors is a problem why only those are affected?
—
Why in the name of old and new gods AI used Küsse in that context
I don’t think there have been any recent Discourse changes to cause this. However, S3 does have a longstanding weirdness with CORS, which can cause CDNs to cache a version of the asset without any Access-Control-Allow-Origin header. And if it’s a bad-cache issue, that could explain why it only affects some of your users (likely based on their location).
IIRC - S3 will only serve the Access-Control-Allow-Origin header to requests which send an Origin header (i.e. those from a normal web browser). When Access-Control-Allow-Origin is omitted, it does not serve Vary: origin in its response. And so: if the first request for a given asset is sent from a non-web-browser-context (e.g. curl, or some web crawler), then the CDN can cache the version without the CORS header. Very annoying!
The DISCOURSE_CORS setting won’t help at all here. That’s only relevant to the application server, not S3.
On our hosting, we workaround this problem by configuring Cloudfront to add Access-Control-Allow-Origin: * to all responses. That makes sure that the weird S3 behaviour can’t cause a bad result to be cached.
Alternatively, you could configure Cloudfront to include the Origin request header in its cache key, which would then keep the non-cors responses separate from the cors responses.
Amazon have a bunch of documentation on CORS here. I had this link in my notes which apparently was a forum thread on exactly this issue… but it seems they deleted it
Yup exactly - required for a custom domain, and it also makes things cheaper (Cloudfront egress is cheaper than direct-s3 egress, if I remember correctly)
)
)
If I recall right it is needed to use own domain. Or something.