[E][P] STARTUP Animations and GIFS are broken on ALL cases. (They don't start from the first frame always anymore.)

[Mosy]

User Agent String: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:131.0) Gecko/20100101 Firefox/131.0
Link:https://www.aaonline.fr/player.php?trial_id=148208
What happened?: (POPUPS AND STARTUP) Non-looped and looped gifs no longer play starting with the first frame, instead they now just keep playing randomly and don't restart upon entering next frame. For non-looped gifs, they are frozen forever on the final frame. This bug also happens to startup animations, hence voiding their purpose, this bug is also reflected on the minieditor (Whom dont reset their animation when we hover them anymore.)
What did you expect to happen?: Gifs need to always reload again starting from it's first frame when entering a new scene. (POPUPS AND STARTUP)
Can you reproduce the problem?: Yes, I created an example case showing the bug. Gifs/Startup animations used to work properly a few weeks ago but something seems to have broken them.
What did you do before the problem showed up?: N/A.

I made an example case showing the issue: https://www.aaonline.fr/player.php?trial_id=148208
This sadly broke so many of my favorite cases that rely on GIF timing to be precise. I hope it can be fixed soon!
thank you for all your help!

[Enthalpy]

I'm currently in the process of editing one of my tutorials. I'll look into this bug after that.

[Mosy]

No problem, good luck and thank you!

I'm currently in the process of editing one of my tutorials. I'll look into this bug after that.

[TimeAxis]

I don’t believe this has ever worked the way you expected. If you thought it did, you may have just gotten lucky with the timings. It’s not really possible to control the playback of gifs in the way you’re suggesting, as far as I’m aware. But it would be very nice if that were fixed somehow.

[Mosy]

GIFS really were working correctly a few weeks ago. Always have been for years now, actually, and it's definitely not luck because as evident of startup animations, they are completely broke too.
something changed a few weeks ago that messed something up in the code, around the time when the site mysteriously went down.

I don’t believe this has ever worked the way you expected. If you thought it did, you may have just gotten lucky with the timings. It’s not really possible to control the playback of gifs in the way you’re suggesting, as far as I’m aware. But it would be very nice if that were fixed somehow.

[DeathByAutoscroll]

I do think someone about how gifs were displayed changed, though if it's from browsers or code I can't say. Startups have basically never worked properly however from my experiences.

[Mosy]

It's true, startups were always buggy but they still did their job as promised. Sadly, the gifs being broken while being displayed also carried on to the case player.
I hope the mods can find a simple fix to this! if not, maybe revert the site back to a more stable version from a few days before I made this post?
thank you all.

I do think someone about how gifs were displayed changed, though if it's from browsers or code I can't say. Startups have basically never worked properly however from my experiences.

[TimeAxis]

There is no “more stable version” to revert back to. Nothing has changed in the code in the past few weeks/months.

The way AAO is coded (and has always been coded), the gifs first load when the green loading bar is filling out at the start of the trial. At that point, the gif is already loaded and playing in the background where you can’t see it. When it shows up in the case itself, it is another instance of the already loaded gif that plays in sync with the invisible one in the background. It’s set up this way so that all the assets don’t show up invisible and loading for a few seconds every time the case needs to display them. Resetting the timing of the gif when there is already an instance of it playing on the page isn’t possible.

Perhaps they could remove preloading of gifs entirely and that could solve the issue on faster connections, but in most cases that would be much worse because the gif would need to load from scratch every time it shows up in the case. (And even then, it’s likely that your browser would cache it and mess with the timings, so I’m not sure if that would even work).

You may just have never noticed the discrepancies before, but many others have. I’ve personally been dealing with it from the beginning of my time here and have never had precise gif timings.

[Mosy]

I don't think it's really that complicated, I have been experimenting on this site for 7+ years and I know how GIFS work enough to make a functional minigame. Let me show you an example of a case I have made a while ago using said GIF timings, and how this bug downgraded it.
It's a realtime battle where Gumshoe must fight Oogie Boogie (An enemy from TNBC movie), and we do so by clicking on the right set of cards.
Luckily I had a recording I made of it a few months ago, compare the old recording with the one I made today. Gumshoe no longer punches correctly, even Oogie is just stuck on his last frame, the loading timer above their heads is stuck on 0, etc with all the gifs used. (The GIFs in the older version unmistakably always refreshed upon entering a new frame, while in the playtest today, the GIFs dont reset and just play randomly. It is clear that there is a difference between then and now.)

GIFs BEFORE BUG (RECORDED OVER A MONTH AGO) --------------------- GIFs AFTER BUG (RECORDED TODAY) (Open gif in new tab if laggy.)
-------------------------------------

I am not sure if there was something client sided with your perspective of GIFS, or you just misunderstood what I was trying to say about them, but many of my friends and others I know also reported an issue with the GIFs just as I have.
Thank you. I hope this will be an easy fix!

There is no “more stable version” to revert back to. Nothing has changed in the code in the past few weeks/months.

The way AAO is coded (and has always been coded), the gifs first load when the green loading bar is filling out at the start of the trial. At that point, the gif is already loaded and playing in the background where you can’t see it. When it shows up in the case itself, it is another instance of the already loaded gif that plays in sync with the invisible one in the background. It’s set up this way so that all the assets don’t show up invisible and loading for a few seconds every time the case needs to display them. Resetting the timing of the gif when there is already an instance of it playing on the page isn’t possible.

Perhaps they could remove preloading of gifs entirely and that could solve the issue on faster connections, but in most cases that would be much worse because the gif would need to load from scratch every time it shows up in the case. (And even then, it’s likely that your browser would cache it and mess with the timings, so I’m not sure if that would even work).

You may just have never noticed the discrepancies before, but many others have. I’ve personally been dealing with it from the beginning of my time here and have never had precise gif timings.

[TimeAxis]

All I can say is that the second recording is how it has always been on my end, and as far as I’m aware, nothing has changed on AAO’s end that would affect that, especially within the past couple months or so. Maybe something changed on the browser side, but I use the same browser as you, so I don’t think that’s it either. I am still leaning toward “you happened to get lucky with the timings in that first recording”, as ridiculously unlikely as that would be (it is theoretically possible to flip 50 coins and have them all land heads, and then suddenly get tails and think something changed), but I realize that’s probably difficult to accept. If there were some way to reproduce the first recording’s behavior reliably, though, then of course I’d love that, but I’m worried it won’t be as easy as you’re hoping.

[Mosy]

Edit: I follow this site's engine on BITBUCKET and noticed that on October 8th there were indeed a few changes and commits to the code of the site's engine, the same time when the problem began. (And when I posted this bug report)

I wonder if this could be the issue? is the newly added commit code live? if anyone of the staff would like to take a look and let me know, I'd appreciate that. thank you.

All I can say is that the second recording is how it has always been on my end, and as far as I’m aware, nothing has changed on AAO’s end that would affect that, especially within the past couple months or so. Maybe something changed on the browser side, but I use the same browser as you, so I don’t think that’s it either. I am still leaning toward “you happened to get lucky with the timings in that first recording”, as ridiculously unlikely as that would be (it is theoretically possible to flip 50 coins and have them all land heads, and then suddenly get tails and think something changed), but I realize that’s probably difficult to accept. If there were some way to reproduce the first recording’s behavior reliably, though, then of course I’d love that, but I’m worried it won’t be as easy as you’re hoping.