Closed Bug 1961075 Opened 1 month ago Closed 2 days ago

Intermittent bugs/1804872-3.html == bugs/1804872-3-ref.html | single tracking bug

Categories

(Core :: Layout, defect, P5)

Product:
Core
Component:
Layout
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: intermittent-bug-filer, Unassigned)

Details

(Keywords: intermittent-failure, intermittent-testcase)

The failure's testcase and reference case screenshots match what I see if I directly view testcase/reference case files locally in Firefox.

In particular, the testcase has a very small graphic (expected to be small, due to having scale: 0.1), and the reference case has a much larger graphic (expected to be large, due to having scale: 2).

When run in the reftest harness, the testcase is supposed to kick off an animation that increases its scale from the default 0.1 to 2.0 (making it 20 times as large):
https://searchfox.org/mozilla-central/rev/0383ce6fe9579f345529b06170caaeb386ebc7c2/layout/reftests/bugs/1804872-3.html#14-16,19,27,33-41

@keyframes anim {
  0% { scale: 2.0; }
  100% { scale: 2.0; }
...
#target {
...
  scale:0.1;
...
<script>
document.addEventListener('MozReftestInvalidate', () => {
  // Set a bit longer animation delay to avoid painting the initial animation
  // style on the main thread.
  target.style.animation = "anim 100s 1s";
  target.addEventListener("animationstart", () => {
    requestAnimationFrame(() => {
      requestAnimationFrame(() => {
        document.documentElement.classList.remove("reftest-wait");

That animation is on a 1s delay, and the test is supposed to wait out that delay (for animationstart to fire) and then the test is supposed to flush paints and then allow the reftest snapshot to be taken.

But apparently some part of that failed here. I suspect maybe we failed to wait out the delay somehow, as I'll note in my next comment...

(CC :boris and tnikkel who might be interested, since this has to do with css animations and tnikkel was the test author)

(In reply to Daniel Holbert [:dholbert] from comment #1)

But apparently some part of that failed here. I suspect maybe we failed to wait out the delay somehow, as I'll note in my next comment...

Hmm, actually I think we did wait out the animation delay after all. --> [editing to strike through that theory]

I was initially suspecting that we skipped the delay somehow, since the timestamps in the linked "Full Log" seem to show us loading the testcase and reference case in rapid succession (the logging is all within a span of .002ms). But really I think those timestamps are bogus and are an artifact of how android test logging is done asynchronously/off-device.

If I click through to the logcat log, it shows the more true-to-life timing, with the TEST-LOAD event happening at timestamp 02:04:24.194 and then the DoDrawWindow and other steps at the end of that test load happening at timestamp 02:04:26.255, ~2s later. So it looks like we did wait for about the expected amount of time, and we must have failed to produce the correct test-rendering for other reasons.

https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup
For more information, please visit BugBot documentation.

Status: NEW → RESOLVED
Closed: 2 days ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.