Tested the issue in Android and could not reproduce the issue. 

teps Followed:
1. Launched Chrome Browser.
2. Navigated to https://blog.chromium.org
3. Observed Chrome NTP/Chrome Home after step 3 and step 5 

Chrome versions tested:
62.0.3202.84

OS
Android 7.0.0

Android Devices
7.0.0 SM-J710F Build/NRD90M

@loorongjie: Could you please help us with the OS & details of your device and attach a screencast as well.

Thanks!!

@sandeepkumars, you misread my report, Chrome 62.0.3202.84 is working as expected, Chrome Dev 64.0.3261.0 is not working as expected.

Thank you for providing more feedback. Adding requester "sandeepkumars@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Screencast for Chrome Dev 64

Deleted: 2017_11_10_13_41_40.mp4 13.0 MB

	2017_11_10_13_41_40.mp4 13.0 MB View Download

Able to reproduce the issue as per the steps mentioned in comment #2.

Chrome versions tested:
64.0.3261.0

OS
Android 7.0.0

Android Devices
7.0.0 SM-J710F Build/NRD90M

Below is the bisect info
=======================
Chrome Good Build -- 63.0.3237.11
Chrome Bad Build  -- 63.0.3238.0

https://chromium.googlesource.com/chromium/src/+log/63.0.3237.0..63.0.3238.0?pretty=fuller&n=10000

Unable to provide the per-revision bisect as all good builds are getting invoked.

Requesting someone from dev team, please take a look at this issue and help us in assigning the issue to appropriate owner.

Adding Release Block Stable as this is a recent regression broken in M63.

Please navigate to below link for log's and video--
go/chrome-androidlogs/783142

Note: This issue is not observed in Desktop.

Thanks!!

May be this patch is the suspect, seeing some change in NewTabPageView.java - 

https://chromium.googlesource.com/chromium/src/+/c9aa58c60c6ad870e9c8d2718975d501347a4902

Assigning to Bernhard for confirming.

+Kingston, Matt

So, there isn't actually a New Tab Page per se anymore in Chrome Home. What you get when opening a new tab e.g. from the overflow menu is the bottom sheet shown over the tab switcher (I think fully expanded). When you navigate back we also show the bottom sheet, but in the half-opened state, which might be what you observed, so I think this is working as intended, but I'll pass to Kingston for triaging the feedback.

I have been experimenting with Chrome Home and following several public tracking bugs, so I know this is indeed "working as intended" based on the design. My report is to show that this design decision breaks a common workflow.

If a user go to website A > website B > website C > [Return] to website B > [Return] to website A (*) > [Return] and see overflow menu > [Return] to close Chrome > [Open Chrome] and see website A > website D > [Return] to A (*) > [Return] and see overflow menu > [Return] to close Chrome > [Open Chrome] and see A.

Website A persists when user opens Chrome. Workaround is after (*), explicitly close website A tab in tab manager instead of tapping [Return]. However, that is more taps than it used to be before Chrome Home and I always forgot to do this instead of keep tapping [Return] (old habits die hard).

Thanks for the feedback, that is very helpful!

Got it thanks -that's good to know. We're working on better back button behavior so we can take this into account as we proceed with it.

We are looking into potential solutions here though removing RBS since it's not a blocking bug.

We are ending the current Chrome Home experiment and closing the corresponding Chrome Home bugs. Thanks for the feedback and support!

Chrome Home with bottom URL bar and bottom download/history/bookmarks buttons is FAR superior to Chrome Duplex. Huge regression. 

Chrome Home was the only way for one handed people to use Chrome on a smartphone. UX has become incredibly bad (again) by removing it.
Sad you don't care about disabled people or good user experience.