Closed Bug 754860 Opened 12 years ago Closed 10 years ago

Intermittent test_bug726904.html | clientWidth should be 400 - got 0, expected 400 | clientHeight should be 400 - got 0, expected 400

Categories

(Core :: Audio/Video, defect)

Product:
Core
Component:
Audio/Video
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox16 --- affected
firefox17 --- affected

People

(Reporter: emorley, Assigned: padenot)

References

Details

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

Rev3 WINNT 5.1 fx-team pgo test mochitests-1/5 on 2012-05-12 15:32:29 PDT for push c758cc9b60e5

slave: talos-r3-xp-033

https://tbpl.mozilla.org/php/getParsedLog.php?id=11710350&tree=Fx-Team

{
89543 INFO TEST-START | /tests/content/media/test/test_bug726904.html
89544 INFO TEST-PASS | /tests/content/media/test/test_bug726904.html | Intrinsic width should match video width - 320 should equal 320
89545 INFO TEST-PASS | /tests/content/media/test/test_bug726904.html | Intrinsic height should match video height - 240 should equal 240
89546 ERROR TEST-UNEXPECTED-FAIL | /tests/content/media/test/test_bug726904.html | clientWidth should be 400 - got 0, expected 400
89547 ERROR TEST-UNEXPECTED-FAIL | /tests/content/media/test/test_bug726904.html | clientHeight should be 400 - got 0, expected 400
89548 INFO TEST-END | /tests/content/media/test/test_bug726904.html | finished in 91ms
}
Assignee: nobody → chris
cadecairos/cpearce: do you have any ideas for this one?
(Is one of the top oranges at the moment)
(In reply to Ed Morley [:edmorley] from comment #181)
> cadecairos/cpearce: do you have any ideas for this one?
> (Is one of the top oranges at the moment)

I'd expect the test to work as is. There's a genuine bug here. I don't know what's causing the failure.
Whiteboard: [orange]
Paul, any chance you could take a look at this? This is one of our most frequent failures on OSX. It appears to have spiked around Feb. 8, FWIW.
roc, it was pointed out that the spike on Feb. 8 coincides with the landing of bug 821695. Can you look otherwise?
As said on irc at the moment, I'll have a look tomorrow.
Assignee: chris → paul
I tried running a similar-ish testcase in a loop locally and wasn't able to reproduce the bug.

This test is testing the sizing of the media element to its poster. Bug 821695 shouldn't have affected that, especially because these media elements don't have controls. Maybe, before bug 821695, the presence of controls even on controls-less media elements was somehow hiding an underlying bug.

However, I don't understand this test. Our code does:
  if (NS_FAILED(element->GetVideoSize(&size)) && ShouldDisplayPoster()) {
    // Use the poster image frame's size.

So if the video has an intrinsic size (which it does, since the test ensures the video has loaded metadata before running the tests) we shouldn't be using the poster size. So how can the test expect the element size is the poster size, and pass?
Just a quick message to say that I'm working on this actively. It does not mean I'm making much progress, though, this is a bizarre bug.
Thank you :-)
(In reply to Paul Adenot (:padenot) from comment #446)
> Just a quick message to say that I'm working on this actively. It does not
> mean I'm making much progress, though, this is a bizarre bug.

Any luck in the last week? :-)
Flags: needinfo?(paul)
Disabled on OS X for now, since the failure rate is so high:
https://hg.mozilla.org/integration/mozilla-inbound/rev/b903c81b23eb
Whiteboard: [test disabled on OS X][leave open]
Failing on all platforms; disabled on the rest too:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7bdeb824afcf
Whiteboard: [test disabled on OS X][leave open] → [test disabled][leave open]
Flags: needinfo?(paul)
Runs without failure now. Re-enabled.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.