Open Bug 934301 Opened 6 years ago Updated 3 years ago

Intermittent test_bug450930.xhtml | Right edges out (408,0), | Bottom edges out (227,0)

Categories

(Core :: Layout, defect, P3)

x86
Linux
defect

Tracking

()

Tracking Status
firefox27 --- unaffected
firefox28 --- disabled
firefox29 --- disabled
firefox-esr24 --- unaffected

People

(Reporter: philor, Unassigned)

References

Details

(Keywords: intermittent-failure, Whiteboard: [leave open][test disabled])

https://tbpl.mozilla.org/php/getParsedLog.php?id=30052992&tree=Fx-Team
Ubuntu VM 12.04 fx-team opt test mochitest-4 on 2013-11-03 14:47:55 PST for push 1478a4c6fe96
slave: tst-linux32-ec2-073

14:57:26     INFO -  18938 INFO TEST-PASS | /tests/layout/base/tests/test_bug450930.xhtml | trigger test1 paint
14:57:26     INFO -  18939 INFO TEST-PASS | /tests/layout/base/tests/test_bug450930.xhtml | Left edges out (0,8)
14:57:26     INFO -  18940 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/base/tests/test_bug450930.xhtml | Right edges out (408,0)
14:57:26     INFO -  18941 INFO TEST-PASS | /tests/layout/base/tests/test_bug450930.xhtml | Top edges out (0,27)
14:57:26     INFO -  18942 ERROR TEST-UNEXPECTED-FAIL | /tests/layout/base/tests/test_bug450930.xhtml | Bottom edges out (227,0)
Roc, I'm wondering if this from your recent landing?
Flags: needinfo?(roc)
You mean the landing for bug 911889? I don't think so since this test doesn't use any of that. Bug 924679 only affected Linux, which matches this bug, but should only affect native theming, which this test isn't affected by.

I don't know what's going on here.
Flags: needinfo?(roc)
We have "trigger test1 paint" in the log, so clearly we got a MozAfterPaint event:
http://mxr.mozilla.org/mozilla-central/source/layout/base/tests/bug450930.xhtml#97
but still, the width/height of 'd' are zero according to the errors, even though
we called getBoundingClientRect().

I see only one explanation for that result - we haven't yet constructed
frames for 'd'.  Maybe we got a bogus MozAfterPaint event before the
initial reflow?
Hmm, that's not the case, because the failing test is actually the
fourth (and last) iteration:

TEST-START | /tests/layout/base/tests/test_bug450930.xhtml
TEST-PASS | trigger test1 paint
TEST-PASS | Left edges out (8,8)
TEST-PASS | Right edges out (408,408)
TEST-PASS | Top edges out (27,27)
TEST-PASS | Bottom edges out (227,227)
TEST-PASS | trigger test1 paint
TEST-PASS | Left edges out (8,8)
TEST-PASS | Right edges out (408,408)
TEST-PASS | Top edges out (27,27)
TEST-PASS | Bottom edges out (227,227)
TEST-PASS | trigger test1 paint
TEST-PASS | Left edges out (8,8)
TEST-PASS | Right edges out (408,408)
TEST-PASS | Top edges out (27,27)
TEST-PASS | Bottom edges out (227,227)
TEST-PASS | trigger test1 paint
TEST-PASS | Left edges out (0,8)
 TEST-UNEXPECTED-FAIL | Right edges out (408,0)
TEST-PASS | Top edges out (0,27)
 TEST-UNEXPECTED-FAIL | Bottom edges out (227,0)
Note that "Left edges out" goes from (8,8) -> (0,8) in the last iteration, so the rects
go from (in x,y,width,height format) r=8,27,400,200 -> r=0,0,408,227 and
bounds=8,27,400,200 -> 8,27,-8,-27 ?!?!  What can possibly cause such madness?
It was the third iteration that failed in the test run above.
Otherwise the same results.

TEST-START | /tests/layout/base/tests/test_bug450930.xhtml
TEST-PASS | trigger test1 paint
TEST-PASS | Left edges out (8,8)
TEST-PASS | Right edges out (408,408)
TEST-PASS | Top edges out (27,27)
TEST-PASS | Bottom edges out (227,227)
TEST-PASS | trigger test1 paint
TEST-PASS | Left edges out (8,8)
TEST-PASS | Right edges out (408,408)
TEST-PASS | Top edges out (27,27)
TEST-PASS | Bottom edges out (227,227)
TEST-PASS | trigger test1 paint
TEST-PASS | Left edges out (0,8)
 TEST-UNEXPECTED-FAIL | Right edges out (408,0)
TEST-PASS | Top edges out (0,27)
 TEST-UNEXPECTED-FAIL | Bottom edges out (227,0)
TEST-PASS | trigger test1 paint
TEST-PASS | Left edges out (8,8)
TEST-PASS | Right edges out (408,408)
TEST-PASS | Top edges out (27,27)
TEST-PASS | Bottom edges out (227,227)
TEST-PASS | Found exact rect
INFO -  Incoming rect: (8,227,412,431)
...
Priority: -- → P3
Interesting that this suddenly became a Windows-only failure on 5-Dec.
Thanks for investigating this Ryan.  That range contains only devtools and plugin CTP changes,
and a one-liner fix for B2G, all of which seems very unlikely to have an effect on this test.
The push to m-c prior to that merge sure says otherwise.
https://tbpl.mozilla.org/?tree=Try&rev=38d54d7753ef
(In reply to Mats Palmgren (:mats) from comment #109)
> Thanks for investigating this Ryan.  That range contains only devtools and
> plugin CTP changes,
> and a one-liner fix for B2G, all of which seems very unlikely to have an
> effect on this test.

Well this is fun. I stand by what I said earlier about reproducing on m-c. But to make matters more fun, I can't reproduce on fx-team until the m-c -> fx-team merge push. ARGH. However, there are some good-looking candidates in there, eh? I'm thinking maybe roc or tnikkel?
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=c7d9e537642a&tochange=1478a4c6fe96

I will try to reproduce this on the equivalent inbound range and hope for the best.
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #3)
> Roc, I'm wondering if this from your recent landing?

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #20)
> You mean the landing for bug 911889? I don't think so since this test
> doesn't use any of that.

Try bisection says otherwise.

https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=364814837fa8&tochange=eb66a2aa121e

29a30f4e9ad5 - https://tbpl.mozilla.org/?tree=Try&rev=28826809e8d8
eb66a2aa121e - https://tbpl.mozilla.org/?tree=Try&rev=389a34e48693

Also, are we still interested in why this started happening on Windows last Thursday or are we content with the Linux regression range?
Disabled in https://hg.mozilla.org/integration/mozilla-inbound/rev/711293c01410 while we think about whether or not we're interested in when we broke it the second time.
Whiteboard: [leave open][test disabled]
Flags: needinfo?(roc)
These failures are still there, along with "Test attempted to use a flaky timeout value 100" now.
You need to log in before you can comment on or make changes to this bug.