By the way, if you hit search afterwards, it will search for the string with the first word added (Lorem uma tincidunt egestas) instead of the string in the omnibox.

Hi Rohit, could you please take a look at this. 

Mighty weird.  Does this still reproduce?  If so, can you figure out the shortest paragraph on which it reproduces for you on?  (For example, if it reproduces on a six word input, then that's likely a problem for real users.  If it only reproduces for 30+ word paragraphs, then it's not likely a user gets into it.)

I bet this is somehow related to delete-by-word -- UITextField goes into that mode if you hold down delete for long enough.  I'd expect it to reproduce on longer-ish URLs as well.

It seems as though we're not getting the very last delegate callback, to tell us that the final word was deleted.  I'll see if I can catch this in the debugger.

Oddly enough, when iOS goes into delete-by-word mode, it calls textField:shouldChangeCharactersInRange:replacementString: once for every *two* calls to textFieldDidChange:.

We have code that attempts to detect programmatic calls to textFieldDidChange, by ensuring that every call to didChange is paired with a preceding call to shouldChange.

Delete-by-word breaks this assumption, so every second word deletion is discarded by the omnibox code as not being a user-initiated change.  If you have an even number of words, this means that the omnibox doesn't see the final deletion.  If you have an odd number of words, everything turns out ok in the end =)

I'll try to figure out why iOS behaves differently in delete-by-word mode.  The code that's trying to ensure shouldChange/didChange pairings is probably long obsolete (programmatic changes stopped triggering callbacks in iOS6), but will be harder to delete, because I'll need to make sure that doesn't accidentally break anything else.

Tested on latest Stable M60 build 60.0.3112.72 in iPhone6s(iOS 10).

Not able to reproduce the issue with the steps mentioned in Comment#0

Link to video: 
https://drive.google.com/a/google.com/file/d/0B8Cek8RsDbF8Z2d6OE9lY2tSUkE/view?usp=sharing

jasonkliu@ can you still reproduce this on 60?

For some reason, I can't download 60 stable manually though I should be able to. Will update when it's possible.

Yes, this still repros as of 61.0.3153.40 beta.

The shortest text I can use that repros is:
"Lorem Ipsum is simply dummy text of the"

If the word 'the' is omitted, this bug doesn't occur. I'm always putting the cursor before the 3rd to last word.

stk@ can you take a look at this?

First of all, I can still repro. 

I added a DCHECK in OnDidChange a few weeks ago (https://chromium-review.googlesource.com/c/chromium/src/+/1120816), and it seems like it didn't fail for anybody. However, I do hit it if I delete a lot of text, which seems to be exactly what is documented in comment 5. 

Therefore I think we should stop tracking processing_user_event flag at all, as we know the delegate callbacks are no longer called from setText:/setAttributedText:. 

I suspect we also don't need forwardingOnDidChange_ anymore, will add a DCHECK for that, too.