Closed Bug 1039226 Opened 11 years ago Closed 11 years ago

Trigger explicit OpenH264 updates from OpenH264Provider

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
normal
Points:
3

Tracking

()

VERIFIED FIXED
mozilla34
Iteration:
34.1
Tracking Status
firefox32 --- unaffected
firefox33 + verified
firefox34 --- verified

People

(Reporter: gfritzsche, Assigned: gfritzsche)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 2 obsolete files)

As a follow-up to bug 1009909, we need to trigger an update of OpenH264 explicitly from the OpenH264Provider via the API from bug 1009909.
Flags: firefox-backlog+
Summary: Trigger explicit OpenH264 from OpenH264Provider → Trigger explicit OpenH264 updates from OpenH264Provider
Note that I'm doing a check for update at most daily on Firefox startup on delayed Firefox startup.
Depends on: 1039490
Depends on: 1039555
Attached patch WIP (obsolete) — Splinter Review
This should be roughly what we want. I currently hit issues with the test mocking on browser_openH264.js, line 215: > TypeError: OpenH264Scope.OpenH264Wrapper is undefined
Depends on: 1039839
Depends on: 1040060
Iteration: --- → 33.3
Status: NEW → ASSIGNED
QA Whiteboard: [qa?]
QA Whiteboard: [qa?] → [qa+]
Attachment #8457005 - Attachment is obsolete: true
Attachment #8459672 - Flags: review?(bmcbride)
Comment on attachment 8459672 [details] [diff] [review] Triggering updates, test coverage Review of attachment 8459672 [details] [diff] [review]: ----------------------------------------------------------------- ::: toolkit/mozapps/extensions/internal/OpenH264Provider.jsm @@ +16,5 @@ > Cu.import("resource://gre/modules/Preferences.jsm"); > Cu.import("resource://gre/modules/osfile.jsm"); > Cu.import("resource://gre/modules/Log.jsm"); > +Cu.import("resource://gre/modules/Task.jsm"); > +Cu.import("resource://gre/modules/GMPInstallManager.jsm"); Should lazy-load this. @@ +171,5 @@ > aListener.onNoCompatibilityUpdateAvailable(this); > if ("onNoUpdateAvailable" in aListener) > aListener.onNoUpdateAvailable(this); > if ("onUpdateFinished" in aListener) > aListener.onUpdateFinished(this); I had assumed this was temporary - but then implementing AddonInstall for this is overkill. Can replace all those listener calls with just: AddonManagerPrivate.callNoUpdateListeners(this, aListener); @@ +173,5 @@ > aListener.onNoUpdateAvailable(this); > if ("onUpdateFinished" in aListener) > aListener.onUpdateFinished(this); > + > + if (aReason !== AddonManager.UPDATE_WHEN_USER_REQUESTED || Should let through UPDATE_WHEN_PERIODIC_UPDATE too - some people leave their browsers open for a Very Long Time, so the automatic check in browser.js doesn't help much there (this was mentioned somewhere in bug 1009816).
Attachment #8459672 - Flags: review?(bmcbride) → review-
(In reply to Blair McBride [:Unfocused] from comment #5) > Should let through UPDATE_WHEN_PERIODIC_UPDATE too - some people leave their > browsers open for a Very Long Time, so the automatic check in browser.js > doesn't help much there (this was mentioned somewhere in bug 1009816). Forgot to mention - the background update should only go ahead if the on-startup check hasn't happened in the past day. And you *DO* need to check the state of applyBackgroundUpdates when doing background update checks. AddonManager.shouldAutoUpdate() is a useful helper function here. AddonManager.jsm normally does this for you, but only if you use onUpdateAvailable and implement AddonInstall.
Iteration: 33.3 → 34.1
(In reply to Blair McBride [:Unfocused] from comment #6) > (In reply to Blair McBride [:Unfocused] from comment #5) > > Should let through UPDATE_WHEN_PERIODIC_UPDATE too - some people leave their > > browsers open for a Very Long Time, so the automatic check in browser.js > > doesn't help much there (this was mentioned somewhere in bug 1009816). > > Forgot to mention - the background update should only go ahead if the > on-startup check hasn't happened in the past day. > > And you *DO* need to check the state of applyBackgroundUpdates when doing > background update checks. AddonManager.shouldAutoUpdate() is a useful helper > function here. AddonManager.jsm normally does this for you, but only if you > use onUpdateAvailable and implement AddonInstall. That is not the scope of this bug though, i'll file a follow-up.
Attachment #8459672 - Attachment is obsolete: true
Attachment #8460326 - Flags: review?(bmcbride)
Blocks: 1042161
Whiteboard: [openh264-uplift]
Attachment #8460326 - Flags: review?(bmcbride) → review+
I think the easiest testing steps here are setting media.gmp-gmpopenh264.lastUpdate to something <1 day ago on a new profile before the automatic update/install happens. It's an int pref, seconds since unix epoch - e.g. just set it to the result of |Date.now()/1000 - 60|. Then trigger updates manually from either: * the context menu on openh264 in the list view of the Addons Manager plugin category * the detail view of openh264 - you need to turn automatic updates off to get the update link
QA Contact: drno
Hi Georg -- Do we still need to land this or did this get landed in another bug (or was it overtaken by events)?
Flags: needinfo?(georg.fritzsche)
Thanks for the reminder Maire, this dropped off my radar over the recent busy schedule. Fixed test and landed: https://hg.mozilla.org/integration/mozilla-inbound/rev/3c052ee8d76a
Flags: needinfo?(georg.fritzsche)
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
QA Contact: drno → alexandra.lucinet
Comment on attachment 8460326 [details] [diff] [review] Triggering updates, test coverage Approval Request Comment [Feature/regressing bug #]: OpenH264 integration. [User impact if declined]: Non-working manual triggering of update checks for the plugin. [Describe test coverage new/current, TBPL]: Automated testing, manual spot-checking, up on m-c. [Risks and why]: Low-risk, contained to the "find updates" actions in the addon manager UX. [String/UUID change made/needed]: None.
Attachment #8460326 - Flags: approval-mozilla-aurora?
Flags: in-testsuite+
Attachment #8460326 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Verified as fixed with latest Aurora 33.0a2 and Nightly 34.0a1 builds on Windows 7 x64, Mac OS X 10.9.4 and Ubuntu 13.04 64bit (e.g.: https://pastebin.mozilla.org/5804582 - logs after openh264 is installed and Find Updates option is selected).
Status: RESOLVED → VERIFIED
QA Whiteboard: [qa+] → [qa!]
Depends on: 1087674
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: