Closed Bug 1060315 Opened 9 years ago Closed 9 years ago

Intermittent browser_devices_get_user_media.js | video/audio global indicator attribute as expected - Got , expected true

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal
Points:
3

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 36
Iteration:
36.2
Tracking Flags:
Tracking Status
firefox34 --- unaffected
firefox35 --- fixed
firefox36 --- fixed
firefox-esr31 --- unaffected

People

(Reporter: cbook, Assigned: florian)

References

(
URL
)

Details

(Keywords: intermittent-failure)

Attachments

(1 file, 1 obsolete file)

Patch with yield*
3.90 KB, patch
Gijs
: review+
Details | Diff | Splinter Review 
Ubuntu VM 12.04 mozilla-inbound pgo test mochitest-browser-chrome-1 on 2014-08-29 02:13:51 PDT for push 5f66dd3d63f2

slave: tst-linux32-spot-574

https://tbpl.mozilla.org/php/getParsedLog.php?id=47017529&tree=Mozilla-Inbound



633 INFO TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/general/browser_devices_get_user_media.js | video global indicator attribute as expected - Got , expected true
Blocks: 1041658
I wonder if the fix for bug 973001 increased the frequency of this intermittent failure.
Summary: Intermittent browser_devices_get_user_media.js | video global indicator attribute as expected - Got , expected true → Intermittent browser_devices_get_user_media.js | video/audio global indicator attribute as expected - Got , expected true
(In reply to Florian Quèze [:florian] [:flo] from comment #26)
> I wonder if the fix for bug 973001 increased the frequency of this
> intermittent failure.

Looking at war on orange, I'm seeing a spike around Oct 12/13:

http://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1060315&startday=2014-08-21&endday=2014-10-21&tree=trunk

Do you have time to look at this, Florian, or know someone who does? It is now one of the top oranges...
Flags: needinfo?(florian)
I think the frequency of this failure has actually increased twice. When the bug was initially filed, this was a very rare failure (about once a week). Around September 22, it became more common, failing a few times per day; my guess is that increase was due to the webrtc UI becoming more asynchronous with the fix for e10s.

Then, like you observed, there's another increase in October, making this fail very frequently. I have no idea of the cause of that new increase.

For the reason for the failure, my guess is that the webrtcIndicator.xul window hasn't finished loading when we check DOM attributes on it.

The problem would be near http://hg.mozilla.org/mozilla-central/annotate/29fbfc1b31aa/browser/base/content/test/general/head.js#l669

Possible fix ideas:
- hide the problem with waitForCondition
- check that the document has finished loading (using document.readyState) before the DOM attribute checks. If it hasn't, listen to the readystatechange event.

Is the test now failing frequently enough that pushing a possible fix to try and retriggering bc1 several times can confirm the fix? Not being able to reproduce the failure is the reason why I haven't tried any of these possible fixes a month ago.
Flags: needinfo?(florian)