First image in sequence isn't visible after loading

[pisi]

Two users independently reported a unpleasant behavior of new image sequence feature in 1.1. When frames are being loaded, the very first one isn't displayed when loading is finished.

Please vote for this issue if it bugs you too!

[Tornth]

The very first image of mine also disappear. Can you suggest the workaroumd?

[Witti]

After all images are loaded the first image src is replaced with this string "gif;base64,R0lGODlhCAAIAIAAAAAAAAAAACH5BAEAAAAALAAAAAAIAAgAAAIHhI+py+1dAAA7" so the first image can't be displayed.

Workaround:
Remove line no 322 ("t.attr({ src: transparent }).trigger('loaded');")

[DaveGorski]

removing line 322 breaks the plugin for sprite based reels.
try

if(opt.images.length == 0){
    t.attr({ src: transparent }).trigger('loaded');
}

this will work in both cases

[pisi]

Dave! Guys!

I've immediatelly tested out your suggested method and it indeed works. Not for 100% because the loaded event trigger is an important one and must be triggered. But pretty pretty close!

I've adapted your solution in a branch gorski-method and that works just perfect!

Then, however, I've rooted down the stink bit deeper. I realized the reason was that the initial fractionChange event for default initial frame was being dropped as not-changed. Modified dropping condition is another solution for this fix and this one will probably make it into patch release 1.1.1.

Till then the cleanest solution is condition modification in the zero-fraction-fix branch.

Both branches include a test case.

Thank you very much, guys for practically solving this instead of me. Very much appreciated!

[Archivist-zz]

Oh, I apologize, I made a new post about this issue, but didn't see this here.

I hope 1.1.1 can be released soon!

[pisi]

Hey!

I just released a patch version 1.1.1, which has a built-in cure for this issue along with test case assuring it won't re-emerge.