Use the result view font list for the base answers font.

chrome/browser/ui/views/omnibox/omnibox_result_view.cc

Index: chrome/browser/ui/views/omnibox/omnibox_result_view.cc
diff --git a/chrome/browser/ui/views/omnibox/omnibox_result_view.cc b/chrome/browser/ui/views/omnibox/omnibox_result_view.cc
index 6d29e0a88eb076eed56a869c07f408f5eeb59282..ba5cfda702b82b159db5cb71a5e5d17ba23ae54f 100644
--- a/chrome/browser/ui/views/omnibox/omnibox_result_view.cc
+++ b/chrome/browser/ui/views/omnibox/omnibox_result_view.cc
@@ -739,6 +739,12 @@ const gfx::FontList& OmniboxResultView::GetAnswerFont() const {
       match_.answer && !match_.answer->second_line().text_fields().empty()
           ? match_.answer->second_line().text_fields()[0].type()
           : SuggestionAnswer::SUGGESTION;
+
+  // When BaseFont is specified, reuse font_list_, which may have had size
+  // adjustments from BaseFont before it was provided to this class.

[Peter Kasting, 2017/06/15 22:50:28]

Hmm.  It seems like if the font passed in has been adjusted, we'd really want
the adjustments to apply to non-base fonts too, thus preserving the relative
differences between them.  This basically preserves the adjustment for BaseFont,
but leaves the other cases untouched.  It seems like maybe all font cases in
this function should be derived off |font_list_|, instead of ever using the
resource bundle fonts directly?

[Justin Donnelly, 2017/06/16 14:28:23]

Yeah, it feels like that's the right thing to do. But I think it's a solution in
search of a problem. The current fonts work well. Presumably
ui::ResourceBundle::LargeFont is designed in a way that it produces an
appropriately sized large font for the current platform and settings, whereas
BaseFont is being manipulated to specifically match the size of the omnibox
field.

[Peter Kasting, 2017/06/16 23:47:21]

Hrm, I would worry about this, especially for users with really large fonts.  I
suspect this is kinda broken today for those users.

I'm not going to block you landing this, since it seems like a win over where we
are today, but I would take the time to look into this a little more deeply.  I
think some combination of Derive calls would do what you want.  You could ping
tapted@ for help, he's looked at a lot of typography stuff lately.

[Justin Donnelly, 2017/06/21 21:13:49]

I'm interested in how answers look with different font size settings and I tried
doing so earlier. But the only setting in Windows that seems to exist ("Make
text and other items larger or smaller") scales both the font and the UI (both
Win 7 and Win 10). FWIW the result of adjusting that setting works well:
https://screenshot.googleplex.com/5PeDxRXONhe.png

Off the top of your head do you know of some other thing I can try to make the
font larger?

[Peter Kasting, 2017/06/21 21:20:23]

On Win 7, try Control Panel > Appearance and Personalization > Personalization,
click the "Window color" at the very bottom, click "Advanced appearance
settings", change "Item" to "Message box", adjust the font size, apply, and
restart Chrome. 

[Justin Donnelly, 2017/06/21 21:32:07]

Thanks! It's so obvious, why didn't I think of that? :P

Ok, here's the result of maxing out the text size:
https://screenshot.googleplex.com/dS4RFPJ69P1.png

It looks to me like, insofar as the design calls for this to be large text, that
the answer is doing the right thing. If anything's broken, I'd suggest it's the
tabs and the omnibox which aren't growing to accommodate the user's desired font
size.

+  if (GetTextStyle(text_type).font == ui::ResourceBundle::BaseFont)

[Peter Kasting, 2017/06/15 22:50:28]

Nit: Use a temp for this subexpression that's repeated below?

[Justin Donnelly, 2017/06/16 14:28:23]

Done.

+    return font_list_;
+
   return ui::ResourceBundle::GetSharedInstance().GetFontList(
       GetTextStyle(text_type).font);
 }