Issue 1103 - Migrate Simple Adblock users

src/engine/Main.cpp

Index: src/engine/Main.cpp
===================================================================
--- a/src/engine/Main.cpp
+++ b/src/engine/Main.cpp
@@ -87,6 +87,7 @@
   CriticalSection updateCheckLock;
   bool firstRunActionExecuted = false;
   AdblockPlus::ReferrerMapping referrerMapping;
+  std::string convertedFrom = "";
   Communication::OutputBuffer HandleRequest(Communication::InputBuffer& request)
   {
     Communication::OutputBuffer response;
@@ -367,6 +368,27 @@
         }
         break;
       }
+      case Communication::PROC_GET_CONVERTED_FROM:
+      {
+        if (convertedFrom != "")
+        {
+          response << convertedFrom;
+          break;
+        } 
+        std::wstring updatedFromKeyPath = L"Software\\Adblock Plus for IE\\ConvertedFrom";
+        try
+        {
+          AdblockPlus::RegistryKey updatedFromKey(HKEY_CURRENT_USER, updatedFromKeyPath);
+          convertedFrom = ToUtf8String(updatedFromKey.value_wstring(L"name"));
+        }
+        catch(std::runtime_error)
+        {
+          break;
+        }
+        LONG res = RegDeleteKey(HKEY_CURRENT_USER, updatedFromKeyPath.c_str());

[Eric, 2015/08/10 17:08:49]

Deleting the key immediately after returning its status means that the
combination of 
  (1) display conversion page and 
  (2) delete the flag that mandates the display
is not an atomic action. In other words if there's an error displaying the page,
or a _de facto_ failure for the user to see it, such as immediate shutdown, then
we don't get another chance to show the page again.

If I understand the comment that introduced this patch set, this change is
possible because a medium integrity engine can delete the registry key whereas a
low integrity one cannot. (This point should be commented in the code, also.)
Assuming that's right, all we need in the engine is to be able to delete the
key. We can still read it in the plugin, where we'd also have access to any
display error.

If we didn't need medium integrity to delete such a key, we wouldn't need this
piece in the engine at all. It could all go in the plugin. This is a design
point worth documenting in the code. I wouldn't consider it obvious, since these
permission are ambient (not directly visible in the code) and their behavior
with respect to the registry is something most don't concern themselves with.

I do understand that there's JavaScript code involved as well, so it's not quite
as simple as I'm making it out, but it's still a design problem to bind query
and delete together as it is here.

+        response << convertedFrom;
+        break;
+      }
     }
     return response;
   }