FoxyProxy 2.8.6+ force enables all plugins
Versions:
FoxyProxy 2.8.6-2.8.9
Windows XP SP3
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5
Steps to reproduce:
1. Create a brand new profile, all default settings, no other extensions.
2. Check that all plugins are enabled, then disable them.
3. Check that all plugins remain disabled after FF restart.
4. Install FP 2.8.5, check that all plugins remain disabled after FF restart.
5. Install FP 2.8.6-9: all* plugins are enabled after FF restart.
6. Disable all plugins, restart FF: all* plugins are enabled again.
7. Disable FP 2.8.6-9, restart FF, disable all plugins: they now stay disabled after FF restart.
8. Re-enable FP 2.8.6-9: all* plugins are again enabled after FF restart.
* except Java, which uses a different enabling mechanism
The same thing happens with an existing profile, regardless of what other extensions there are. Step 4. can be skipped, I included it to show where the change in behavior occurs.
BTW, this appears likely to be caused by the same issue that introduced the inability for the Google Toolbar to save its search history I reported earlier. But while that one could be considered a nuisance, this one seems like a rather serious potential security breach. I could live with not being able to save changes to plugin status without disabling FP, but FP forcing all plugins enabled upon every FF restart is something else entirely. I wish I'd noticed this when I noticed the search history issue, but it absolutely didn't occur to me that plugin settings could be messed with by FP. Going back to 2.8.5 for now...
Wow, that is really bizarre.
Wow, that is really bizarre. It's most bizarre that FP 2.8.5 doesn't cause this but 2.8.6 does. I need to do a thorough "diff" between the two versions to see what might be causing it. FWIW, there is nothing in FP that explicitly enables/disables plugins. In fact, there's nothing that touches plugins at all. This must be a side-effect of some other code in FP 2.8.6+.
Thanks for the detailed analysis and steps to reproduce. That will make it really easy to nail down the problem and either get it fixed in Firefox core or in FoxyProxy (Yes, FoxyProxy has illuminated bugs in Firefox core before)
Regards,
eric jung
foxyproxy author
What may be the cause
Hi, Eric (and Merry Christmas if you celebrate it :)
Glad I could help. I didn't think FP would do anything to the plugins directly. There seems to be something FP does that messes with the reading/writing of configuration files by other FF parts/add-ons, in this case pluginreg.dat and the Google Toolbar config file in the other case. The plugins seem to be reset because the browser thinks it doesn't have the plugin cache file, so it (apparently) rescans the plugins and enables them by default. Java is probably excempted because it's controlled by a user pref. I did some testing with what happens with pluginreg.dat that I'll try to write up later, but the gist of it appears to be some obstruction in reading/writing the file at some crucial times.
Interesting. I didn't even
Interesting. I didn't even know about pluginreg.dat (I admit my knowledge of plugins is limited more to their implementation than how Firefox manages and indexes them). I look forward to your info about it. Perhaps looking at the last modified date of the file will be helpful. In the meantime, I'm going to reach out to some Mozilla folks for advice on where to start.
Apparently you need to jar the chrome like you did before
It would appear that simply putting the FP chrome back into foxyproxy.jar the way it was in 2.8.5, and changing the manifest accordingly, fixes both the plugin and Google Toolbar problems. I'm not proficient enough in Mozilla details to know why exactly that should be the case, but that's the way it seems to be.
I tried rolling back some of the code changes to see it that helped, and when it didn't, I took the very blunt approach of replacing the extension subdirs one by one with 2.8.5 versions. When it turned out that using the 2.8.5 chrome with what was otherwise 2.8.6+ fixed the problem, and there was nothing obvious in the diffs to explain why, I tried jaring up the newer chrome and that works for me all the way up to today's 2.8.10 version.
Thanks for the work! This is
Thanks for the work! This is likely a problem with Firefox. I'm working on a minimal extension that exhibits the problem so I can file a new bug at http://bugzilla.mozilla.org. I've also been looking for workarounds... jar'ing the chrome isn't an option yet because it will cause other problems (see https://bugzilla.mozilla.org/show_bug.cgi?id=456705 for more info)
Well, at least it's a
Well, at least it's a work-around option for me on my PC, since I haven't encountered that crash problem you're working around by flattening the chrome.
I agree that this must be a larger problem with Firefox, because even if FP were doing something wrong, I've seen no documentation anywhere warning people about bizarre issues like these arising simply from the chome being jflat vs jar'ed. (Not that I'm an expert, but I think it'd come up more readily in docs if this was by design.) Hopefully you can sort this out with the Mozilla folk, and if you get a chance, please post the link to your new bug submission here as well.
Uh, make that "chrome being
Uh, make that "chrome being flat", not "chome being jflat"... lol
Hi, New Firefox bug opened
Hi,
New Firefox bug opened here: https://bugzilla.mozilla.org/show_bug.cgi?id=471245. It's interesting this bug doesn't occur on Ubuntu. It happens on Vista for me. I don't have OS/X to test there.
I've found a way to work
I've found a way to work around this problem. I'll issue FoxyProxy 2.8.11 soon with the fix.
Thanks for the fix
2.8.11 works fine for me.