Unable to reproduce the issue on chrome reported version# 68.0.3440.3 using Windows-10 with steps mentioned below:
1) Launched chrome reported version and navigated to chrome://settings and changed yahoo as default search engine
2) Opened New Tab Page, didn't observed any white area

@Reporter: Could you please try to test this issue by creating new person with no apps and extensions in it and let us know if the issue still persists.

Thanks!

The problem is easily reproducible in a new profile with any search engine that doesn't add its own content.
For example, add a new search engine with a name "123", keyword "123", URL "http://123/%s"

Bisected to 87cb6bc677f7665addec684361c25dfda1e22e3f "Revert changes in css files to hide rows of MV tiles."
Landed in 67.0.3369.0

Thanks. I created a new person, changing Yahoo as default search engine and the white area still persists.
And woxxom is right. Every search engine that does not create something in the new tab will produce such a problem.

Deleted: 1.png 164 KB

	1.png 164 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

 Issue 857246  has been merged into this issue.

Able to reproduce the issue on Windows 10, mac 10.13.3 and Ubuntu 17.10 using chrome reported version #68.0.3440.33 and latest canary #69.0.3487.0.

Bisect Information:
=====================
Good build: 67.0.3368.0
Bad Build : 67.0.3369.0

As per comment #3, suspecting the below change:
Change-Id: I336351f35077cacecf4682bddfa47322db882eba
Reviewed-on: https://chromium-review.googlesource.com/950105

ramyan@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner.
Note: Adding stable blocker for M-68 as it seems to be a recent regression. Please feel free to remove the same if not appropriate.

Thanks...!!

This seems to be due to left & top positioning for .non-google-page #ntp-contents, and seems to be solvable by explicitly setting height there (rather than letting it inherit from ntp-contents. I'll test that this also looks good on Pixelbook before sending out a cl.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e7886601e76bc2be1d43b5185ba102513f33b0dc

commit e7886601e76bc2be1d43b5185ba102513f33b0dc
Author: Ramya Nagarajan <ramyan@chromium.org>
Date: Fri Jul 13 20:25:47 2018

[NTP] Explicitly set ntp-contents height for non-google-page.

If this is not set, the #ntp-contents height is inherited, which applies
from the "top" location specified in .non-google-page, but using the
size of the overall NTP content area (at 100%), resulting in an
unnecessary scrollbar. The chosen height corresponds to MV tile height
for a single row, but also works for a row of icons, and works well on
small screens (like Pixelbook), as well as high-res screens.

Bug:  855834 

Cq-Include-Trybots: luci.chromium.try:closure_compilation
Change-Id: I8b342e066c8ddcb51b51e9f03a85e9181a001020
Reviewed-on: https://chromium-review.googlesource.com/1136860
Commit-Queue: Ramya Nagarajan <ramyan@chromium.org>
Reviewed-by: Mathieu Perreault <mathp@chromium.org>
Cr-Commit-Position: refs/heads/master@{#575053}
[modify] https://crrev.com/e7886601e76bc2be1d43b5185ba102513f33b0dc/chrome/browser/resources/local_ntp/local_ntp.css

This would mean a late merge in M68, and its severity and impact doesn't seem to warrant that. The fix will be available in M69.

Able to reproduce the issue on Mac 10.13.3 using chrome reported version #68.0.3440.33

Verified the fix on Mac 10.13.3, Win-10 and Ubuntu 17.10 using latest chrome version #69.0.3493.0 as per the comment #0 and #3.
Attaching screen cast for reference.
Observed that there is not a scroll bar, and the page can't be scroll down.
Hence, the fix is working as expected. 
Adding the verified labels.

Thanks...!!

Deleted: 855834.mp4 384 KB

	855834.mp4 384 KB View Download

 Issue 877845  has been merged into this issue.