When people post a new topic and they embed an image by pasting the image URL on a blank line, the image does not appear until some minutes later, when Sidekiq has downloaded the remote image to local (albeit AWS S3).
This only occurs when people paste HTTP URLs to remote images in to their post, all HTTPS images are displaying fine.
Here’s what everyone sees in the minutes before the image is pulled locally:
Navigate away from that new post then go back in to it (and/or refresh the page to clear the console too). Image is no longer displayed and there are console warnings and errors in red / yellow about mixed content.
Wait five minutes for the image to be pulled locally and for System user to edit the first post with the new / local image URL and it then displays fine with no warnings.
Again, this only occurs on HTTP image URLs, all https image urls are fine.
ember_jquery.js seems to throw the yellow warnings of “Loading mixed (insecure) display content “http://www.sebulli.com/Testbildgenerator/testbild.gif” on a secure page”
If your Discourse forum is served over https, then having links to images which are not from an https website will create an error for mixed content. Most browsers will rightfully complain and, depending on their configuration, refuse to load the image.
I discussed this issue with @sam last week and there’s not much we can do here since sharing non-secure assets on a secured forum is essentially a self-inflicted end user issue.
What we can do here is stop showing image previews for non-secure assets on a secure forum so the end user does not get confused if the image does not show up when the post is created.
This is new behavior. It is caused by the newly implemented lazy-loading of images. It did not occur before.
The lazy-loading mechanism somehow causes browsers to treat the images as active content. Passive content (like plain old <img> tags) is allowed to load from non-secure sources. This will result in a warning, not an error:
As per my steps to replicate, the user goes away thinking their shiny image-embedded post has worked yet anyone viewing their post before the image has been pulled down locally simply sees a broken/missing image.
Which is a poor user experience all round
So we have a few options available I’m guessing?
Option one, as you suggested @techAPJ is to simply not show the preview - the user can then see the image is not going to work (although it does work when fetched to local 5 mins later).
Option two, as @fuzzyk suggested, use an <img> tag - which @codinghorror ruled out.
Option three, can you you use the <img> tag which Jeff isn’t keen on, then at the point of fetching the image locally, edit the post to use whatever code you currently use and replace the <img> at the same time as replacing the image URL?
Option four, can I change the amount of time it takes to download the image locally? It seems to be approx 5 minutes. Can I lower this to 10 seconds or something?
Sorry for not being able to respond in the last few days.
My only issue with this is how the new lazy loading system somehow breaks existing functionality, even if that may have been “accidental” functionality. I strongly believe it doesn’t have to be this way!
I’ll look into what exactly causes browsers to treat the images as active content, which is basically the only issue here.
(<img> tags are already used, by the way, so there must be some counter-intuitive API restriction somewhere.)
/edit: Okay, trivial testing reveals this is related to the use of srcsets.
/edit2: Here’s a blog post on this topic. It appears there is no trivial solution.
/edit3: I have found the issue and will present a pull request shortly.
/edit4: Here’s the pull request:
