It’s super strange. Almost seems intermittent. At one moment we were thinking JPGs were working but PNGs were not. Then we find other PNGs that do preview. So it’s really odd. Maybe task or project driven? Maybe based on size?
On one task we see that the PNG previews if you click on it under the attachments area under description. But if you click on it in the comment threads it doesn’t.
@Michael_B has a problem with attached images in comments, that sometimes can’t be enlarged via lightbox.
@Andreas_Bossard has a problem with inline images in task descriptions, that never can be enlarged via lightbox.
I want to elaborate on issue number 2.
I did a little research and found a task created on January 2nd with an inline image in its description. The image was also added as an attachment automatically. This way I was able to see a larger version of the image because attachments are lightbox-able. A little cumbersome, but possible.
For newer tasks inline images are not added as attachments automatically. But since inline images are not lightbox-able, there’s no way to show screenshots in task descriptions at a useful size which is a massive downgrade. It seems like something changed within the last month or so.
I also read that inline images (a.k.a. the new content editor) will come to comments as well, so the problem will spread there as well.
That’s what the issue is about AFAIK.
I can reproduce it in Chrome and Safari. Co-workers are also able to reproduce it, also in Firefox.
The often mourned about pre-inline-images-behavior of “see attached screen number 3” was also cumbersome but at least we were able to enlarge the image at all. Right now our only option is to download the image and regularly clean our downloads folder afterwards.
Thank you so much for continue looking into this @Michael_B, but unfortunately, I’m still unable to reproduce the issue. I’ve spoken with some teammates and believe the issue is related to an A/B test we’re running, but I’m waiting on a confirmation. In the meantime, if you can reproduce the issue you’re describing, please DM me a screencast so I can share it with our team (ps: to DM me, simply click on my name and hit Message)
This A/B test is silly. Images are broken, my whole team is annoyed. The Windows version of Asana does not support “open image in new tab.” It has been going on for more than a month. @Michael_B is right - older tasks still work, but around Feb 1 images stopped working as expected. It really is a “massive downgrade” as Michael said.
@Marie would be neat if this topic was not marked as resolved. If it’s an A/B test, it’s broken. If it’s not, it’s even more broken. Marking this as resolved sends the wrong signal to us users who report those issues.
My team has been experiencing the same issues. It’s SUPER frustrating, as we primarily use screenshots to review that tasks are completed correctly. Not being able to enlarge an image in a comment means several extra clicks, in a completely different system, when it used to be only one. Yes, the work around of clicking on an attachment in the description works, but only if there was an attachment to start with (usually sent into the project via email). This really needs to be corrected, as it is greatly affecting the efficiency of our entire team!
If history is in any indication, two years from now someone still stumble across this thread trying to understand why it doesn’t work in the intuitive way they’d lke it to. (The only difference is that Asana will have removed this comment you’re now reading.)
The inability for the people in charge to reproduce the issue is a massive red flag.
If the best working theory right now is that an A/B test is to blame, then the person validating the problem needs to be empowered to shut down the test and confirm if the test is indeed to blame. If it turns out that a test is to blame (because it’s intentionally testing breaking established functionality) then the person who dreamed up the test is a bad, bad person. If the test is to blame because it breaks this functionality (but it isn’t specifically testing this functionality) then QA didn’t do their job thoroughly.
Either way, we’re not collectively imagining this - something has changed in our experience that is negatively impacting our workflow. The inability to replicate isn’t a reason to close the ticket, it’s a reason to escalate it.
If they can’t reproduce, then turning off the test would leave it to us to attempt to reproduce. Either way, we’d know something. Anyone validating a reported bug should have the ability to force themselves into all test variations as a way of attempting to reproduce. If one is attempting to reproduce without iterating through all tests, then it’s an invalid attempt to reproduce.