On Fri, Oct 9, 2009 at 7:59 AM, Scott Hess <sh...@chromium.org> wrote: > > Of course, it didn't ACTUALLY get better until I got annoyed enough to > figure out how to upgrade my system's version of flash. I went out > and followed web instructions for apt-removing the older version and > installed the newer deb from Adobe. > > Of course, that didn't fix it either. Eventually it bugged me enough > to do something else, so I figured "Maybe about:plugins?", and it gave > me a page, and I noticed that I had two flash plug-ins. Didn't tell > me where they were coming from, though. Eventually I found the second > plug-in in .mozilla/plugins. Being confident in my ability to restore > Firefox from the ground up, I nuked it from orbit.
I would like this too. Part of the problem is that about:plugins is a plain HTML page -- it has no special privs -- so the information we provide on the page is constrained by the API and information we're willing to provide to random websites. It would be useful to have a more powerful page that includes plugin paths, but (as you mention before) it's not especially discoverable and we shouldn't expect every user to debug this themselves. (Also: the page also has a silly "enabled" column that is meaningless for us since (AFAIK) there's no way to change it.) The which-plugin-am-I-getting situation on Linux is *incredibly* confusing, in no small part due to the variety found on real-world systems. Check out this code: http://svn.beauchesne.info/gwenole/projects/nspluginwrapper/trunk/src/npw-config.c?revision=881&view=markup search for "usr" in there (and then keep jamming on ctl-g) to see the variety of paths that have existed. On top of that, on Debian systems you have two layers of symlinks around the alternatives system, and then seven different setups of that for just Flash: $ ls /etc/alternatives/*flash* | wc -l 7 And then there's also nspluginwrapper, and *also* that we only load plugins matching the bit-ness (32/64) of the browser binary, so some are silently dropped on startup... And *then* that if we print any diagnostic information about this while loading, that output ends up in layout tests so all tests fail. There's a --debug-plugin-loading flag I sometimes get users to use to help track down what a bug report is exactly reporting. > Given the history of ways to install things on Linux, I wonder if it > wouldn't be worth having additional information for that platform > about stuff like this. about:plugins tells me the filename to look > for, but not where to look. And about:plugins isn't very > discoverable, even if you know that you should be looking for > something - I think that if we see two versions of libflashplayer.so, > we can be pretty sure something is wrong. We de-duplicate multiple instances of the same file. If you have multiple copies of the same file we attempt to prioritize non-nspluginwrapper versions over nspluginwrapper-wrapped versions. After that, the list of plugins displayed is not the list of plugins that are *loaded* -- we only actually plugins in a per-plugin process, and only the first match, so having multiple libflashplayer.so should be fine. --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: chromium-dev@googlegroups.com View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
