The problem is in the following snippet from -[OmniboxTextFieldIOS updateTextDirection]:
NSTextAlignment alignment = [self bestTextAlignment];
[self setTextAlignment:alignment];
UITextWritingDirection writingDirection =
alignment == NSTextAlignmentLeft ? UITextWritingDirectionLeftToRight
: UITextWritingDirectionRightToLeft;
[self
setBaseWritingDirection:writingDirection
forRange:[self
textRangeFromPosition:[self
beginningOfDocument]
toPosition:[self endOfDocument]]];
When this code was originally written, |bestTextAlignment| could only return Left or Right. A subsequent change allowed it to return Natural when the text field was not first responder. As a result, |writingDirection| is initialized to RTL when the field is not focused.
This code has been broken in production for a while now, but the effects were hidden because (presumably) baseWritingDirection had no practical meaning when the field was not first responder.
In iOS11, it appears that setting the baseWritingDirection to RTL also changes the textAlignment to Right. This is what is forcing the field to be right-aligned.
For M60, I'd prefer to add a fix that's behind IsRunningOnIOS11OrLater(), to prevent behavioral changes for existing users.
Longer-term, Justin wants to update this code to set the baseWritingDirection to Natural (which wasn't supported before but is supported now). Or maybe we can determine that this code is no longer useful and can be removed entirely.
For posterity, the history of this bug is a combination of an iOS specific workaround coupled with a bad refactor.
For iOS6/7, we added alignment code that forced baseWritingDirection to left or right, because Natural didn't exist and setting alignment did not always work correctly (what was broken is lost to history, it seems)
It seems that sometime around iOS8/9 alignment started working properly for these edge cases, and baseWritingDirection was ignored/overridden by alignment.
Sometime last year, a refactor introduced a hidden bug where baseWritingDirection was set to RTL all the time. But this was ignored since alignment was set correctly.
The new bug is that in iOS11 baseWritingDirection also sets alignment. So the alignment is set correctly, then baseWritingDirection is set incorrectly, which then sets alignment to RTL. Bug.
During the bad refactor, we also introduced a security measure that correctly sets baseWritingDirection somewhere else when in non-editing mode.
Since alignment seems to work, and we already set baseWritingDirection elsewhere, I recommend we simply remove this code. Adding a change for M60 to wrap a removal for iOS11 only, then remove for everyone in M61.
, the bug is caused by some code added in iOS6/7 to fix alignment issues
This bug requires manual review: M60 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!
If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.
Thanks for your time! To disable nags, add the Disable-Nags label.
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible!
If all merges have been completed, please remove any remaining Merge-Approved labels from this issue.
Thanks for your time! To disable nags, add the Disable-Nags label.
For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Comment 1 by jif@chromium.org
, Jun 7 2017