Build ID: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0 Nightly builds new tab page added a search bar, but it also made the tiles much smaller resulting in lots of unused white space. See attached screenshots.

What this bug requests is to make better use of the screen in higher resolutions like older versions of Firefox.

Dão did this ever present differently in previous versions on hi-dpi screens? It looks like this is an enhancement request more than a regression unless it did and if so, how far back?

Just compare the screenshots to see how it looked before in hi-dpi screens. This is a regression since it used to work well, but not anymore since bug 978338 was checked in.

According to bug 978338, this is potentially a regression in Firefox 31. Given the possibility of regression, I'm flagging this for tracking 31. I'd like to get to the bottom of the expected result of the change in bug 978338. Cornel - You represented QA on bug 978338. Can you comment on how that bug was verified given the finding in this bug? Is the smaller page expected for some reason?

The smaller page is expected because the tiles have a fixed ratio now (243x150 px) as you may see in bug 975208 (attachment https://bug975208.bugzilla.mozilla.org/attachment.cgi?id=8385835). I'm afraid this is not going to change due to this fact. As a workaround, you could change the default number of rows/columns in order to see more tiles and so, you won't have so much unused space, with the following prefs from about:config - browser.newtabpage.columns - browser.newtabpage.rows

(In reply to Cornel Ionce [QA] from comment #6) > The smaller page is expected because the tiles have a fixed ratio now > (243x150 px) as you may see in bug 975208 (attachment > https://bug975208.bugzilla.mozilla.org/attachment.cgi?id=8385835). I'm > afraid this is not going to change due to this fact. This only explains why technically the tiles are smaller. I would like to know from a UX point of view why this change would be better.

https://bug1030832.bugzilla.mozilla.org/attachment.cgi?id=8446620 is the spec for the new tiles design. Page 3 of that spec shows how larger screens will show more tiles, which can solve this bug. We can implement the requested change of page 3 to fix this bug without having to implement the rest of the new Tiles design spec.

Based on the spec that I linked to in the earlier comment, we want to show more tabs when space permits. I looked in to removing the preference values at first, since they are less useful now but that will affect add-ons that are referencing them and also removes the ability for people to limit the number of tiles that are displayed on the New Tab Page. We will now show up to 15 tiles on the New Tab Page (5 columns, 3 rows) as is described by the spec. The search container now has a fixed max-width of 600px, and I put a 12px left and right margin on the search container to match the offset that the toggle button has from the top-right corner of the page (visible when the browser window is made very narrow). The spec shows that a minimum of two columns will be shown when the browser window is < 640 pixels wide, but our tiles don't currently scale down when the viewport is narrower. This would mean that we would need to be OK with showing a horizontal scrollbar, which I'm pretty sure we don't want. In the case that the browser window is very narrow (320px for example), we will show a single column of tiles.

Added to Iteration 33.2 Jared, can you provide a point value and if the bug should be marked as [qa+] or [qa-]

Doing a little bugzilla switcharoo here. This bug is now being marked as wontfix as the size of the tiles are by design and we aren't planning on changing them in v1. Bug 1026561 will be unduped and will be used for the patch that I just attached (v2 will tweak the size of the tiles but since we will probably want to uplift this patch I went with a reduced approach to reduce the potential effects on telemetry experiments and QA risk.

wontfix, updating the tracking flags.