summaryrefslogtreecommitdiffstats
path: root/chrome/common/pref_names.cc
diff options
context:
space:
mode:
authoragl@chromium.org <agl@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-09-16 22:44:34 +0000
committeragl@chromium.org <agl@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98>2009-09-16 22:44:34 +0000
commit5be8fa84c198ead81d35aacb5fd106f81a3bdfe7 (patch)
tree94424816889d4c22ad2256573647ea9bff940c04 /chrome/common/pref_names.cc
parentda67d252a2c42b5fd8c46f06e42f07c9c92294bb (diff)
downloadchromium_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.cc4
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