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=881view=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
-~--~~~~--~~--~--~---
