Strip special characters in extension omnibox suggestions.

chrome/browser/ui/cocoa/omnibox/omnibox_popup_view_mac.mm

Index: chrome/browser/ui/cocoa/omnibox/omnibox_popup_view_mac.mm
===================================================================
--- chrome/browser/ui/cocoa/omnibox/omnibox_popup_view_mac.mm	(revision 106488)
+++ chrome/browser/ui/cocoa/omnibox/omnibox_popup_view_mac.mm	(working copy)
@@ -103,12 +103,16 @@
 // and description cases.  Returns NSMutableAttributedString as a
 // convenience for MatchText().
 NSMutableAttributedString* OmniboxPopupViewMac::DecorateMatchedString(
-    const string16 &matchString,
+    const string16& matchStringIn,
     const AutocompleteMatch::ACMatchClassifications &classifications,
     NSColor* textColor, NSColor* dimTextColor, gfx::Font& font) {
   // Cache for on-demand computation of the bold version of |font|.
   NSFont* boldFont = nil;
 
+  string16 matchString;
+  const char16 kNewlineChar[] = { '\n', '\0' };
+  RemoveChars(matchStringIn, kNewlineChar, &matchString);

[Scott Hess - ex-Googler, 2011/10/20 19:54:03]

Should this remove the newline, or convert it to a space?  What about tabs? 
Linefeeds?  Random other control characters?

As a more general question, it seems like this should be solvable at the point
where the offending match contents are generated, rather than where they are
used.  Unfortunately, AutocompleteMatch is a struct where callers set contents
directly.  Since this problem is one where someone else controls what we
display, ExtensionAppProvider::Start() might be the chokepoint you want.  Are
newlines legitimate contents of matches in general?

+
   // Start out with a string using the default style info.
   NSString* s = base::SysUTF16ToNSString(matchString);
   NSDictionary* attributes = [NSDictionary dictionaryWithObjectsAndKeys: