Closed Bug 1040941 Opened 7 years ago Closed 7 years ago

Non-functional "preference" button for Open H264 plugin (depending on state)


(Core :: WebRTC, defect)

Not set



Tracking Status
firefox32 --- unaffected
firefox33 + verified
firefox34 --- verified


(Reporter: drno, Assigned: gfritzsche)


(Blocks 1 open bug)



(2 files)

After the download of the Open H264 plugin the about:addons shows a "Preferences" button left to the drop down menu.
In that state the button is non-functional. If I manually chose "Always Activate" from the drop down menu, the button becomes functional.

I see two options here:
- do not show the button until the plugin is properly installed/activated
- make the button functional even if the plugin is disabled.
Georg -- Can I get you help triaging this?  Thanks.
Flags: needinfo?(georg.fritzsche)
I believe this is now a dup for properly enabling/disabling the OpenH264 plugin
Closed: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1041080
Should be fine by now, let me know if there still are issues.
Flags: needinfo?(georg.fritzsche)
The "Preference" button is visible all the time, no matter in which state the add-on is.
If the add-on is still waiting for download the button is non-functional.
If the add-on is disabled (after successful download) the button is non-functional.

I understand that in both states the actual preferences (if the user wants the plugin to automatically update itself or no) are not meaningful. But I think from a users perspective it is not acceptable to have a button which can be clicked, but does nothing.

I would like to see the "Preferences" button in these two states either somehow disabled, or even better do not show the button if the plugin is not active.
Resolution: DUPLICATE → ---
Summary: Non-functional "preference" button after Open H264 plugin download → Non-functional "preference" button for Open H264 plugin (depending on state)
Points: --- → 3
Flags: firefox-backlog+
OS: Mac OS X → All
Hardware: x86 → All
Georg -- I believe you're taking this yourself.
Assignee: nobody → georg.fritzsche
Users should always be able to disable the auto-update to stay in control, independent of install or enabled state of the plugin.

Blair, looks like we can't avoid patching extensions.js again.
Attachment #8459550 - Flags: review?(bmcbride)
Iteration: --- → 33.3
QA Whiteboard: [qa?]
QA Whiteboard: [qa?] → [qa+]
Comment on attachment 8459550 [details] [diff] [review]
Make preferences button always work

Review of attachment 8459550 [details] [diff] [review]:

Hmm, yea. At least we'll be able to clean this up sometime in the future.

There's actually two bugs here - the Preferences button shouldn't even have been shown in the first place (bug 1041859). But with this patch, bug 1041859 doesn't affect the OpenH264 plugin.
Attachment #8459550 - Flags: review?(bmcbride) → review+
Iteration: 33.3 → 34.1
Attachment #8459550 - Flags: checkin? → checkin+
Closed: 7 years ago7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
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
Whiteboard: [openh264-uplift]
Comment on attachment 8459550 [details] [diff] [review]
Make preferences button always work

Approval Request Comment
[Feature/regressing bug #]: plugin UI for GMP

[User impact if declined]: Unclickable button shown to users

[Describe test coverage new/current, TBPL]: none

[Risks and why]: fairly low risk; mostly to this button itself

[String/UUID change made/needed]: none
Attachment #8459550 - Flags: approval-mozilla-aurora?
Attachment #8459550 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Hi Alexandra, following up to see if this bug can be verified by the end of the iteration on Monday August 4.
Flags: needinfo?(alexandra.lucinet)
Reproduced with Nightly 2014-07-21: if the plugin is disabled, Options button is not functional.
Verified as fixed with latest Nightly (Build ID: 20140729030202) on Windows 7 x64, Ubuntu 13.04 x64 and Mac OS X 10.9.4.

Please flip back the [qa+] keyword once this fix lands on Aurora 33.
QA Whiteboard: [qa+] → [qa!]
Flags: needinfo?(alexandra.lucinet)
Verified as fixed with latest Aurora 33.0a2 (Build ID: 20140831004002) on Windows 7 64-bit, Mac OS X 10.9.4 and Ubuntu 14.04 32-bit.
You need to log in before you can comment on or make changes to this bug.