Open H264 plugin stuck in disabled state after download

VERIFIED FIXED in mozilla33

Status

()

defect
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: drno, Assigned: gfritzsche)

Tracking

(Blocks 1 bug)

Trunk
mozilla33
Points:
3
Dependency tree / graph
Bug Flags:
firefox-backlog +
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments, 2 obsolete attachments)

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.
Restarting Firefox does not change this status.
Georg -- Any idea why this would happen?  Nils used Brian's try push which should have all the settings we need.
Flags: needinfo?(georg.fritzsche)
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.
Manually setting the plugin to "Always Activated" has no effect.
H264 settings present in this state:
media.openh264-plugin@cisco.com.lastUpdate;1405715605
media.openh264-plugin@cisco.com.path;/Users/nohlmeier/Library/Application Support/Firefox/Profiles/qswgxl68.h269/openh264-plugin@cisco.com
media.openh264-plugin@cisco.com.version;1.0
media.openh264.providerEnabled;true
media.peerconnection.video.h264_enabled;false
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)
Flags: needinfo?(netzen)
Flags: needinfo?(drno)
Also, where and how do i check for a working call?
Flags: needinfo?(georg.fritzsche)
(In reply to Nils Ohlmeier [:drno] from comment #5)
> media.openh264-plugin@cisco.com.path;/Users/nohlmeier/Library/Application
> Support/Firefox/Profiles/qswgxl68.h269/openh264-plugin@cisco.com
> media.openh264-plugin@cisco.com.version;1.0

The issue is the pref names:
* the installer/updater code sets media.openh264-plugin@cisco.com.path & media.openh264-plugin@cisco.com.version
* 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.
(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.
Flags: needinfo?(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.
Assignee: nobody → georg.fritzsche
Status: NEW → ASSIGNED
Attachment #8459045 - Flags: review?(netzen)
Points: --- → 3
Flags: needinfo?(netzen) → firefox-backlog+
Attachment #8459045 - Flags: review?(netzen) → review+
Per IRC discussion we're just changing the OpenH264Provider pref names to match the GMPInstallManager.
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.
Component: WebRTC → Add-ons Manager
Keywords: checkin-needed
OS: Mac OS X → All
Product: Core → Toolkit
Hardware: x86 → All
Attachment #8459086 - Flags: review?(bmcbride)
Attachment #8459087 - Flags: review?(bmcbride)
Iteration: --- → 33.3
QA Whiteboard: [qa?]
Attachment #8459045 - Attachment is obsolete: true
Attachment #8459086 - Flags: review?(bmcbride) → review+
Attachment #8459087 - Flags: review?(bmcbride) → review+
Attachment #8459088 - Flags: review?(bmcbride)
Attachment #8459088 - Attachment is obsolete: true
Attachment #8459088 - Flags: review?(bmcbride)
Attachment #8459089 - Flags: review?(bmcbride)
Attachment #8459089 - Flags: review?(bmcbride) → review+
https://hg.mozilla.org/mozilla-central/rev/d774179cdc65
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
Duplicate of this bug: 1041097
Hi Georg, can you mark this bug as [qa+] or [qa-] for verification.
Flags: needinfo?(georg.fritzsche)
QA Whiteboard: [qa?] → [qa+]
Flags: needinfo?(georg.fritzsche)
Hi Florin, can a QA contact be assigned for verification of this bug.
Flags: needinfo?(florin.mezei)
Flags: needinfo?(florin.mezei)
QA Contact: alexandra.lucinet
Iteration: 33.3 → 34.1
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.
Status: RESOLVED → VERIFIED
QA Whiteboard: [qa+] → [qa!]
(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?
Flags: needinfo?(alexandra.lucinet)
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.
Flags: needinfo?(alexandra.lucinet)
You need to log in before you can comment on or make changes to this bug.