Closed
Bug 554780
Opened 15 years ago
Closed 12 years ago
Make plugins provider correctly handle plugins being added and removed through detection at runtime
Categories
(Toolkit :: Add-ons Manager, defect, P2)
Toolkit
Add-ons Manager
Tracking
()
RESOLVED
FIXED
mozilla21
People
(Reporter: mossop, Assigned: mossop)
References
Details
(Whiteboard: [rewrite])
Attachments
(1 file, 1 obsolete file)
17.48 KB,
patch
|
Unfocused
:
review+
lsblakk
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
We still need to send events for when new plugins are detected/removed.
Updated•15 years ago
|
Flags: in-testsuite?
Flags: in-litmus-
Assignee | ||
Updated•15 years ago
|
Assignee: dtownsend → nobody
Comment 1•14 years ago
|
||
Dave, I don't know if you have a bug on this, or this is backend work, although it doesn't look like it, but Remove plugin doesn't appear to do anything. I was thinking of filing a bug on that. One plugin that was bothersome is the Bing Bar which gets installed with Windows Live Essentials. I tried to remove it but it didn't do anything. I resorted to using the control panel in windows.
Assignee | ||
Comment 2•14 years ago
|
||
There shouldn't be a remove button for plugins, if there is it is a separate bug that should be filed.
Comment 3•14 years ago
|
||
ok, Done.
Comment 4•14 years ago
|
||
(In reply to comment #2)
> There shouldn't be a remove button for plugins, if there is it is a separate
> bug that should be filed.
bug 588888
Assignee | ||
Updated•13 years ago
|
Summary: Implement additional events for plugins provider → Make plugins provider correctly handle plugins being added and removed through detection at runtime
Assignee | ||
Comment 8•12 years ago
|
||
I have a straightforward patch for this. It will make it appear through the add-ons manager API as if updated plugins are simple uninstalled and installed again which is enough to keep things working sane in cases like bug 823085. It still won't be perfect if the UI is open when plugin changes occur and the user attempts to make changes to the old plugin before a re-scan occurs but that seems a rare enough event that we should defer it to a follow-up.
Assignee: nobody → dtownsend+bugmail
Assignee | ||
Comment 9•12 years ago
|
||
Attachment #705119 -
Flags: review?(bmcbride)
Comment 10•12 years ago
|
||
Comment on attachment 705119 [details] [diff] [review]
patch rev 1
Review of attachment 705119 [details] [diff] [review]:
-----------------------------------------------------------------
Just a couple of issues with event order/consistency.
::: toolkit/mozapps/extensions/PluginProvider.jsm
@@ +69,5 @@
>
> observe: function(aSubject, aTopic, aData) {
> + switch (aTopic) {
> + case AddonManager.OPTIONS_NOTIFICATION_DISPLAYED:
> + this.getAddonByID(aData, function(plugin) {
Nit: Since you're changing this code anyway, care to name this function?
Also, I wonder if this block of code should be moved into it's own function now.
@@ +237,5 @@
> + let newWrapper = this.buildWrapper(newList[id]);
> +
> + if (newWrapper.isActive != oldWrapper.isActive) {
> + AddonManagerPrivate.callAddonListeners(newWrapper.isActive ? "onEnabling" : "onDisabling", newWrapper, false);
> + AddonManagerPrivate.callAddonListeners(newWrapper.isActive ? "onEnabled" : "onDisabled", newWrapper);
Shouldn't onEnabled be sent out after updating this.plugins, like onUninstalled is?
Nit: I can haz shorter lines?
@@ +254,5 @@
> + // Finally send out any new plugins.
> + for (let plugin of newPlugins) {
> + AddonManagerPrivate.callInstallListeners("onExternalInstall", null,
> + plugin, null, false);
> + AddonManagerPrivate.callAddonListeners("onInstalling", plugin, false);
Similarly, onExternalInstall and onInstalling should be sent out before updating this.plugins.
::: toolkit/mozapps/extensions/test/xpcshell/test_pluginchange.js
@@ +215,5 @@
> +
> +// Replacing flash should be detected
> +function run_test_6() {
> + let oldTag = PLUGINS.splice(0, 1)[0];
> + let newTag = new PluginTag("Flash 2", "A new crash-free Flash!");
This doesn't seem very realistic ;)
Attachment #705119 -
Flags: review?(bmcbride) → review-
Updated•12 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 11•12 years ago
|
||
(In reply to Blair McBride [:Unfocused] (Back from the dead. Mostly.) from comment #10)
> ::: toolkit/mozapps/extensions/test/xpcshell/test_pluginchange.js
> @@ +215,5 @@
> > +
> > +// Replacing flash should be detected
> > +function run_test_6() {
> > + let oldTag = PLUGINS.splice(0, 1)[0];
> > + let newTag = new PluginTag("Flash 2", "A new crash-free Flash!");
>
> This doesn't seem very realistic ;)
Don't destroy my hope!
Assignee | ||
Comment 12•12 years ago
|
||
Updated, would be nice to get this in before the uplift as long as it doesn't break your brain
Attachment #705119 -
Attachment is obsolete: true
Attachment #714035 -
Flags: review?(bmcbride)
Updated•12 years ago
|
Attachment #714035 -
Flags: review?(bmcbride) → review+
Assignee | ||
Comment 13•12 years ago
|
||
Target Milestone: --- → mozilla21
Comment 14•12 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Comment 16•12 years ago
|
||
Should this possibly be nominated for uplift?
Updated•12 years ago
|
status-firefox19:
--- → affected
status-firefox20:
--- → affected
status-firefox21:
--- → fixed
tracking-firefox20:
--- → ?
Comment 17•12 years ago
|
||
(In reply to Georg Fritzsche [:gfritzsche] from comment #16)
> Should this possibly be nominated for uplift?
Would bug 823085 be the main motivation?
Comment 18•12 years ago
|
||
(In reply to Alex Keybl [:akeybl] from comment #17)
> (In reply to Georg Fritzsche [:gfritzsche] from comment #16)
> > Should this possibly be nominated for uplift?
>
> Would bug 823085 be the main motivation?
Yes, sorry for the missing details.
With mainly Flash doing updates now while Firefox is running, the Addon Manager UI can become broken. Unintended changes to plugin states might also be possible.
Comment 19•12 years ago
|
||
Please nominate for uplift, let's get this into our next Beta so it can be tested/verified sooner rather than later.
Assignee | ||
Comment 20•12 years ago
|
||
Comment on attachment 714035 [details] [diff] [review]
patch rev 2
[Approval Request Comment]
Bug caused by (feature/regressing bug #): Firefox 4
User impact if declined: Add-ons Manager UI displays incorrect information if plugins are updated while Firefox is running
Testing completed (on m-c, etc.): Been in tree for a while
Risk to taking this patch (and alternatives if risky): I think the risk of regression is low, if the code has problems then they should only exhibit themselves in the cases where we were already broken.
String or UUID changes made by this patch: None
Attachment #714035 -
Flags: approval-mozilla-beta?
Updated•12 years ago
|
Attachment #714035 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Comment 21•12 years ago
|
||
Comment 22•12 years ago
|
||
What exactly needs to be tested here?
While I was trying a Flash update with Firefox opened, I spotted the broken UI from bug 823085.
You need to log in
before you can comment on or make changes to this bug.
Description
•