Proof-of-concept: Link version to corresponding announcement

options.js

Index: options.js
===================================================================
--- a/options.js
+++ b/options.js
@@ -646,15 +646,47 @@
     ext.backgroundPage.sendMessage(
     {
       type: "app.get",
-      what: "addonVersion"
+      what: "info"
     },
-    function(addonVersion)
+    function(info)
     {
-      E("abp-version").textContent = addonVersion;
-    });
-    getDocLink("releases", function(link)
-    {
-      E("link-version").setAttribute("href", link);
+      E("abp-version").textContent = info.addonVersion;
+
+      fetch("https://adblockplus.org/atom/?section=releases&limit=100").then(function(response)

[Thomas Greiner, 2016/02/05 14:24:37]

We shouldn't ping our servers everytime someone opens the options page. Maybe we
could do it once for each version to find the corresponding blog post. However,
even then I'm still seeing issues with our privacy policy and with the
reliability of this interface since we'd have to keep this URL alive
indefinitely.

Taking all of that into consideration we'd end up with something like this:

1. User clicks on link
2. We check whether we already know the link to the blog post for this version
   If not:
     a. Fetch list of blog posts
     b. Remove stored link to blog post for previous version (if any)
     c. Determine and store link to the corresponding blog post (preferrably not
dependent on patterns in blog post title or URL)
3. Open blog post

Obviously, that'd still be inferior to having a dynamic redirect on the server
side à la
"https://adblockplus.org/redirect?link=releases&lang=de&application=chrome&addonVersion=1.10.1".

[Wladimir Palant, 2016/02/05 14:29:44]

Indeed. If we need this feature we need to set up a redirect for each release -
everything else would be wrong.

[Sebastian Noack, 2016/02/05 14:37:18]

Please note the alternative approach in patch set 2. The request there is only
sent when the link is clicked. With a fallback through a redirect to the release
overview.

This should address all concerns. We wouldn't send a request no matter what, but
only when the user is about to navigate to our website anyway. Also, if for some
reasons the blog will be taken off or moved in the future, or if there simply
isn't an announcement that matches, we fallback to the releases overview through
a redirect by our server.

+      {
+        return repsonse.ok ? response.text() : "";
+      }).then(
+      function(text)
+      {
+        var doc = new DOMParser().parseFromString(text, "application/xml");
+        var entries = doc.getElementsByTagName("entry");
+        for (var i = 0; i < entries.length; i++)
+        {
+          var entry = entries[i];
+          var title = entry.getElementsByTagName("title")[0];
+          if (!title)
+            continue;
+
+          var lowerCaseTitleText = title.textContent.toLowerCase();
+          if (lowerCaseTitleText.split(/\W+/).indexOf(info.application) == -1)

[Thomas Greiner, 2016/02/05 14:24:37]

That doesn't seem too reliable because it's more of a coincidence that the
application name is part of the blog post title.

[Sebastian Noack, 2016/02/05 14:37:18]

I guess we could omit that check as well. Not sure if that would be more
reliable though.

+            continue;
+          if (lowerCaseTitleText.split(/\s+/).indexOf(info.addonVersion) == -1)
+            continue;
+
+          var links = entry.getElementsByTagName("link");
+          for (var j = 0; j < links.length; j++)
+          {
+            var link = links[j];
+            var href = link.getAttribute("href");
+
+            if (link.getAttribute("rel") == "alternate" && href)
+            {
+              E("version").setAttribute("href", href);
+              return;
+            }
+          }
+        }
+      }).catch(function() {});
     });
 
     getDocLink("contribute", function(link)