Bug 234746 – CSS Animation does NOT NOT when it should NOT

• Status: NEW
• Component: Animations

[John A. Bilicki III]

Created attachment 448081 [details]
Example of the fourth header bleeding through during the display of header 1; image numbers are chronological so there is something seriously off happening here.

URLs (if applicable) : https://www.jabcreations.net/ (initially, then https://alwcounseling.com/ in early January 2022)

Waterfox Classic 56: PERFECT
             Safari: FAIL
  Otter Safari 11.1: FAIL
      Firefox 78/91: PERFECT
               Edge: IE18 no longer supported.

This WebKit CSS Animations bug jumps the gun by NOT-NOT doing anything when it's told to NOT do anything. It automatically starts applying opacity from 0% to 14.28% even though opacity: 1; is set on both.

Background: the goal was to use a single XML element to render six images that transition. The timing is as follows:

Image 1: 6 seconds
Image 1-to-Image 2 Fade Transition: 1 second
Image 2: 6 seconds
Image 2-to-Image 3 Fade Transition: 1 second
Image 3: 6 seconds
Image 3-to-Image 4 Fade Transition: 1 second
Image 4: 6 seconds
Image 4-to-Image 5 Fade Transition: 1 second
Image 5: 6 seconds
Image 5-to-Image 6 Fade Transition: 1 second

There are two animations, front_page_1 and front_page_2.

@keyframes front_page_1
{
 0% {opacity: 1; background-image: url(images/header-front-page-1.jpg);}
 14.28% {opacity: 1;}
 16.66% {opacity: 0;}

 30.94% {opacity: 0;}
 33.32% {opacity: 1; background-image: url(images/header-front-page-3.jpg);}
 47.6% {opacity: 1;}
 49.98% {opacity: 0;}

 64.26% {opacity: 0;}
 66.64% {opacity: 1; background-image: url(images/header-front-page-5.jpg);}
 80.92% {opacity: 1;}
 83.3% {opacity: 0;}

 97.58% {opacity: 0;}
 100% {opacity: 1; background-image: url(images/header-front-page-1.jpg);}
}

@keyframes front_page_2
{
 14.28% {background-image: url(images/header-front-page-2.jpg);}
 47.6% {background-image: url(images/header-front-page-4.jpg);}
 80.92% {background-image: url(images/header-front-page-6.jpg);}
 100% {background-image: url(images/header-front-page-6.jpg);}
}


#page_
{
 animation: front_page_2 steps(3) 48s;
 animation-iteration-count: infinite;
 background-image: url(images/header-front-page-2.jpg);
}

#page_::before
{
 animation: front_page_1 steps(12) 48s;
 animation-iteration-count: infinite;
 background-image: url(images/header-front-page.jpg);
}

In order to use a single element to transition via opacity between multiple background-images two animations were necessary. This bug requires focus on the first animation. Additionally because there is always someone who doesn't READ or FOCUS at the problem at hand I am more than aware that the background-image does not "animate", it's simply changed; this is a problem with WebKit (and now also Blink) not following the rules set forth by the syntax.

In order to have six seconds without anything changing follow by a one second transition additional frames are required to tell the rendering engine to NOT do anything by re-declaring opacity: 1;. Both Blink and WebKit fail at this. There is a slight though VERY noticeable transition for opacity during the first six seconds when no changes should be occurring. All the animation transitions have this bug.

I've made a few attempts to adjust the code in order to attempt to negate this bug. In example I've tested a few different values for animation-timing-function. I also added non-related properties to see if I could "get the attention" of the rendering engine by using color: red and color: blue in case it was erroneously programmed to presume that something must be animated between each defined point in the animation. Nothing I tried worked and the bug remains on the test (and eventually live) website until Blink/WebKit engines are properly updated.

To view the correct behavior use Waterfox Classic to view the website (or I suppose Firefox if you must); both the individual transitions and the overall loop of the animation work perfectly.

Since CSS Animations were developed during the non-official fork between Safari/WebKit and Chrome/WebKit I will cross-post this to both rendering engine bug reporting systems along with the links in order to help make any collaboration easier. Additionally this website is (at the initial post time of this bug report) is on a test domain so when the domain transitions I'll update the domain name in the bug report for both rendering engine bug report systems.

I've attached a screenshot of the animation bug (about two seconds in to the animation when nothing should be happening until start AT the six second mark). If you can not clearly see the fourth image erroneously being displayed or you can not perceive the visual error please defer to someone who can to avoid confusion.

Because Blink is derived from WebKit and there may need to be some collaboration the Blink/Chrome bug report can be viewed at: https://bugs.chromium.org/p/chromium/issues/detail?id=1283283

[Radar WebKit Bug Importer]

<rdar://problem/87164061>

[John A. Bilicki III]

The domain account has temporarily been moved to https://www.abundanceofloveandwealth.com/. I will comment again when the domain account is at it's permanent domain name.

[Antoine Quint]

If I understand correctly, the issue is that before the first transition happens for the background image, we start showing another image at partial opacity. I can reproduce the issue with https://www.abundanceofloveandwealth.com with the latest STP and ToT while Chrome and Firefox don't show this odd behavior.

[John A. Bilicki III]

Antoine Quint, exactly correct.

Additionally I had not intentionally made any changes regarding the animation and Blink/Chrome suddenly seems to work including portable old versions with updating disabled.

So now only Safari and STP have the bug.

[Antoine Quint]

Wanted to check on this bug to see if it's still current but cannot load https://www.abundanceofloveandwealth.com anymore.

[John A. Bilicki III]

@Antoine Quint

That was the placeholder/text domain for:
https://www.alwcounseling.com/

Confirmed that this bug is still present on Safari 16.4.1 on Mac OS 12.6.5 on my Mac Mini late 2014.

So yes, please fix this if you can/would.