When manually opened, the New Tab Page should be ready for quick search

[brampitoyo]

Current

When the New Tab Page is opened from the tab tray, the address bar is not selected, and the keyboard does not come up.

Additionally, when the address bar is selected, the toolbar always “jumps” to the top of the screen, no matter where your toolbar has been positioned in Settings.

Proposal

When manually opened, the New Tab Page should be ready for quick search. And “the rest of the New Tab Page” should look more selectable.

When the New Tab Page is opened from the tab tray, select the address bar automatically and pop up the keyboard so that people can instantly start a new search.

The position of the toolbar now depends on whether it’s set to bottom or top:

• Toolbar on bottom: it “jumps halfway” above the keyboard. This will go a long way towards smoothing out abrupt motion.
• Toolbar on top: same as current behaviour. When selected, it should still stay where it is, on top of the screen.

The rest of the content on the New Tab Page – like Top sites – should be selectable. The area above the keyboard shouldn’t be covered by a scrim.

Tab tray	New Tab Page with keyboard up

┆Issue is synchronized with this Jira Task

[s-ankur]

@brampitoyo one question: should the long press on tab count -> new tab shortcut also have this behavior?

[brampitoyo]

@s-ankur Yes. We should consider long-pressing on the tab count icon as identical to tapping the “+” button. It should still pop the keyboard open.

[XxAcielxX]

I also agree here, when you open a new tab the input field & keyboard should get auto focus so can start typing right away.

[Cheap-Skate]

This would be fantastic.

And if every time I tapped the URL bar (even if I didn't open a new tab) I saw exactly the same (Top Sites, Scan, Shortcuts, text input field, keyboard) it would be utterly fantastic.

[dglttr]

The mockup of the New Tab Page with keyboard up in comment 0 has a lot of elements which could make it more difficult for users to understand and navigate correctly.
So, inspired by #12619, I thought that it might be possible to remove the button pointing to search engines (because that functionality would then already be available by clicking the search engine icon/arrow, which I find much more intuitive anyway). In addition, if one moves the "Scan" button to the address bar, the bar containing the buttons could be removed entirely, leaving more space for the information that the users wants to see.

Quick mock-up of what I mean:

For the purpose of the mock-up, I left the additional space empty, but one could probably see the available Collections, more top sites or other things in the future (see #12941, for example).

As for the lost visibility of the "Scan" button:

1. I don't think that it is very frequently used, I believe most users use their built-in camera or dedicated QR scanner app to scan the QR code and then follow the link in-app. Especially because it isn't always clear that there is a URL behind a QR code (it might be contact information or countless other things instead).
2. As was shown in Make buttons for "Mic/voice" and "x" icon dynamically appear/disappear #12657 (comment), apps like WhatsApp place two icons in their text boxes, so users have a fair degree of familiarity with this.

In total, I think this could result in way more space available to the user and less cognitive overload from menu elements, while keeping feature discoverability intact.

[dglttr]

Seeing the two microphone buttons directly below each other leads me to thinking that the extra microphone icon could maybe be disabled if a keyboard supporting voice input is detected. Though that's probably for a different issue.

[Cheap-Skate]

@amkcpu

I really like this. Space efficient, logical. The Google logo with up caret will be familar to Samsung Internet users at least. Much better than the current solution- I think using a whole screen row just for Scan & Search Engines is very wasteful.

The blank space might get filled up with Pocket suggestions or "News from Mozilla" like on Firefox Desktop. Or, as you say, more Top Sites.

[andreicristianpetcu]

Will we have multi line recommandations like FF Lite?

[brampitoyo]

@Cheap-Skate Thanks for pointing out the text displacement problem. We’re aware of this, and will address it.

@opusforlife2 Yes – I meant to say that the toolbar on top should stay exactly where it is. Let me fix the wording. Thanks!

[ghost]

@brampitoyo I think in the new search experience, search suggestions should go from bottom to top because when I'm typing into the address bar looking down and if the search suggestions end up at the top of the display this will feel very disconnected as the user has to scan through from the top to bottom and the user will have to stop typing and look at the suggestions at the top of the screen and then come back again to continue typing in the address bar, this takes a lot of visual effort I think and it also doesn't match with user intuitions.

When the address bar is at the top:

The user is looking at the top and scanning through suggestions by looking downwards in a top to bottom fashion and if the first search suggestion matches then the user clicks on it to make a search.

When the address bar is at the bottom:

The user types something into the address bar and the user is looking at the bottom and scanning through the search suggestions in a direction of bottom to top fashion so the user types something and gets a suggestion and if the first suggestion matches up then the user click it and makes a search.

But if the search suggestion appear at the top then I think the user would get puzzled which is the search engine suggestion and which is the typed word. In my opinion the search suggestions should be just above the address bar as the user is looking at it in that moment, not at the top where the user isn't looking.

I'd have filed an issue for this but I thought I'd get some thoughts from you before that.

Edit: Filed an issue #14017.

[klint]

Hi. The New Search Experience is still not activated in the 2 following cases. Shall I open separate tickets? :)

• when creating a new tab by clicking on the search widget (but maybe that is on purpose, actually?)

• when creating a new tab by long pressing on the tab count in a specific scenario : click on the app icon in the launcher (whether it was in the background or not running at all does not matter), long press on the tab count once the app is opened, then choose to open a new tab (either private or not): new tab page opens but the keyboard is not displayed, which is not what was expected.

[vesta0]

@klint we looked into those 2 cases and agree that the new search experience should be extended to those - thanks for raising them!

[ebalazs-sv]

Verified as fixed on Nightly 200827 07:01 (Build #2015760377) GV 81.0a1 from 8/27 with the following devices:

• Google Pixel 2 (Android 9);
• Samsung Galaxy Tab S3 (Android 8);
• Nexus 5 (Android 6.0.1).

New related issues:
#14280;
#14282;
#14283;
#14288

I will remove the qa:needed label and close this issue.

[hwinnemoe]

Additional related issues:
#14279
#14321
#14246

[liuche]

@boek it looks like these are the new issues that have been filed by QA after testing the search feature - could you pull any of them that need to be fixed into the current sprint? or close ones that are working as expected.

[OUTDOOOR]

Hello, could you please add option in the settings to disable or enable behaviour of the keyboard when is New Tab opened? For example I mostly use Top Sites and automatically opened keyboard is annoying. Now I have to tap on the icon with bookmark twice - first tap - keyboard disappear, second tap opens bookmark.
Behaviour with automatic keyboard with New Tab.zip

[rusegithub]

And if every time I tapped the URL bar (even if I didn't open a new tab) I saw exactly the same (Top Sites, Scan, Shortcuts, text input field, keyboard) it would be utterly fantastic.

Yes it would.

[brampitoyo]

@OUTDOOOR We hear you. When the keyboard is up, we still want Top Sites to be selectable without an extra tap.

We will solve this problem when we fix #14288. Stay tuned.