Closed Bug 1415783 Opened 7 years ago Closed 7 years ago

Make OMTA tests in layout/style work with conformant Promise handling on Android

Categories

(Core :: DOM: Animation, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla59
Tracking Status
firefox58 --- wontfix
firefox59 --- fixed

People

(Reporter: hiro, Assigned: hiro)

References

Details

Attachments

(1 file)

https://treeherder.mozilla.org/#/jobs?repo=try&revision=dc35b181a4a55c0bd3cca8a19346ff224545a649&selectedJob=143219722 It does not work at all. For example; INFO TEST-UNEXPECTED-FAIL | layout/style/test/test_animations_effect_timing_duration.html | OMTA should work
This is only for Android, on other platforms tests work somehow.
Summary: Make OMTA tests in layout/style work with conformant Promise handling → Make OMTA tests in layout/style work with conformant Promise handling on Android
Bug 1415734 is a similar one.
See Also: → 1415734
I will look this.
Assignee: nobody → hikezoe
Status: NEW → ASSIGNED
Surprisingly it did not fail on debug build? Happened only on release build??
Oops, I saw the same failure on local debug build, so it happens on debug build too.
This is the same symptoms what mantaroh mentioned in bug 1395971 comment 24. In the failure case, we receive the timer-triggered MozAfterPaint and thus we fail to check the opacity value on the compositor.
See Also: → 1395971
If I understand correctly bug 1419226, this should be fixed by that bug.
Depends on: 1419226
Even though I applied the patches for bug 1419226, the same error happens locally. That means we receive undesirable MozAfterPaint there.
Depends on: 1420791
(In reply to Hiroyuki Ikezoe (:hiro) from comment #8) > Even though I applied the patches for bug 1419226, the same error happens > locally. That means we receive undesirable MozAfterPaint there. I thought the undesirable MozAfterPaint comes from creating an element for testing animation [1], but even if the creation of the element is moved after fulfilled for loadPaintListener the OMTA check still fails. There must be other trigger to cause MozAfterPaint on Android. Given that this utility is used in many tests, I think the safest way to avoid the unexpected MozAfterPaint is that flush all pending styles before setting animation style. This way seems to work fine on a try; (mochitest-19 on Android opt, and mochitest-44 on Android debug) https://treeherder.mozilla.org/#/jobs?repo=try&revision=900ac5e4be6ac5746b067c1e6bef7777b457a170 [1] https://hg.mozilla.org/mozilla-central/file/f5f03ee9e6ab/layout/style/test/animation_utils.js#l241
Comment on attachment 8932328 [details] Bug 1415783 - Flush pending style, layout and paint and wait for a MozAfterPaint before waiting for MozAfterPaint for OMT animation. https://reviewboard.mozilla.org/r/203352/#review208762 ::: layout/style/test/animation_utils.js:268 (Diff revision 1) > + // receives unexpected MozAfterpaint event for those pending > + // notifications. > utils.advanceTimeAndRefresh(0); > + return waitForPaintsFlushed(); > + }).then(function() { > + // Trigger animation now (We probably don't need this comment--the above comment seems sufficient to me.)
Attachment #8932328 - Flags: review?(bbirtles) → review+
Pushed by hikezoe@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/ddbabccd3208 Flush pending style, layout and paint and wait for a MozAfterPaint before waiting for MozAfterPaint for OMT animation. r=birtles
No longer depends on: 1419226
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla59
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: