I'm not sure who's closest to this, so over to Bernhard for assignment.

Does this only happen with the NTP, or with any web page? Also, +aberent, who worked on making the omnibox usable before the browser has fully started :)

For other web pages it seems okay. There are minor glitches but the use case does not seem as important as for NTP.

When I open chrome with another web page (e.g. by tapping a link in Inbox):
 - chrome opens with an empty address bar which I can tap,
 - the address bar gets focus, the rest of the screen turns gray,
 - after a short delay, the keyboard appears
 - after another short delay, the URL I opened chrome with appears in the address bar and the keyboard disappears again, the page starts to load.

From talking to dgn@, who has worked on the NTP recently, there is currently no code to transition input from the fake omnibox to the NTP. I am not sure why the keyboard isn't appearing, but as the code is at the moment it may be a good thing that it isn't, since any input the user typed early would be lost when the NTP appeared.

Since the NTP is implemented in Java with Android layouts one possibility is that loading the NTP layouts (which, I believe, has to happen on the UI thread) is blocking the UI thread and hence preventing the keyboard appearing.

One thought; if the user starts typing in the fake omnibox should we abandon loading the NTP and simply try process whatever they type?

+dgn@
+peconn@ at dgn@'s suggestion.

I just tried to repro and, we get to the real omnibox by tapping early, so fakebox to omnibox transitioning is irrelevant here. 

However, I noticed that the NTP is completely unaware that we are already focusing the omnibox when it loads. It still displays the fakebox and does not scroll where it should. IIRC the code only updates that on scroll events and the omnibox is not supposed to be tappable, so we didn't handle it. Or removed that code at some point.

Second thing, the keyboard still comes up before the NTP is fully loaded, and from my attempts it seems to behave exactly like regular web pages. So I suppose a fix to make the keyboard appear earlier would not be specific to the NTP.

Deleted: Screenshot_2016-06-06-10-58-23.png 99 KB

	Screenshot_2016-06-06-10-58-23.png 99 KB View Download

I did not mention: the delay is noticeable only when really starting chrome, when it is not running.

I've tested it once again. 
In many trials (always force stopping chrome in between), the keyboard often appears clearly before the NTP renders. Several times I even managed to type a few letters before NTP rendered - my input was never lost afterwards.

Weird, I did test it many times last week and I would bet this never happened. In the meantime I encrypted my phone, adding my corp account on it. Maybe loading NTP just got slower due to the encryption and the keyboard sometimes clearly wins, now.


Anyway, I would love to be able to type in the address bar much sooner. I think that tapping the address bar before NTP opens is a clear indication that I am not much interested in the NTP. 

If abandoning loading NTP in this situation would be somewhat easy to implement, I think it would be lovely. The loading of NTP would be restarted only after the user hits the [back/hide keyboard] button. Another option is to prioritize the input/keyboard somehow, if this is even possible.

Whenever I suffer from slowness on my phone, I feel super sorry for all the millions of users who have even way cheaper phones :)

I agree, Pam. The question is more general: 

What to do if the user tries to type into the address bar while a page is loading? (as loading of the page might really slow down the ui for typing)

It is just my feeling that for NTP, people might try this way more often than for any other page.

Reading dgn@'s comment we need to be careful with terminology here; there are two fake omniboxes here:
1 - The fake omnibox created by the Java startup code at the top of the page. This allows the user to start typing a URL or search string before the Chrome native library is fully loaded and started.
2 - The fake omnibox in the NTP. This is graphical element that allows the user to get back the real omnibox (which the NTP covers).

Both these are distinct from the real omnibox that is created and visible once Chrome is properly started and a web page is displayed.

Re #7, we already try to avoid doing any expensive operation on the UI thread. It could just be overall CPU contention, in which case this would fall more into the bigger (startup) performance context.

Bulk edit: Moving back into the untriaged pool, as I'm leaving the project.