1057990 - GMPInstallManager installing openh264 plugin while testrun is underway

Status: RESOLVED WONTFIX

(Mozilla QA Graveyard :: Mozmill Tests, defect)

Description

[Andrei Eftimie]

I've noticed lately that Firefox is installing the openh264 plugin sometime after it is started without any intervention.

It might be worth investigating if this can affect our testruns.
For example this was installed during one test where we would wait for an external resource to load. There is a possibility that this test failed because the bandwidth was occupied by the plugin thus the page took longer then expected to load:
> 04:20:58 1408879193797  GMPInstallManager.simpleCheckAndInstall INFO  Last check was: 1408879194 seconds ago, minimum seconds: 86400
> 04:20:58 1408879193797  GMPInstallManager._getURL INFO  Using url: https://aus4.mozilla.org/update/3/GMP/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/%LOCALE%/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml
> 04:20:58 1408879193798  GMPInstallManager._getURL INFO  Using url (with replacement): https://aus4.mozilla.org/update/3/GMP/33.0a2/20140824004001/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/aurora/Darwin%2012.5.0/default/default/update.xml
> 04:20:58 1408879193800  GMPInstallManager.checkForAddons  INFO  sending request to: https://aus4.mozilla.org/update/3/GMP/33.0a2/20140824004001/Darwin_x86_64-gcc3-u-i386-x86_64/en-US/aurora/Darwin%2012.5.0/default/default/update.xml
> 04:20:59 1408879193900  GMPInstallManager.onLoadXML INFO  request completed downloading document
> 04:20:59 1408879193901  GMPInstallManager.onLoadXML INFO  allowNonBuiltIn: false
> 04:20:59 1408879193911  GMPInstallManager.simpleCheckAndInstall INFO  Found 1 addons advertised.
> 04:20:59 1408879193911  GMPInstallManager.simpleCheckAndInstall INFO  Found addon: gmp-gmpopenh264 (isValid: true, isInstalled: false, isOpenH264: true, hashFunction: SHA512, hashValue: 57c2b23c97e32d21ff9f6f611803cfdf6ba4a97f7b403c031e979a79c1db1f507d9b72749824254892032f119a4d057cec926fbc4efb184c4f543dfd34ad72a2, size: 282436)
> 04:20:59 1408879193931  GMPInstallManager.simpleCheckAndInstall INFO  Addon installed successfully: gmp-gmpopenh264 (isValid: true, isInstalled: true, isOpenH264: true, hashFunction: SHA512, hashValue: 57c2b23c97e32d21ff9f6f611803cfdf6ba4a97f7b403c031e979a79c1db1f507d9b72749824254892032f119a4d057cec926fbc4efb184c4f543dfd34ad72a2, size: 282436)
> 04:21:02 ERROR | Test Failure | {
> 04:21:02   "exception": {
> 04:21:02     "message": "controller.waitForPageLoad(URI=https://www.stopbadware.org/firefox?hl=zh-CN&url=https%3A%2F%2Fwww.itisatrap.org%2Ffirefox%2Fits-an-attack.html, readyState=loading)", 
> 04:21:02     "lineNumber": 27, 
> 04:21:02     "name": "AssertionError", 
> 04:21:02     "fileName": "resource://mozmill/modules/errors.js"
> 04:21:02   }
> 04:21:02 }
> 04:21:02 TEST-UNEXPECTED-FAIL | testSecurity/testSafeBrowsingNotificationBar.js | testNotificationBar

AFAIK this plugin is needed for WebRTC, so we might be safer to disable it completely for mozmill-tests for now (if it indeed can affect our tests stability)

Comment 1

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I don't think there is a way to prevent the installation of the gmp plugin. But Nils might know more, and what we could do here.

Comment 2

[Nils Ohlmeier [:drno]]

According to bug 1046644 we should have now the user pref media.gmp-gmpopenh264.autoupdate allowing us to disable the download of the OpenH264 plugin.

Comment 3

[Georg Fritzsche [:gfritzsche]]

It would be much better to not disable the autoupdate and instead set a dummy URL override like this:
https://hg.mozilla.org/releases/mozilla-aurora/rev/c0e95adfb454#l1.13

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Can I ask how much data we have to download for this plugin? I wonder if that really is a problem for us.

Comment 5

[Andrei Eftimie]

I'm not concerned about data-volume, but about interference (i.e. blocking the main thread bug 1039490). Unfortunately I have no testcase and can't be sure of its effects. Maybe we should not do any changes until we have a way of measuring the impact.

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Interesting bug. It looks like nothing which can be fixed shortly. So my question still persists, in how much data we have to download. If its only a couple of kb, I don't see a problem for our CI machines in SCL3 given the good bandwidth.

Comment 7

[Georg Fritzsche [:gfritzsche]]

This isn't very big, e.g. via here:
https://aus4.mozilla.org/update/3/GMP/34.0a1/20140825171445/Darwin_x86_64-gcc3/en-US/default/Windows 7.0/default/default/update.xml
... it's 276kb for Darwin:
http://ciscobinary.openh264.org/openh264-macosx64-master-300cceaabf0c423a3f464c963ac1b7abdae6e6b3.zip

If you can keep this enabled and are not worried about hitting the network, then the added test-coverage would be nice to have.

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

That's indeed very small. So I don't see how this would cause network issues and timeouts for waitForPageLoad. Also unzipping the file should be done kinda quick. I would vote for keeping it in.

Comment 9

[Andrei Eftimie]

In that case let us leave this in.
We should be aware that this happens and monitor further to see if there's any impact.