diff options
author | agl@chromium.org <agl@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-09-16 22:44:34 +0000 |
---|---|---|
committer | agl@chromium.org <agl@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-09-16 22:44:34 +0000 |
commit | 5be8fa84c198ead81d35aacb5fd106f81a3bdfe7 (patch) | |
tree | 94424816889d4c22ad2256573647ea9bff940c04 /chrome/common/pref_names.cc | |
parent | da67d252a2c42b5fd8c46f06e42f07c9c92294bb (diff) | |
download | chromium_src-5be8fa84c198ead81d35aacb5fd106f81a3bdfe7.zip chromium_src-5be8fa84c198ead81d35aacb5fd106f81a3bdfe7.tar.gz chromium_src-5be8fa84c198ead81d35aacb5fd106f81a3bdfe7.tar.bz2 |
Windows: Warn about outdated plugins.
Add the infrastructure for detecting out of date plugins and warning
the user about them.
Glen was ok with the infobar, although he notes that there will be a
better 'notifications' UI for this sort of thing in the future.
This UI will trigger at most once a day and only when we load the
plugin information.
This patch appears to duplicate some information from plugins2.xml,
which is the plugins database that the default plugin uses to install
missing plugins. I'm not reusing that information in this patch:
* Note that the names of the plugins are different between the two.
plugins2.xml uses a 'friendly' name, while this code needs to know
the name that the plugin itself uses.
* Also note that URLs are different. plugins2.xml wants a link to an
exe for the installer, while we want a landing page.
* The code for loading and parsing plugins2.xml is in the default
plugin, and thus would require a lot of major refactoring to use
here.
Regarding the second point, above. One could imagine that we open a
tab to "about:update-plugin#MAGICSTRING,application/x-shockwave".
Javascript on that page notes the fragment in the URL and creates a
plugin of the correct type on the page, passing MAGICSTRING to the
plugin. The renderers are updated to know that all plugins on about
pages should be directed to the default plugin.
The default plugin notes the MAGICSTRING argument and uses a new NPAPI
call to validate the string. MAGICSTRING will be a random string,
created once per instance which is needed so that the default plugin
can know that it's running on behalf of the browser, not some random
webpage. When it validates, it doesn't wait for the user to click
inside the plugin to trigger the download. It also doesn't trigger a
page reload afterwards, instead draws text to the effect of
"Successful install".
This alternative design would remove the duplication, at the cost of a
lot of work. Since it's a UI question, I asked Ben and Glen. However,
they didn't get back to me so, for now at least, this simplier
solution will suffice.
BUG=21100
http://codereview.chromium.org/197053
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@26409 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/common/pref_names.cc')
-rw-r--r-- | chrome/common/pref_names.cc | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/chrome/common/pref_names.cc b/chrome/common/pref_names.cc index 4ee3cb7..3d55aba 100644 --- a/chrome/common/pref_names.cc +++ b/chrome/common/pref_names.cc @@ -596,4 +596,8 @@ const wchar_t kSyncLastSyncedTime[] = L"sync.last_synced_time"; // Boolean specifying whether the user finished setting up sync. const wchar_t kSyncHasSetupCompleted[] = L"sync.has_setup_completed"; +// A double value giving the epoch time when we last nagged the user about +// outdated plugins. +const wchar_t kLastTimeNaggedAboutPlugins[] = L"plugins_last_nagged"; + } // namespace prefs |