Synchronize plugin activation state preferences




4 years ago
a year ago


(Reporter: gps, Unassigned)



Firefox Tracking Flags

(Not tracked)



(1 attachment)



4 years ago
I was disappointed to learn that setting Flash as click to activate on my laptop didn't propagate to my desktop machine via Sync. I think we should synchronize the plugin.state.* preferences automatically.

Comment 1

4 years ago
Created attachment 8559615 [details] [diff] [review]
Synchronize plugin.state.* preferences

I made Flash click to activate on my laptop and this change did not
propagate to my desktop machine. I think if a user exhibits a choice
to change the activation state of a plugin, we should synchronize that
across machines.

This may result in some wonky preferences being set because plugins
aren't synchronized across machines. For example, a machine without
Flash installed may end up with a "plugin.state.flash" preference
if that pref was modified on a machine with Flash enabled. There
should be little harm caused by this, however. The flip side is that
if a user disables a plugin on one machine and that plugin is later
installed on another machine (say the plugin is malware the user
doesn't want), the newly-installed plugin may get disabled courtesy
of the existing synced preference. (Although, it's possible the Add-on
Manager may reset the pref during installation - I dunno.)

My Sync memory isn't as sharp as it once was. Putting the pref scanning
code in tracker start may not be the best location. But it is easy and
I'm pretty sure it works.
Attachment #8559615 - Flags: review?(rnewman)
Attachment #8559615 - Flags: feedback?(bmcbride)
Attachment #8559615 - Flags: feedback?(benjamin)


4 years ago
Assignee: nobody → gps
(In reply to Gregory Szorc [:gps] from comment #1)
> (Although, it's possible the Add-on
> Manager may reset the pref during installation - I dunno.)

Nope, prefs aren't modified when a new plugin is detected.
Attachment #8559615 - Flags: feedback?(bmcbride) → feedback+


4 years ago
Blocks: 530399

Comment 3

4 years ago
I don't have any thoughts on the implementation: in terms of the experience, I think that this should be controlled by the "sync addons" checkbox and not the "sync preferences" checkbox, because the UI controls for this appear in the addons manager.


4 years ago
Attachment #8559615 - Flags: feedback?(benjamin)
Comment on attachment 8559615 [details] [diff] [review]
Synchronize plugin.state.* preferences

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

I'd prefer a data-driven approach here.

That is, make the small change to engines/prefs.js to support branches (prefs ending in ".") instead of just individual prefs, and then add

  services.sync.prefs.sync.plugin.state. = true

to browser/app/profile/firefox.js.

Also, I haven't tested, but I think your patch won't work for the first sync if each device has different plugin prefs (which is the reason why you do it dynamically): on the receiving device, unless it's lucky enough to see the Sync enablement pref first (i.e., the s.s.prefs.sync.plugin.state.whatever pref), the call to _isSynced for plugin.state.whatever will return false.

A subsequent sync should apply the pref correctly, but that might take a while, and if the second device syncs first, it'll force its own plugin state on the other device...
Attachment #8559615 - Flags: review?(rnewman) → review-

Comment 5

4 years ago

I was hoping this would be a quick itch scratch. As much as I'd like to see this feature to completion, I have other projects to worry about. Back in the pool :/
Assignee: gps → nobody


3 years ago
Priority: -- → P3
Severity: normal → enhancement
Priority: P3 → --
plugins have almost completely gone away, and will be completely gone soon.
Last Resolved: a year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.