1040937 - Open H264 plugin stuck in disabled state after download

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Nils Ohlmeier [:drno]]

Attachment: Screen Shot 2014-07-18 at 1.15.57 PM.png

After starting the 10.8 opt try build from here https://tbpl.mozilla.org/?tree=Try&rev=98fb3c863308 on Mac OSX 10.9 the Open H264 plugin gets installed, but the plugin stays in the disabled state.

Comment 1

[Nils Ohlmeier [:drno]]

Restarting Firefox does not change this status.

Comment 2

[Maire Reavy [:mreavy]]

Georg -- Any idea why this would happen?  Nils used Brian's try push which should have all the settings we need.

Comment 3

[Nils Ohlmeier [:drno]]

If I set the environment variable MOZ_GMP_PATH to a directory with a copy of the plugin and the last directory in that path being named "gmp-gmpopenh264" I get a working call with H264.
In this case I do not have to make any more changes (beside the env var). And the plugin on the about:addons page stays disabled as described above.

Comment 4

[Nils Ohlmeier [:drno]]

Manually setting the plugin to "Always Activated" has no effect.

Comment 5

[Nils Ohlmeier [:drno]]

H264 settings present in this state:
[e-mail];1405715605
[e-mail];/Users/nohlmeier/Library/Application Support/Firefox/Profiles/qswgxl68.h269/[e-mail]
[e-mail];1.0
media.openh264.providerEnabled;true
media.peerconnection.video.h264_enabled;false

Comment 6

[Georg Fritzsche [:gfritzsche]]

Nils or Brian, can you point me to QA docs or steps on how to trigger download/install, so i can check?
(ideally for a dev/local build, not Nightly)

Comment 7

[Georg Fritzsche [:gfritzsche]]

Also, where and how do i check for a working call?

Comment 8

[Georg Fritzsche [:gfritzsche]]

(In reply to Nils Ohlmeier [:drno] from comment #5)
> [e-mail];/Users/nohlmeier/Library/Application
> Support/Firefox/Profiles/qswgxl68.h269/[e-mail]
> [e-mail];1.0

The issue is the pref names:
* the installer/updater code sets [e-mail] & [e-mail]
* the addon manager code reads/watches the previously defined media.openh264.path & media.openh264.version and hence doesn't pick up anything

... the question is which part to change.

Comment 9

[Nils Ohlmeier [:drno]]

(In reply to Georg Fritzsche [:gfritzsche] from comment #7)
> Also, where and how do i check for a working call?

Go to this URL http://mozilla.github.io/webrtc-landing/pc_test.html check the "Require H.264 video" option and check the video players and the log output at the bottom of the page.

Comment 10

[Nils Ohlmeier [:drno]]

(In reply to Georg Fritzsche [:gfritzsche] from comment #6)
> Nils or Brian, can you point me to QA docs or steps on how to trigger
> download/install, so i can check?
> (ideally for a dev/local build, not Nightly)

My understanding is that there is not really anything to make it download. You simply have to wait for ~1 min for the download of the plugin to start.

Comment 11

[Georg Fritzsche [:gfritzsche]]

Attachment: Make OpenH264Provider use the same pref names as GMPInstallManager

Comment 12

[Georg Fritzsche [:gfritzsche]]

Per IRC discussion we're just changing the OpenH264Provider pref names to match the GMPInstallManager.

Comment 13

[Brian R. Bondy [:bbondy]]

Make sure media.gmp-manager.lastCheck does not exist, if it does, then reset the value.
Close browser, open, and after 1 minute it'll install. 

If you run into problems, reset media.gmp-manager.lastCheck again and set media.gmp-manager.log to true.
Also set browser.dom.window.dump.enabled to true and javascript.options.showInConsole to true.

Then open the browser, wait for a minute and check your browser console. There will be a clear indication of what went wrong in GMPInstallManager.

If you get the prefs you watch for, it'll show you where the dylib and info files are.

Comment 14

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Fix platform and GMPInstallManager/OpenH264Provider using different directory names

Comment 15

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Fix GMPInstallManager and OpenH264Provider using different pref names.

Comment 16

[Randell Jesup [:jesup] (needinfo me)]

Attachment: extensions.js change

Comment 17

[Randell Jesup [:jesup] (needinfo me)]

Attachment: extensions.js change

Comment 18

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 19

[Randell Jesup [:jesup] (needinfo me)]

https://hg.mozilla.org/mozilla-central/rev/35f3fa435d2c

Comment 20

[Randell Jesup [:jesup] (needinfo me)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/bdf16778db9c
https://hg.mozilla.org/integration/mozilla-inbound/rev/36f891d6eaec

Merged over from m-c to help peole working today

Comment 22

[Marco Mucci [:MarcoM]]

Hi Georg, can you mark this bug as [qa+] or [qa-] for verification.

Comment 23

[Marco Mucci [:MarcoM]]

Hi Florin, can a QA contact be assigned for verification of this bug.

Comment 24

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/bdf16778db9c
https://hg.mozilla.org/mozilla-central/rev/36f891d6eaec

Comment 25

[Ada [:adalucinet]]

Reproduced with https://tbpl.mozilla.org/?tree=Try&rev=98fb3c863308 try build: the plugin remains in disabled state.
Verified as fixed with latest Aurora 33.0a2 (Build ID: 20140723004001) on Windows 7 x64, Ubuntu 14.04 x32 and Mac OS X 10.9.4.

Comment 26

[Georg Fritzsche [:gfritzsche]]

(In reply to Alexandra Lucinet, QA Mentor [:adalucinet] from comment #25)
> Reproduced with https://tbpl.mozilla.org/?tree=Try&rev=98fb3c863308 try
> build: the plugin remains in disabled state.

You mean it *doesn't* remain in disabled state?

Comment 27

[Ada [:adalucinet]]

No, it *does* remain in disabled state with the try build (the bug is reproducible there). It *doesn't* with latest Nightly and Aurora builds.