WAI. GetVisibleItem is the item that should be shown in the omnibox and it is either LastComittedEntry (URL of the page) or PendingEntry if request was initiated by the user from the omnibox.

If I understand correctly this bug asks to always return pending entry, which would lead to security vulnerabilities (f.e. evil.com would be able to spoof omnibox URL and present bank.com by simply requesting a navigation).

If you believe that there is a bug in navigation system, please provide a test page and steps to reproduce.

The question is:
If you do

1. Navigate to foo.com
2. Navigate to bar.com
3. Press back
4. In the didStartLoading, GetVisibleItem returns the bar.com entry.

In that case, in the omnibox, the foo.com should be displayed, right?
Shouldn't press back/forward be interpreted as user intention?

If we've received the didStartLoading WSO callback, doesn't that mean that the pending navigation is committed? It looks like we're calling CRWSessionController's |-commitPendingEntry| before that callback is called; is it a bug that the pending/lastCommitted entry indices aren't updated before this callback?

didStartLoading callback does not mean that navigation has committed and changing visible item before navigation is committed would lead to various security vulnerabilities. Answering question from comment #3: after tapping back omnibox should keep showing bar.com and change to foo.com only when server start responding with data.

What's interesting is that Chrome for iOS used to behave according to Olivier's expectations and back navigation immediately changed last committed item. We changing that for M46 and you can find more details in this doc: https://docs.google.com/document/d/1GvsaoNtMO7d87FzoysOW5GqH6XErI5g2cinKhkPk7bQ/edit

Also you can take a look at visible_url_egtest.mm tests cases which demonstrate how omnibox should behave during back forward navigation. Please let me know if you have further questions.