User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

This might be a duplicate, if so sorry — I don't know what OMTA is so I can't tell if other issues might be describing the root cause of the symptom I'm posting about.

• Make sure pref "gfx.omta.background-color" is set to true (this was default for me)

• Interact with some element with a background-color transition where it transitions from one color with alpha: 1 to some other color with alpha: 1

• In my case I noticed this on textboxes, my UI theme changes various textbox background colors (urlbar, findbar, search bars etc.) according to hover/active/focused states. These elements have opacity: 1 and background-color with alpha: 1, meaning no transparency. Similar transitions with opacity or color as the transition property do not have the same problem. It only seems to affect background-color.

• A really simple test example could be:
  #urlbar{background-color:red!important;transition:0.5s linear all}
  #urlbar:hover{background-color:yellow!important;transition:0.5s linear all}

Actual results:

Instead of smoothly transitioning from state 1 (red) to state 2 (yellow), it instantly jumps to some other color (I can't see a pattern) which in this case is yellow, then from there it transitions to red before instantly jumping back to yellow. It's kinda hard to phrase this, basically it is showing up like red->yellow......red->yellow instead of red......yellow, where -> means an instant transition and ....... means the actual transition defined in the CSS rules.

This isn't a consistent pattern though, this is just what happens in the red & yellow example I gave. My actual stylesheet is a lot more complicated and I wanted to give a simple example obviously. But in my case the urlbar starts out dark, then gets lighter on hover, then gets even lighter on focus. But what happens when I hover it with that pref set to true is really bizarre. Even if I remove everything except the rules directly controlling the animation, the exact same thing persists. The selector is only given 3 colors total, one base color, one hover, and one focus. The base color is the darkest one defined, the other 2 are lighter. But somehow when I hover the urlbar, it does the same kind of thing as the red&yellow example—except it instantly jumps from the base color to some darker color (which doesn't exist anywhere in the stylesheet), which then smoothly transitions back to the base color, which then instantly jumps to the brighter hover color.

So the sequence is just like in the red and yellow example, but in that case there were only 2 colors and they were at least the ones I defined. In this case there's a darker color that's apparently coming from nowhere. It's not an internal stylesheet doing it either. The same thing happens with the findbar textbox and other search bars. I even tried making a new, unique element with the console and applying these rules to it, and the same thing happened.

Expected results:

The background color should transition smoothly from state 1 to state 2 just like it did a month ago and does in every other program I know of that can render html 5. And just like it still does in firefox with every other transition property. This only seems to affect background-color and it also seems not to affect elements where all background colors have nonzero alpha values and nonzero opacity values.

Also keep in mind the textbox animations in my stylesheet been working correctly in approximately the same form for 5 years. And haven't been touched at all for months, yet they worked up until last week. And of course if I set gfx.omta.background-color to false, they work as normal again. Which is a solution for me obviously but should be reported since this doesn't look like intended behavior and I'm fairly certain this just recently happened. Or maybe it has been an ongoing problem but that pref's default value was changed recently, idk because I never noticed the setting until now.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Can you provide a testcase showing the problem?

shmediaproductions, thanks for the bug report. Though it's quite hard to tell what's going on there without a test case, my best guess is that in your case a new transition repeatedly replaces an older one? If so, I guess it's the same symptom as bug 1623425.

shmediaproductions, would you mind trying a build in this link?
https://treeherder.mozilla.org/#/jobs?repo=try&revision=381e04deddaa2707b2153bfad2121320fa12463c&selectedTaskRun=DPZq6UgTSdGvSwhJZdHATw-0

You can get the build from the link at "target.zip". If the issue doesn't happen on the build, this bug is pretty much same as bug 1623425. If not, I have totally no idea.

idk, every time I do a regression with this profile or install a build from outside the update installer, it deletes my whole sessionstore and I lose my 200+ tabs and notes and stuff. If I can figure out a way to back up and restore my profile that actually works, I will definitely try it.
Though I don't think that bug sounds like the same thing as mine. The animation isn't really jittery, it actually looks smooth most of the time, it's just "backwards." It's hard to explain. If you can't reproduce it with the simple example I gave, you can try using my whole userchrome.css file. Just make sure you set gfx.omta.background-color to true, since this userchrome file works perfectly fine if it's set to false. I use UI userscripts too but I don't think they are important in reproducing this. But in the event that I'm wrong about that, they are on my github too in the scripts folder.

https://github.com/shmediaproductions/uc.css.js

You can run the build with a new profile.

So, do you mean the issue happens only with your local modified userChrome.css, right? There is also userContent.css in your repo, does the issue happen in content documents (i.e. not browser window) without userContent.css?

I am attaching a simple test case, FWIW.

I don't see this problem on any websites. it only happens in the UI. so no, I don't think transitions defined in userContent.css would have this problem, though I didn't check that for sure. even the simple example I gave in the original report reproduces the issue exactly as I said, at least for me, I guess because it is styling a UI element. All the UI elements I tested have this problem. like, everything. toolbar buttons, text fields, window controls, etc. It's definitely not a generalized problem with transitions, because it only applies to background-color transitions. If I try to achieve the same overall effect by modulating opacity instead of background-color, it works fine, no problems. It's only when I try to use background-color that I get this issue. Also, if I set the element's opacity to non-zero, and set the alpha value in its background-color to non-zero as well (for all states) then the problem goes away. It only seems to cause a problem when 1 or more of the element's states has alpha and opacity 1.0

And yeah, I have tried running the build with a new profile but when I uninstall it and start back up in my real profile, it wipes my sessionstore, cache, site storage etc. only preserving the places files and account databases

btw I have just recently tried applying the transitions through javascript instead of CSS and no difference. idk if that rules anything out

So I just updated nightly and the problem is gone. Set gfx.omta.background-color to true and the transitions appear as normal. Not sure what happened, the problem only existed for a couple days

Thanks! So now I am pretty sure the root case is same as bug 1623425. We will have to land bug 1626165 along with bug 1634945.