(No comment was entered for this change.)

for best scalability I would like to suggest what I have already said in the ML
Being the UA meta forced with chromeframe=1, where I guess 1 means "true" or "on", I
would use same strategy for the UA string when the plugin is disabled.

chromeframe installed but disabled, the UA will contain chromeframe=0
chromeframe installed and enabled, the UA contain chromeframe=1

If one day there will be possibility to decide which version of the plugin we would
like to run, chromeframe=2 or 4, or 5, to keep Chrome main revision consistent with
the chose one (so right now it should be chromeframe=4 , since this seems to be the
main revision)

Makes sense?

After a long discussion with Amit, we've decided not to fix this. Our options were:

  * patch vtables in order to modify the UA string for every request (brittle and 
problematic but would handle this)
  * implement an alternative form of disabling (toolbar UI, etc.) but leave the issue 
essentially untouched
  * implement a right-click style menu for "reload this page without GCF" and inform 
users that if they want to fully disable GCF, they should uninstall it.

We're opting for the 3rd.

I am going to regret this but Tommi, go ahead with your fix. :)

Issue 23994 has been merged into this issue.

(No comment was entered for this change.)

(No comment was entered for this change.)

fixed in http://src.chromium.org/viewvc/chrome?view=rev&revision=29370

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=29370 

------------------------------------------------------------------------
r29370 | tommi@chromium.org | 2009-10-16 21:48:37 -0700 (Fri, 16 Oct 2009) | 2 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/bho.cc?r1=29370&r2=29369
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/chrome_frame.gyp?r1=29370&r2=29369
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/chrome_tab.cc?r1=29370&r2=29369
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/html_utils.cc?r1=29370&r2=29369
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/html_utils.h?r1=29370&r2=29369
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/http_negotiate.cc
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/http_negotiate.h
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/protocol_sink_wrap.cc?r1=29370&r2=29369
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/protocol_sink_wrap.h?r1=29370&r2=29369
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/test/html_util_unittests.cc?r1=29370&r2=29369
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/test/http_negotiate_unittest.cc
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/utils.h?r1=29370&r2=29369
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/vtable_patch_manager.cc?r1=29370&r2=29369
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome_frame/vtable_patch_manager.h?r1=29370&r2=29369

Add the chromeframe tag to the user agent header at runtime instead of statically in the registry.TEST=Try disabling GCF and see if the chromeframe tag in the user agent is still set.  It should not be. Also make sure you don't have an older version installed... the chromeframe tag should not be in the registry - if it is, you've got an older version still registered.  This should fix the issue with going to wave.google.com after disabling chrome frame and seeing the white page of death.R=amitBUG=22760
Review URL: http://codereview.chromium.org/259025
------------------------------------------------------------------------

(No comment was entered for this change.)

Fixing a bulk edit. Looks like the search query was not correct.

This issue come back again in build 5.0.317.0 (Official Build 38070), have to reopen it.

This is a regression.

The code for this hasn't changed, so it would be nice if the following could be 
verified:
1. Was IE restarted after disabling the BHO? No other instance of IE was running?
2. Is "chromeframe" present under 
HKLM\Software\Microsoft\Windows\CurrentVersion\Internet Settings\User Agent\Post 
Platform

I didn't find a "chromeframe" under HKLM but I found it under HKCU, after I deleted
it IE becomes work fine.

It seems this is a legacy problem, close it then.