Closed Bug 541855 Opened 14 years ago Closed 10 years ago

Intermittent failure in test_transitions.html | timing function test for timing function cubic-bezier(1, 0, 0, 1) : computed value 52.8px should be between 52.859280px and 53.199280px at time between 4.0002640000000005s and 4.0002640000000005s.

Categories

(Core :: CSS Parsing and Computation, defect, P5)

Product:
Core
Component:
CSS Parsing and Computation
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla30
Tracking Flags:
Tracking Status
firefox28 --- fixed
firefox29 --- fixed
firefox30 --- fixed
firefox-esr24 --- fixed
b2g-v1.2 --- fixed
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed

People

(Reporter: philor, Assigned: dbaron)

References

Details

(Keywords: intermittent-failure, Whiteboard: [qa-])

Attachments

(1 file)

Add in the error tolerance before calling the timing function, so that we allow more error for steeper functions, and less error for most.
1.53 KB, patch
dholbert
: review+
Details | Diff | Splinter Review 
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1264329100.1264331595.12701.gz
Linux mozilla-central debug test mochitests-4/5 on 2010/01/24 02:31:40
s: moz2-linux-slave02

23538 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_transitions.html | timing function test for timing function cubic-bezier(1, 0, 0, 1): computed value 52.1833px should be between 52.258859px and 52.598859px at time between 4.000136s and 4.000136s.
Seems to have changed message after bz's change in http://hg.mozilla.org/mozilla-central/rev/54d47e708c9c

s: cb-seamonkey-linux-03
26242 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_transitions.html | interrupt on parent test for time 2s: computed value 49.6167px should be between 0.000000px and 0.000000px at time between 0s and 0s.
Bug 541855 - Intermittent failure in test_transitions.html | timing function test for timing function cubic-bezier(1, 0, 0, 1) Bug 522862 - intermittent failure at test_transitions.html 26243 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_transitions.html | interrupt on parent test for time 4s: computed value 49.6167px should be between 0.000000px and 0.000000px at time between 0s and 0s.
26244 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_transitions.html | interrupt on parent test for time 6s: computed value 49.6167px should be between 0.000000px and 0.000000px at time between 0s and 0s.
26245 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_transitions.html | interrupt test for time 2s: computed value 49.6167px should be between 0.000000px and 0.000000px at time between 0s and 0s.
26246 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_transitions.html | interrupt test for time 4s: computed value 49.6167px should be between 0.000000px and 0.000000px at time between 0s and 0s.
26247 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_transitions.html | interrupt test for time 6s: computed value 49.6167px should be between 0.000000px and 0.000000px at time between 0s and 0s.
26248 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_transitions.html | interrupt on parent test for time 2s: computed value 49.6167px should be between 0.000000px and 0.000000px at time between 0s and 0s.
26249 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_transitions.html | interrupt on parent test for time 4s: computed value 49.6167px should be between 0.000000px and 0.000000px at time between 0s and 0s.
26250 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_transitions.html | interrupt on parent test for time 6s: computed value 49.6167px should be between 0.000000px and 0.000000px at time between 0s and 0s.
26251 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_transitions.html | interrupt test for time 2s: computed value 49.6167px should be between 0.000000px and 0.000000px at time between 0s and 0s.
26252 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_transitions.html | interrupt test for time 4s: computed value 49.6167px should be between 0.000000px and 0.000000px at time between 0s and 0s.
26253 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_transitions.html | interrupt test for time 6s: computed value 49.6167px should be between 0.000000px and 0.000000px at time between 0s and 0s.
54901 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/style/test/test_transitions_per_property.html | Test timed out.
Summary: Intermittent failure in test_transitions.html | timing function test for timing function cubic-bezier(1, 0, 0, 1) → Intermittent failure in test_transitions.html | timing function test for timing function cubic-bezier(1, 0, 0, 1) : computed value 52.8px should be between 52.859280px and 53.199280px at time between 4.0002640000000005s and 4.0002640000000005s.
Whiteboard: [orange]
Priority: -- → P5
This is probably the steepest point of the steepest timing function tested; the errors are always coming out high.  This may well be a case of the comment in check_transition_value:

        // Assume a small error since bezier computation can be off slightly.
        // (This test's computation is probably more accurate than Mozilla's.)
        var value_portion = func(time_portion) + error_direction * 0.0015;

not being sufficient error tolerance for this particularly-steep function.  I suppose it would help to put in a very small error bounds into the argument to the function (which would thus become relevant only when the function is very steep, as here).
Actually, given that bug 522862 was this same test, I'm going to move the entire thing inside the function.  I'll want to get a bunch of data from try to make sure the new number is sufficient before landing, though...
Assignee: nobody → dbaron
Status: NEW → ASSIGNED
Comment on attachment 8375833 [details] [diff] [review]
Add in the error tolerance before calling the timing function, so that we allow more error for steeper functions, and less error for most.

>+++ b/layout/style/test/test_transitions.html
>@@ -433,17 +433,17 @@ function check_transition_value(func, st
>     function value_at(elapsed, error_direction) {
>         var time_portion = (elapsed - start_time) / (end_time - start_time);
>         if (time_portion < 0)
>             time_portion = 0;
>         else if (time_portion > 1)
>             time_portion = 1;
>         // Assume a small error since bezier computation can be off slightly.
>         // (This test's computation is probably more accurate than Mozilla's.)
>-        var value_portion = func(time_portion) + error_direction * 0.0015;
>+        var value_portion = func(time_portion + error_direction * 0.0005);
>         if (value_portion < 0)
>             value_portion = 0;
>         else if (value_portion > 1)
>             value_portion = 1;
>         var value = (1 - value_portion) * start_value + value_portion * end_value;
>         if (start_value > end_value)
>             error_direction = -error_direction;
>         // Computed values get rounded to 1/60th of a pixel.

Makes sense; so now our fudge factor lets us have any of the values within the range of +/- .0005 seconds from the current time. (or is it .0005 milliseconds? not sure what the units are here)

nit: could you add a brief comment explaining the purpose of "value_at", so that that's clearer? Maybe something like:
 // Helper function to compute an upper or lower fuzzy bound on the expected
 // value at a given time, depending on error_direction.

(maybe mentioning the +/- .0005 second window, too, to make it clear that that our "fuzziness" is (now) time-based rather than value-based)

r=me
Attachment #8375833 - Flags: review?(dholbert) → review+
It's not seconds -- the time fudging ratio is handled elsewhere, and we run this code twice, once for each time bound.  What we're fudging here is the error in the cubic-bezier timing function, and I'm changing the fudging to being an addition to its 0-1 range input, rather than an addition to its output (generally but not always 0-1 range).  I'll add a comment to explain it a little better.
(In reply to David Baron [:dbaron] (needinfo? me) (UTC-8) from comment #112)
> It's not seconds -- the time fudging ratio is handled elsewhere

Oh, right -- you're normalizing to (end_time - start_time) before adding the fudge factor. (So it would be .0005 seconds if this were a 1s transition.)

> we run
> this code twice, once for each time bound.

Yup, noticed that after skimming the contextual code.  A comment would indeed make that more obvious. thanks!
https://hg.mozilla.org/mozilla-central/rev/6e53e28ec256
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Whiteboard: [qa-]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: