[Webkit-unassigned] [Bug 234746] New: CSS Animation does NOT NOT when it should NOT

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=234746

            Bug ID: 234746
           Summary: CSS Animation does NOT NOT when it should NOT
           Product: WebKit
           Version: Safari 15
          Hardware: All
                OS: macOS 12
            Status: NEW
          Severity: Major
          Priority: P2
         Component: Animations
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jab_creations at yahoo.com
                CC: dino at apple.com, graouts at apple.com

Created attachment 448081

  --> https://bugs.webkit.org/attachment.cgi?id=448081&action=review

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

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20211229/96e2d204/attachment-0001.htm>