summaryrefslogtreecommitdiffstats
path: root/chrome/test/chrome_process_util_mac.cc
diff options
context:
space:
mode:
authoravi@google.com <avi@google.com@0039d316-1c4b-4281-b951-d872f2087c98>2009-04-23 18:07:51 +0000
committeravi@google.com <avi@google.com@0039d316-1c4b-4281-b951-d872f2087c98>2009-04-23 18:07:51 +0000
commit075a7253bc09178cb94e44b4ae08f5ad1d00f07a (patch)
tree3102e07f44a1361d31d41ce15b28c0cb56efa290 /chrome/test/chrome_process_util_mac.cc
parentd61653713c71eeff68b379e60a0e44545921994c (diff)
downloadchromium_src-075a7253bc09178cb94e44b4ae08f5ad1d00f07a.zip
chromium_src-075a7253bc09178cb94e44b4ae08f5ad1d00f07a.tar.gz
chromium_src-075a7253bc09178cb94e44b4ae08f5ad1d00f07a.tar.bz2
Create a ChromeProcessUtil for the Mac, and enable it in the tests.
Review URL: http://codereview.chromium.org/95009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14328 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'chrome/test/chrome_process_util_mac.cc')
-rw-r--r--chrome/test/chrome_process_util_mac.cc49
1 files changed, 47 insertions, 2 deletions
diff --git a/chrome/test/chrome_process_util_mac.cc b/chrome/test/chrome_process_util_mac.cc
index 4d252ba..fa587b9 100644
--- a/chrome/test/chrome_process_util_mac.cc
+++ b/chrome/test/chrome_process_util_mac.cc
@@ -4,9 +4,54 @@
#include "chrome/test/chrome_process_util.h"
-#include "base/logging.h"
+#include <string>
+#include <vector>
+
+#include "base/command_line.h"
+#include "base/process_util.h"
+#include "base/string_util.h"
+
+// Yes, this is impossibly lame. This horrible hack is Good Enough, though,
+// because it's not used in production code, but just for testing.
+//
+// We could make this better by creating a system through which all instances of
+// Chromium can communicate. ProcessSingleton does that for Windows and Linux,
+// but the Mac doesn't implement it as its system services handle it. It's not
+// worth implementing just for this.
+//
+// We could do something similar to what Linux does, and use |fuser| to find a
+// file that the app ordinarily opens within the data dir. However, fuser is
+// broken on Leopard, and does not detect files that lsof shows are open.
+//
+// What's going on here is that during ui_tests, the Chromium application is
+// launched using the --user-data-dir command line option. By examining the
+// output of ps, we can find the appropriately-launched Chromium process. Note
+// that this _does_ work for paths with spaces. The command line that ps gives
+// is just the argv separated with spaces. There's no escaping spaces as a shell
+// would do, so a straight string comparison will work just fine.
+//
+// TODO(avi):see if there is a better way
base::ProcessId ChromeBrowserProcessId(const FilePath& data_dir) {
- NOTIMPLEMENTED();
+ std::vector<std::string> argv;
+ argv.push_back("ps");
+ argv.push_back("-xw");
+
+ std::string ps_output;
+ if (!base::GetAppOutput(CommandLine(argv), &ps_output))
+ return -1;
+
+ std::vector<std::string> lines;
+ SplitString(ps_output, '\n', &lines);
+
+ for (size_t i=0; i<lines.size(); ++i) {
+ const std::string& line = lines[i];
+ if (line.find(data_dir.value()) != std::string::npos &&
+ line.find("type=renderer") == std::string::npos) {
+ int pid = StringToInt(line); // pid is at beginning of line
+ return pid==0 ? -1 : pid;
+ }
+ }
+
return -1;
}