1205819 - Sanity test error "this.mm is null" on Windows Server 2012 (Remote Desktop)

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Vladan Djeric (:vladan)]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20150914030205

Steps to reproduce:

I launched a Windows debug build with "mach run" on a Windows Server 2012 machine (via Remote Desktop) and saw the following error on stdout:

JavaScript error: file:///c:/Users/vdjeric/mozilla-central-debug/obj-i686-pc-mingw32/dist/bin/components/SanityTest.js, line 224: TypeError: this.mm is null

This error is in in the endTest method, on the following line:

this.mm.removeMessageListener(msgName, this);

Comment 1

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: fix

If we don't get an onWindowLoaded message by the timeout, we won't have a MessageManager. Simple fix, but it looks like our timeout value probably isn't great.

I took a sample of 1273 users who had a timeout in the sanity test. Of these, 877 had a firstPaint of more than 6 seconds. Looking at overall telemetry for firstPaint, 20 seconds would cover ~90% of users so let's try that and see how it works.

Comment 2

[Vladan Djeric (:vladan)]

Would a longer timeout delay Firefox startup?

Comment 3

[David Anderson [:dvander] - inactive, e-mail if emergency]

(In reply to Vladan Djeric (:vladan) -- please needinfo! from comment #2)
> Would a longer timeout delay Firefox startup?

Nope, it shouldn't.

Comment 4

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a0afac66eb98

Comment 5

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/a0afac66eb98

Comment 6

[Vladan Djeric (:vladan)]

This change caused a big different in the GRAPHICS_SANITY_TEST data and triggered a Telemetry alert: 

https://groups.google.com/forum/#!topic/mozilla.dev.telemetry-alerts/bU5LzdV1HUU

dvander: is the new histogram distribution what you were hoping for?

Comment 7

[David Anderson [:dvander] - inactive, e-mail if emergency]

That's exactly what I was hoping for (in part). There's much less timeouts now that we've increased the timeout length. However, the amount of failures detected went up too. That's either good or bad depending on how you look at it (bad that we're failing, but good if we're now disabling video where it didn't work).