Factor parsing "ln=" to SuggestionAnswer

components/omnibox/browser/suggestion_answer_unittest.cc

Index: components/omnibox/browser/suggestion_answer_unittest.cc
diff --git a/components/omnibox/browser/suggestion_answer_unittest.cc b/components/omnibox/browser/suggestion_answer_unittest.cc
index a75e41238096797dfb1ab0ee77de58cd31b97dfb..b849d3b7d4daf3bc9b450f568fe6043cbcce5ee3 100644
--- a/components/omnibox/browser/suggestion_answer_unittest.cc
+++ b/components/omnibox/browser/suggestion_answer_unittest.cc
@@ -199,10 +199,10 @@ TEST(SuggestionAnswerTest, URLPresent) {
 TEST(SuggestionAnswerTest, ValidPropertyValues) {
   std::string json =
       "{ \"l\": ["
-      "  { \"il\": { \"t\": [{ \"t\": \"text\", \"tt\": 8, \"ln\": 3 }, "
+      "  { \"il\": { \"t\": [{ \"t\": \"text\", \"tt\": 8 }, "
       "                      { \"t\": \"moar text\", \"tt\": 0 }], "
       "              \"i\": { \"d\": \"//example.com/foo.jpg\" } } }, "
-      "  { \"il\": { \"t\": [{ \"t\": \"other text\", \"tt\": 5 }], "
+      "  { \"il\": { \"t\": [{ \"t\": \"other text\", \"tt\": 5, \"ln\": 3 }], "
       "              \"at\": { \"t\": \"slatfatf\", \"tt\": 42 }, "
       "              \"st\": { \"t\": \"oh hi, Mark\", \"tt\": 729347 } } } "
       "] }";
@@ -215,8 +215,6 @@ TEST(SuggestionAnswerTest, ValidPropertyValues) {
   EXPECT_EQ(2U, first_line.text_fields().size());
   EXPECT_EQ(base::UTF8ToUTF16("text"), first_line.text_fields()[0].text());
   EXPECT_EQ(8, first_line.text_fields()[0].type());
-  EXPECT_TRUE(first_line.text_fields()[0].has_num_lines());

[groby-ooo-7-16, 2016/06/23 20:49:27]

Why did this check move from the first to the second line? 

Does the protocol spec actually say that ln can show up anywhere, but affects
only the second line? (In which case we should fix the spec)

[Kevin Bailey, 2016/06/23 21:49:23]

Since ParseTextField is looking for it, we can handle it in any text field,
including 'additional text' and 'status text'. Thus, I had no qualms about
testing for it in the first line. But practically, it will only be in the answer
of a multiline answer.

They only specified it in a reply to jdonnely@. (He asked, how are we supposed
to know that an answer is a dictionary definition and that we're supposed to
allow it go beyond one line, and they said, it will have a "ln" field.) Here is
the example that they give in the document:

[
  {"il":
    {"at":
      {"t": "\u2022 /KHsEMSHIYKLlizIYm/",
       "tt": 8},
     "t": [
      {"t": "definition of socialism",
       "tt": 8}]}},
  {"il":
    {"t":
      [
       {"t": "a political and economic theory ..."
        "tt": 8,
        "ln": 3}]}}]},

Moving it to the second line also makes it more clear to a reader where to
expect it.

-  EXPECT_EQ(3, first_line.text_fields()[0].num_lines());
   EXPECT_EQ(base::UTF8ToUTF16("moar text"), first_line.text_fields()[1].text());
   EXPECT_EQ(0, first_line.text_fields()[1].type());
   EXPECT_FALSE(first_line.text_fields()[1].has_num_lines());
@@ -232,6 +230,9 @@ TEST(SuggestionAnswerTest, ValidPropertyValues) {
   EXPECT_EQ(
       base::UTF8ToUTF16("other text"), second_line.text_fields()[0].text());
   EXPECT_EQ(5, second_line.text_fields()[0].type());
+  EXPECT_TRUE(second_line.text_fields()[0].has_num_lines());
+  EXPECT_EQ(3, second_line.text_fields()[0].num_lines());
+  EXPECT_EQ(3, answer->SecondLineSize());
 
   EXPECT_TRUE(second_line.additional_text());
   EXPECT_EQ(