[ios] Workaround error affecting 3rd party keyboards and omnibox.

ios/chrome/browser/ui/omnibox/omnibox_text_field_ios.mm

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #import "ios/chrome/browser/ui/omnibox/omnibox_text_field_ios.h"
 
 #import <CoreText/CoreText.h>
 
 #include "base/command_line.h"
 #include "base/ios/ios_util.h"
 #include "base/logging.h"
 #include "base/mac/foundation_util.h"
 
 #include "base/strings/sys_string_conversions.h"
 #include "components/grit/components_scaled_resources.h"
 #include "components/omnibox/browser/autocomplete_input.h"
+#include "ios/chrome/browser/application_context.h"
 #include "ios/chrome/browser/autocomplete/autocomplete_scheme_classifier_impl.h"
+#include "ios/chrome/browser/experimental_flags.h"
 #import "ios/chrome/browser/ui/animation_util.h"
 #include "ios/chrome/browser/ui/omnibox/omnibox_util.h"
 #import "ios/chrome/browser/ui/reversed_animation.h"
 #include "ios/chrome/browser/ui/rtl_geometry.h"
 #include "ios/chrome/browser/ui/ui_util.h"
 #import "ios/chrome/browser/ui/uikit_ui_util.h"
 #import "ios/chrome/common/material_timing.h"
 #include "ios/chrome/grit/ios_strings.h"
 #include "ios/chrome/grit/ios_theme_resources.h"
 #include "skia/ext/skia_utils_ios.h"
@@ skipping 423 matching lines @@
     [autocompleteText
         addAttribute:NSBackgroundColorAttributeName
                value:[self selectedTextBackgroundColor]
                range:NSMakeRange([fieldText length], autocompleteLength)];
     [_selection setAttributedText:autocompleteText];
     [_selection setTextAlignment:[self bestTextAlignment]];
   } else {
     [self clearAutocompleteText];
   }
 
-  self.attributedText = fieldText;
+  // The following BOOL was introduced to workaround a UIKit bug
+  // (crbug.com/737589, rdar/32817402). The bug relates to third party keyboards
+  // that check the value of textDocumentProxy.documentContextBeforeInput to
+  // show keyboard suggestions. It appears that calling setAttributedText during
+  // an EditingChanged UIControlEvent somehow triggers this bug. The reason we
+  // update the attributed text here is to change the colors of the omnibox
+  // (such as host, protocol) when !self.editing, but also to hide real
+  // UITextField text under the _selection text when self.editing. Since we will
+  // correct the omnibox editing text color anytime |self.text| is different
+  // than |fieldText|, it seems it's OK to skip calling self.attributedText
+  // during the condition added below. If we change mobile omnibox to match
+  // desktop and also color the omnibox while self.editing, this workaround will
+  // no longer work.
+  BOOL updateText = YES;
+  // Before M61 branch point this should also go behind a Japanese flag, e.g.
+  // [self.textInputMode.primaryLanguage isEqualToString:@"ja-JP"] to be as
+  // restrictive as possible.
+  if (experimental_flags::IsThirdPartyKeyboardWorkaroundEnabled()) {
+    updateText =
+        (!self.editing || ![self.text isEqualToString:fieldText.string]);
+  }
+  if (updateText) {
+    self.attributedText = fieldText;
+  }
 
   // iOS changes the font to .LastResort when some unexpected unicode strings
   // are used (e.g. 𝗲𝗺𝗽𝗵𝗮𝘀𝗶𝘀).  Setting the NSFontAttributeName in the
   // attributed string to -systemFontOfSize fixes part of the problem, but the
   // baseline changes so text is out of alignment.
   [self setFont:_font];
   // TODO(justincohen): Find a better place to put this, and consolidate it with
   // the same call in omniboxViewIOS.
   [self updateTextDirection];
 }
@@ skipping 465 matching lines @@
   // Disable the RTL arrow menu item. The omnibox sets alignment based on the
   // text in the field, and should not be overridden.
   if ([NSStringFromSelector(action) hasPrefix:@"makeTextWritingDirection"]) {
     return NO;
   }
 
   return [super canPerformAction:action withSender:sender];
 }
 
 @end