extensions: tabs: set tab id to -1 for app/devtools windows

chrome/browser/extensions/api/sessions/sessions_apitest.cc

Index: chrome/browser/extensions/api/sessions/sessions_apitest.cc
diff --git a/chrome/browser/extensions/api/sessions/sessions_apitest.cc b/chrome/browser/extensions/api/sessions/sessions_apitest.cc
index 90ebba80a6259eb86377a3700d4270ba8aed71a8..ba487455b78530223e3356781fc1d9d124d5aa3e 100644
--- a/chrome/browser/extensions/api/sessions/sessions_apitest.cc
+++ b/chrome/browser/extensions/api/sessions/sessions_apitest.cc
@@ -253,7 +253,8 @@ testing::AssertionResult CheckSessionModels(const base::ListValue& devices,
     for (size_t j = 0; j < tabs->GetSize(); ++j) {
       const base::DictionaryValue* tab = NULL;
       EXPECT_TRUE(tabs->GetDictionary(j, &tab));
-      EXPECT_FALSE(tab->HasKey("id"));  // sessions API does not give tab IDs
+      EXPECT_EQ(api_test_utils::GetInteger(tab, "id"),
+                -1);  // sessions API does not give tab IDs

[not at google - send to devlin, 2015/07/16 17:09:23]

I'd like to keep using the lack of a tab ID as meaning it's a session API.
Pragmatically, we shouldn't be changing APIs. Philosophically, we could say that
-1 means "there is no tab ID" whereas the lack of a tab ID means "there is a tab
ID, but we don't know it". Not that interesting a distinction to make, but
that's where we are.

[llandwerlin-old, 2015/07/17 11:32:04]

Done.

       EXPECT_EQ(static_cast<int>(j), api_test_utils::GetInteger(tab, "index"));
       EXPECT_EQ(0, api_test_utils::GetInteger(tab, "windowId"));
       // Test setup code always sets tab 0 to selected (which means active in