Add full text regex searching to chrome://sync

chrome/browser/resources/sync_internals/sync_search.js

 // Copyright (c) 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // require: cr.js
 
 cr.define('chrome.sync', function() {
   var currSearchId = 0;
 
   /**
    * Runs a search with the given query.
    *
-   * @param {string} query The query to do the search with.
-   * @param {Array.<{id: string, title: string, isFolder: boolean}>}
+   * @param {string} query The regex to do the search with.
+   * @param {Array.<NodeSummary>}
    *     callback The callback called with the search results; not
    *     called if doSearch() is called again while the search is
    *     running.
    */
   var doSearch = function(query, callback) {
     var searchId = ++currSearchId;
-    chrome.sync.findNodesContainingString(query, function(ids) {
-      if (currSearchId != searchId) {
-        return;
-      }
-      chrome.sync.getNodeSummariesById(ids, function(nodeSummaries) {
-        if (currSearchId != searchId) {
-          return;
-        }
-        callback(nodeSummaries);
-      });
+    chrome.sync.getAllNodes(query, function(allNodes) {
+      var regex = new RegExp(query);
+      callback(allNodes.filter(function (elem) {
+        return JSON.stringify(elem).match(regex);

[rlarocque, 2012/03/27 01:49:05]

I believe JSON.stringify returns a "compact" version of the node.  This affects
how users should be writing queries in non-obvious ways (ie. how much whitespace
to expect).  

It's easy enough to work around this issue by specifying lots of wildcards in
the regex, but it's still likely to confuse people.

[akalin, 2012/03/29 18:41:43]

Does searching the raw json provide us any benefit?  What about writing a
Javascript function that recurses through the hash/array structure and tests the
regexp with the keys, string values, int values, etc.?  That would avoid the
confusion.

[rlarocque, 2012/03/29 20:51:32]

Searching the serialized version makes it easy to implement some very powerful
hacks.  For example:

"ID":\s*"sZ\S*,.*"IS_DIR":\s*true,.*"IS_DEL":\s*true,.*"IS_UNSYNCED":\s*true

That example is not tested and probably not 100% correct, but that's the general
idea.  In theory, it should search for Zipit items (the "ID" starts with "sZ")
which are unsynced, locally deleted, and directories.

Full text search gives us the ability to search for any combination of
attributes with very little effort (to implement, that is).  

Less hack-ish solutions are certainly possible, but they would likely require us
to define our own query language and write functions to parse and implement
those queries.  This language would have its own learning curve, probably almost
as bad as the one for these strange regexes.  To me, that doesn't seem worth it,
but that may be because I haven't put much thought into what such a query
language might look like.  Suggestions welcome.  

If nothing else, using regexes for now gets us a useful starting point that we
can use to gather information about what a proper solution should look like.

+      }));
     });
   };
 
   /**
    * Decorates the various search controls.
    *
    * @param {!HTMLInputElement} queryControl The <input> object of
    *     type=search where the user types in his query.
    * @param {!HTMLElement} statusControl The <span> object display the
    *     search status.
@@ skipping 16 matching lines @@
       }
       statusControl.textContent = 'Searching for ' + query + '...';
       var timer = chrome.sync.makeTimer();
       doSearch(query, function(nodeSummaries) {
         statusControl.textContent =
           'Found ' + nodeSummaries.length + ' nodes in '
           + timer.elapsedSeconds + 's';
         // TODO(akalin): Write a nicer list display.
         for (var i = 0; i < nodeSummaries.length; ++i) {
           nodeSummaries[i].toString = function() {
-            return this.title;
+            return this.NON_UNIQUE_NAME;

[akalin, 2012/03/29 18:41:43]

any reason you changed this?  is the NON_UNIQUE_NAME more readable?

[rlarocque, 2012/03/29 20:51:32]

Less readable, actually.  It's a long story.  

The old search function used getNodeSummariesById() to fetch nodes.  This
returned an array of sync_api::BaseNode::GetNodeSummaryAsValue() results.  The
GetNodeSummaryAsValue() function returns as dictionary with four entries, one of
which is the title, which is derrived from sync_api::BaseNode::GetTitle().

AFAIK, it's impossible to get a list of nodes from the sync_api layer.  To get a
full list, you need to get it from the syncable layer.  At that layer, you can't
get the "summary" of a node.  Instead you can convert the entire node into a
DictionaryValue.  This does not include anything equivalent to the "title" found
in the summary.

I changed this value because the "title" field is not among the attributes
returned by the getAllNodes() function.  I'm not sure yet how or if I intend to
fix this.

[rlarocque, 2012/03/30 21:52:30]

I talked to Nicolas about this.  It turns out that all encrypted nodes have a
non-informative NON_UNIQUE_NAME.  Bookmarks are special in that they store their
title in their specifics, so we can grab a title even from an encrypted bookmark
node.  That's the one case where GetTitle() returns more useful information than
NON_UNIQUE_NAME.

So we're not losing too much by using NON_UNIQUE_NAME instead of the "title"
field generated by GetTitle().  This is a regression I'm willing to tolerate. 
We can revisit this decision later if we decide it's a problem.

           }.bind(nodeSummaries[i]);
         }
         resultsDataModel.push.apply(resultsDataModel, nodeSummaries);
         // Workaround for http://crbug.com/83452 .
         resultsControl.redraw();
       });
     };
     queryControl.value = '';
 
     // Decorate results list.
     cr.ui.List.decorate(resultsControl);
     resultsControl.dataModel = resultsDataModel;
     resultsControl.selectionModel.addEventListener('change', function(event) {
       detailsControl.textContent = '';
       var selected = resultsControl.selectedItem;
       if (selected) {
-        chrome.sync.getNodeDetailsById([selected.id], function(nodeDetails) {
+        chrome.sync.getNodeDetailsById([selected.META_HANDLE],

[akalin, 2012/03/29 18:41:43]

hunh.  is id == META_HANDLE?  any reason you changed this?

[rlarocque, 2012/03/29 20:51:32]

Same as above, but id == META_HANDLE (as opposed to the approximate equality of
NON_UNIQUE_NAME and title).

+                                       function(nodeDetails) {
           var selectedNodeDetails = nodeDetails[0] || null;
           if (selectedNodeDetails) {
             detailsControl.textContent =
               JSON.stringify(selectedNodeDetails, null, 2);
           }
         });
       }
     });
   }
 
   return {
     decorateSearchControls: decorateSearchControls
   };
 });