1026561 - The New Tab Page should be smarter about showing more tiles when on large screens

Status: VERIFIED FIXED

(Firefox :: New Tab Page, defect)

Description

[Jared Wein [:jaws] (please needinfo? me)]

Forking from https://bugzilla.mozilla.org/show_bug.cgi?id=1005596.

browser.newtabpage.rows and browser.newtabpage.columns are preferences that can be set to increase the maximum number of tiles shown on the New Tab Page.

We shouldn't be asking people to change about:config prefs to make the New Tab Page work better for them. Instead, we should remove these preferences and make the New Tab Page show more tiles by default if it can fit them without scrolling.

Comment 1

[Mardeg]

It could also be smarter about showing more tiles without their thumbnails when
browser.pagethumbnails.capturing_disabled is set to true, clipping the size to just the title text for users to click on.
Bug 1024830 is filed about doing that using the values of rows and columns prefs, but discarding the ratio to fit more tiles in for users that have explicitly blocked capturing of thumbnails should be doable without them.

Comment 2

[Ed Lee :Mardak]

Attachment: responsive design mockup

Boriss had a slide that seems to match this bug of removing the preferences

Comment 3

[Jared Wein [:jaws] (please needinfo? me)]

See page 3 of https://bug1030832.bugzilla.mozilla.org/attachment.cgi?id=8446620 to show how larger screens should handle more tiles. Bug 1016366 is basically the same as this bug, was filed earlier, and is in the firefox-backlog already.

Comment 4

[Jared Wein [:jaws] (please needinfo? me)]

Copied from bug 1016366:

Doing a little bugzilla switcharoo here. Bug 1016366 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 has been unduped and will be used for the patch that I just attached to bug 1016366 (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).

Comment 5

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch

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.

As mentioned earlier, I didn't change the size of the tiles to reduce impact on telemetry experiments and QA risk since this patch may get uplifted to Firefox 31.

Comment 6

[Marco Mucci [:MarcoM]]

Added to Iteration 33.2

Comment 7

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch v1.1

I have made the requested (over IRC) change to use -1 as a special value that says to go up to our predefined maximum. However, I have set the default here to be 5 columns and 3 rows.

The New Tab Page creates all of the tiles up to the row * column max, and then only shows as many as it can without clipping. Usability-wise, the New Tab Page becomes cluttered and hard to scan when there are over 15 tiles present. Stretching this to potentially 35 tiles (7 columns, 5 rows) shows this. Flagging Philipp for ui-review due to my above departure from the spec.

On a perf sidenote, we don't want to create excessive numbers of tiles that have a high likelihood of not being shown as the extra work for creating and deciding not to render them will be unnecessary overhead.

This patch still allows people to change the prefs to their own values above or below the defaults.

Comment 8

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch v1.1

(same comment as above)

Comment 9

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Patch v1.1 (qref'd)

Sorry for the spam, forgot to qref.

Comment 10

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8449615 [details] [diff] [review]
Patch v1.1 (qref'd)

Redirecting ui-review to Aaron or Boriss.

Comment 11

[Drew Willcoxon :adw]

Comment on attachment 8449615 [details] [diff] [review]
Patch v1.1 (qref'd)

Just reiterating what we talked about on IRC, the spec says "so on an so forth," so it's not clear to me whether the 5x3 grid shown is the maximum size or just an example of a larger size.  I'd like to understand that first.  If 5x3 really is the maximum size, then let's forget my -1/as-many-tiles-as-possible idea.  You make a good point about performance in either case.

FWIW the patch is kind of backwards from what I was thinking.  I meant that if the prefs are -1 (or 0), then that means show as many tiles as possible, not show the default number of tiles.  If the prefs are > 0, then use those numbers as the max size as usual.

Sorry to give you the runaround on this.  Thanks for taking care of it and bug 1016366.  Hopefully we'll hear back from UX soon.  If we don't, then let's just take your patch in bug 1016366 and be done with it for now.

Comment 12

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Drew Willcoxon :adw from comment #11)
> FWIW the patch is kind of backwards from what I was thinking.  I meant that
> if the prefs are -1 (or 0), then that means show as many tiles as possible,
> not show the default number of tiles.  If the prefs are > 0, then use those
> numbers as the max size as usual.

Yes, showing as many tiles as possible translates to the default number of tiles, unless you are requesting that we start showing a scrollbar in the normal case?

This patch does respect the prefs being > 0 and only using those numbers in that case.

Comment 13

[Drew Willcoxon :adw]

I'm saying (was saying) that if the rows and/or columns prefs are -1, then fill the grid with as many tiles as possible, basically 100 since that's the hardcoded maximum number of links in NewTabUtils.  The grid hides overflow automatically, so if your window can't show 100 tiles, the excess will be hidden, but if your window is big enough and you want to see them, more power to you.  We don't show a scrollbar, not now and not with what I am (was) suggesting.

Comment 14

[Ed Lee :Mardak]

Comment on attachment 8449615 [details] [diff] [review]
Patch v1.1 (qref'd)

From dcrobot: "It should fit to fill the browser window... There is no "max" number of columns, but always 3 rows."

I suppose with the current behavior of only pulling 100 links, this would effectively be 33 columns max?

Comment 15

[Aaron]

If only pulling 100 links, then yes - 33 columns max. I wonder how big of a monitor that would require...

Comment 16

[Lawrence Mandel [:lmandel] (use needinfo)]

jaws - You requested tracking for 31 and 32. This looks like new feature work. Do you have a reason why this shouldn't ride the trains?

Comment 17

[Jared Wein [:jaws] (please needinfo? me)]

I requested tracking since this bug is replacing bug 1016366 which had tracking. It solves the issue in bug 1016366 but with a different approach than what that bug requested.

Comment 18

[Lawrence Mandel [:lmandel] (use needinfo)]

Tracking- for 31 as it's too late to take this type of change on beta. Tracking+ for 32 although if we are to consider a fix it will need to land soon in order to have time to shake out issues on m-c and uplift before 32 merges to beta.

Comment 19

[Ed Lee :Mardak]

A fix that would probably be safe for beta is just changing browser.newtabpage.columns to be a large number to fill up the screen with columns. Each column is 250px (tile) + 32px (padding) so setting to 15 will still be more than could fit on a 4k pixel width.

The bigger question is what do we want on beta? 3x3? Up to 15x3? The old behavior?

Comment 20

[Marco Mucci [:MarcoM]]

Removed from Iteration 33.3

Comment 21

[Bryan Clark (DevTools PM) [:clarkbw]]

(In reply to Ed Lee :Mardak from comment #19)
> A fix that would probably be safe for beta is just changing
> browser.newtabpage.columns to be a large number to fill up the screen with
> columns. Each column is 250px (tile) + 32px (padding) so setting to 15 will
> still be more than could fit on a 4k pixel width.
> 
> The bigger question is what do we want on beta? 3x3? Up to 15x3? The old
> behavior?

I'm pretty hesitant to make this change when we know we have a more responsive design coming anyway.

Comment 22

[Bryan Clark (DevTools PM) [:clarkbw]]

(In reply to Ed Lee :Mardak from comment #19)
> A fix that would probably be safe for beta is just changing
> browser.newtabpage.columns to be a large number to fill up the screen with
> columns. Each column is 250px (tile) + 32px (padding) so setting to 15 will
> still be more than could fit on a 4k pixel width.

Convinced, we might as well bump it up for now.  15?

Comment 23

[Ed Lee :Mardak]

Attachment: v2

Looking at screen resolution stats:
http://www.w3schools.com/browsers/browsers_display.asp
http://www.w3schools.com/browsers/browsers_resolution_higher.asp

90% developers tend to max out at 2560 wide, so with the new styling from bug 1036284 will fit 7.95 columns.

http://gs.statcounter.com/#resolution-ww-monthly-201404-201406

Comment 24

[Ed Lee :Mardak]

(In reply to Ed Lee :Mardak from comment #23)
> Created attachment 8454022 [details] [diff] [review]
It sounds like we might want to get this pref change into beta so that Beta moving to Release will better make use of screen space on larger screens.

Comment 25

[Drew Willcoxon :adw]

Comment on attachment 8454022 [details] [diff] [review]
v2

Review of attachment 8454022 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry for the delay.

Comment 26

[Ed Lee :Mardak]

https://hg.mozilla.org/integration/fx-team/rev/9fe6a4141450

Comment 27

[Carsten Book [:Tomcat]]

sorry had to backout for test failures like https://tbpl.mozilla.org/php/getParsedLog.php?id=43905301&tree=Fx-Team

Comment 28

[Ed Lee :Mardak]

avih, do you know what would be causing tart to crash?

lin: https://tbpl.mozilla.org/php/getParsedLog.php?id=44080550&tree=Fx-Team
osx: https://tbpl.mozilla.org/php/getParsedLog.php?id=44083479&tree=Fx-Team
win: https://tbpl.mozilla.org/php/getParsedLog.php?id=44080347&tree=Fx-Team

PROCESS-CRASH | tart | application crashed [@ nsGlobalWindow::SetNewDocument(nsIDocument*, nsISupports*, bool)]

Is there something that expects only 3 columns of tiles, so increasing that number breaks the test?

Comment 29

[Avi Halachmi (:avih)]

(next time needinfo? me to make sure I'll respond)

Note that you can run TART locally by installing the addon and visiting the TART URI. See here https://wiki.mozilla.org/Buildbot/Talos/Tests#TART.2FCART .

(In reply to Ed Lee :Mardak from comment #28)
> Is there something that expects only 3 columns of tiles, so increasing that
> number breaks the test?

Absolutely not, and when I set the pref browser.newtabpage.columns=8 locally on an official Nightly build (windows 8.1) and run TART - it doesn't crash and completes successfully. This is the only thing the patch does so far, right?

However, when I ran it locally I did notice that the newtab tests (with or without preload or both) are a bit "weird". I.e. it looks to me that either the preload takes relatively long to complete or loading the newtab page takes relatively long, and maybe TART tries to go to its next step before one of them completes fully - and this might trigger an existing crash bug which we just weren't aware of so far.

You could maybe try reproducing it regardless of TART by quickly opening and closing tabs of newtab, while browser.newtab.preload is either true or false.

At the time we intentionally set TART to use timeouts instead of waiting for the preload-done event (or however its called) in order to not let preload duration creep up too much without us noticing it - i.e. if for some case preload would take considerably longer to complete, then TART will somehow reflect it with different results, though we weren't expecting something would crash.

Also, FYI, TART only uses high level APIs as far as opening and closing tabs go - it uses window.BrowserOpenTab(), window.BrowserCloseTabOrWindow(), and for some sub-tests it modifies the prefs browser.newtab.preload and browser.newtab.url .

Comment 30

[Avi Halachmi (:avih)]

(In reply to Ed Lee :Mardak from comment #28)
> lin: https://tbpl.mozilla.org/php/getParsedLog.php?id=44080550&tree=Fx-Team
> osx: https://tbpl.mozilla.org/php/getParsedLog.php?id=44083479&tree=Fx-Team
> win: https://tbpl.mozilla.org/php/getParsedLog.php?id=44080347&tree=Fx-Team

Also notice that on all these logs, the first thing you notice if you scroll one page down is that TART does complete fully, and talos logs all the test results, and the crash appears to be happening while already outside of tart and when the control is back to talos.

Joel, here's the full log of the Linux run: https://tbpl.mozilla.org/php/getParsedLog.php?id=44080550&full=1&branch=fx-team

Notice that at this log the crash happens at 23:23:43 which is after TART completes and while talos "finalizes" the report.

Any idea what might be going on here?

Comment 31

[Avi Halachmi (:avih)]

My current guess is that the preload system is somehow sensitive to timing, and that opening or closing a newtab page while the preload system is in a "sensitive" state will cause a later crash when closing the browser.

Comment 32

[Avi Halachmi (:avih)]

Another guess is that the preload system causes a crash if the browser is closed while preload is in a sensitive state or just plainly not done yet.

Comment 33

[Joel Maher ( :jmaher ) (UTC -8)]

looking in the logs, I don't see any data that would indicate what is going on.  Sometimes I see a failure to shutdown (timeout) and we then kill the process which looks like a crash.  I don't see any evidence of that in the log file.

Comment 34

[Avi Halachmi (:avih)]

(In reply to Avi Halachmi (:avih) from comment #31)
> My current guess is that the preload system is somehow sensitive to timing,
> and that opening or closing a newtab page while the preload system is in a
> "sensitive" state will cause a later crash when closing the browser.

(In reply to Avi Halachmi (:avih) from comment #32)
> Another guess is that the preload system causes a crash if the browser is
> closed while preload is in a sensitive state or just plainly not done yet.

Tim, any light to be shed on these possibilities?

Apparently there are also crashes on bug 1039881, though I don't know if that bug increases the preload duration, but maybe it hangs it somehow?

Comment 35

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 8454022 [details] [diff] [review]
v2

(In reply to Ed Lee :Mardak from comment #23)
> Created attachment 8454022 [details] [diff] [review]
> v2
> 
> Looking at screen resolution stats:
> http://www.w3schools.com/browsers/browsers_display.asp
> http://www.w3schools.com/browsers/browsers_resolution_higher.asp
> 
> 90% developers tend to max out at 2560 wide, so with the new styling from
> bug 1036284 will fit 7.95 columns.
> 
> http://gs.statcounter.com/#resolution-ww-monthly-201404-201406

8 columns (with 3 rows) is **far** too many. The goal here should not be to make sure that we have less white space on the new tab page, but to make it useful for people with small and large screens.

UX best practices show that 24 tiles is too much choice. People will suffer while finding what they are looking for with this many tiles on the screen.

I am OK with increasing the default from 3 to 5 columns (sticking with 3 rows), but anything over 15 will make the New Tab Page look like a mosaic instead of a high-visibility directory of the most frequently visited sites.

Comment 36

[Ed Lee :Mardak]

dcrobot, your design spec says "So on and so forth if > 1570" on page 3 implying the number of columns increases to fill the space: https://bug1030832.bugzilla.mozilla.org/attachment.cgi?id=8446620

jaws says there shouldn't be more than 5 columns.

Comment 37

[Aaron]

Why would we limit the number of tiles a user can see if she has a big-ass monitor? Is there a specific logic or technical reason for max 5 columns?

Comment 38

[Avi Halachmi (:avih)]

Aaron, any reason you canceled the needinfo for Tim? My question from comment 34, for which I requested the info, is still unanswered.

Comment 39

[:Gavin Sharp [email: [e-mail]]]

(In reply to Aaron from comment #37)
> Why would we limit the number of tiles a user can see if she has a big-ass
> monitor? Is there a specific logic or technical reason for max 5 columns?

See comment 35?

Comment 40

[CAK]

(In reply to [Away for most of July] (please needinfo? me) Jared Wein [:jaws] from comment #35)
> Comment on attachment 8454022 [details] [diff] [review]
> v2
> 
> (In reply to Ed Lee :Mardak from comment #23)
> > Created attachment 8454022 [details] [diff] [review]
> > v2
> > 
> > Looking at screen resolution stats:
> > http://www.w3schools.com/browsers/browsers_display.asp
> > http://www.w3schools.com/browsers/browsers_resolution_higher.asp
> > 
> > 90% developers tend to max out at 2560 wide, so with the new styling from
> > bug 1036284 will fit 7.95 columns.
> > 
> > http://gs.statcounter.com/#resolution-ww-monthly-201404-201406
> 
> 8 columns (with 3 rows) is **far** too many. The goal here should not be to
> make sure that we have less white space on the new tab page, but to make it
> useful for people with small and large screens.
> 
> UX best practices show that 24 tiles is too much choice. People will suffer
> while finding what they are looking for with this many tiles on the screen.
> 
> I am OK with increasing the default from 3 to 5 columns (sticking with 3
> rows), but anything over 15 will make the New Tab Page look like a mosaic
> instead of a high-visibility directory of the most frequently visited sites.

If there is no technical reason against it, why don't you let the user decide on what is useful for him/her? You say that 3 rows by 8 columns is far too many and that people will suffer while finding what they are looking for. I currently use 8 rows x 10 columns on my 17" laptop and I consider it to be very useful and comfortable. The tiles of the current "forced" setting of Nightly (4 rows x 6 columns) are imho unnecessarily big (and the colors too flashy but that's another story).

Comment 41

[Aaron]

CAK - agreed. If the user wants less tiles, she can always resize her browser. In fact, if the user has their browser set to fill their large screen, then that would infer they want to see as much as possible (not that they love white space).

2 cents.

Comment 42

[:Gavin Sharp [email: [e-mail]]]

(In reply to Aaron from comment #41)
> CAK - agreed. If the user wants less tiles, she can always resize her
> browser.

I don't really understand this line of reasoning - if we share the assumption that for most people (CAK's personal anecdotes aside), a new tab page with dozens of tiles is overwhelming and makes it difficult to pick out the one you want, then making that the user's problem and requiring that they reduce their browser window size (or un-maximize it if they're on Windows) to address that seems far from optimal. It sounds like you don't share that assumption, and think the downsides to many tiles are non-existent or outweighed by the flexibility?

Comment 43

[CAK]

(In reply to :Gavin Sharp [email: [e-mail]] from comment #42)
> I don't really understand this line of reasoning - if we share the
> assumption that for most people (CAK's personal anecdotes aside), a new tab
> page with dozens of tiles is overwhelming and makes it difficult to pick out
> the one you want, then making that the user's problem and requiring that
> they reduce their browser window size (or un-maximize it if they're on
> Windows) to address that seems far from optimal. It sounds like you don't
> share that assumption, and think the downsides to many tiles are
> non-existent or outweighed by the flexibility?

Why reduce their browser window size (or un-maximize) when they can have a full screen window with a preference for less (huge size) rows and columns? Despite the downsides to many tiles (loading speed, memory required etc.) it should still be up to the user to decide whether they want many tiles (and slower loading newtab page) or few tiles (and fast loading page). Giving the user the option to choose what they prefer is not the same as you say "making it a user's problem". (How about the radio in your car having a fixed volume setting since too high would be harmful to your ears and too low would be difficult to hear? ;)) (one more personal anecdote: new colors are much better! :))

Comment 44

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Aaron from comment #37)
> Why would we limit the number of tiles a user can see if she has a big-ass
> monitor? Is there a specific logic or technical reason for max 5 columns?

See http://uxmyths.com/post/712569752/myth-more-choices-and-features-result-in-higher-satisfac for more background behind comment #35.

I would also like to add that in this specific case of showing websites on the New Tab Page, I would postulate that there is an extremely long tail of low frecency websites a person visits. After some low number of websites (likely in the single digits or teens), the remaining low frecency websites will be indistinguishable and not provide value to the user.

Comment 45

[CAK]

(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #44)
> See
> http://uxmyths.com/post/712569752/myth-more-choices-and-features-result-in-
> higher-satisfac for more background behind comment #35.

You are right! That's why iPhone sold like crazy! ;) To present all those options to the (new) user would be overwhelming. But you can set the satisfaction level even higher by keeping the fine-tuning options hidden (as they are now in about:config) and available only to the power user who seeks for them. 


> I would also like to add that in this specific case of showing websites on
> the New Tab Page, I would postulate that there is an extremely long tail of
> low frecency websites a person visits. After some low number of websites
> (likely in the single digits or teens), the remaining low frecency websites
> will be indistinguishable and not provide value to the user.

This is correct. The most valued tiles on the New Tab Page are the "pinned" tiles (which is a fantastic feature). At the end of the day the New Tab Page plays the role of a "Where do you want to go today?" menu.

Comment 46

[:Gavin Sharp [email: [e-mail]]]

This should have been fixed on 31/32 by bug 1038997. Tracking for 33 to ensure bug 1030832 addresses that there.

Comment 47

[Ed Morley [:emorley]]

A patch from this bug just landed without comment (https://hg.mozilla.org/integration/fx-team/rev/ad5e5e0f18ea), but I've just had to revert it for intermittent failures like:
https://tbpl.mozilla.org/php/getParsedLog.php?id=46036251&tree=Fx-Team
https://tbpl.mozilla.org/php/getParsedLog.php?id=46029514&tree=Fx-Team
https://tbpl.mozilla.org/php/getParsedLog.php?id=46033963&tree=Fx-Team

remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/c3ab83f45b5d

Comment 48

[Ed Morley [:emorley]]

(In reply to Ed Morley [:edmorley] from comment #47)
> remote:   https://hg.mozilla.org/integration/mozilla-inbound/rev/c3ab83f45b5d

Sorry, correct backout URL:
remote:   https://hg.mozilla.org/integration/fx-team/rev/77cef94e4b4b

Comment 49

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/05f052f7c894

Comment 50

[Ed Lee :Mardak]

There's 5-15% tp5o main-rss/private bytes regression in addition to 1-3% tab animation test regression.

http://graphs.mozilla.org/graph.html#tests=[[261,64,33],[261,64,37],[261,64,25],[261,64,22],[261,64,24]]&sel=1408213299475,1408286099475,61904761.90476191,390476190.47619045&displayrange=7&datatype=running

dcrobot/clarkbw, this change to have 8 columns (24 tiles) tries to display 2.66x the number of tiles, so the regression is expected. However, most users will only be able to see 4 or 5 columns anyway.

Each cell is roughly 330px wide, so given these resolutions:

31% 1366x 768 -> 4 columns
13% 1920x1080 -> 5 columns
 8% 1280x1024 -> 3 columns
 7% 1440x 900 -> 4 columns
 7% 1280x 800 -> 3 columns
 6% 1600x 900 -> 4 columns
 6% 1024x 768 -> 3 columns
 5% 1680x1050 -> 5 columns
 3% 1920x1200 -> 5 columns
 2% 1360x 768 -> 4 columns
 1% 2560x1440 -> 7 columns
.5%  800x 600 -> 2 columns
.5% lower
 9% higher

The smarter fix would be to only create the appropriate number of tiles that can actually be displayed, but the preloading and ability to resize the window will complicate things.

Should we just go with 5 columns and the associated "regression-from-3" / "improvement-from-8" as that fix is simple and matches most users?

Comment 51

[Cornel Ionce [:noni] [Hubs QA]]

Confirming that Firefox 32 beta and 31 release were fixed by bug 1038997.

Also, confirming this fix for latest Nightly (build ID: 20140818030205). The number of columns/rows change according to the screen resolution.
The "browser.newtabpage.columns" pref is set by default to 8.

Please let me know if you consider changing the number of columns to 5.
I'll also mark 31 and 32 verified based on comment 46.

Comment 52

[Joel Maher ( :jmaher ) (UTC -8)]

The regressions outlined in comment 50 didn't seem to have any discussion.  Have we weighed the pros/cons of our decision here?  Should we go with 5 columns instead of 8?

Comment 53

[Bryan Clark (DevTools PM) [:clarkbw]]

(In reply to Ed Lee :Mardak from comment #50)
> There's 5-15% tp5o main-rss/private bytes regression in addition to 1-3% tab
> animation test regression.
> 
> http://graphs.mozilla.org/graph.html#tests=[[261,64,33],[261,64,37],[261,64,
> 25],[261,64,22],[261,64,24]]&sel=1408213299475,1408286099475,61904761.
> 90476191,390476190.47619045&displayrange=7&datatype=running
> 
> dcrobot/clarkbw, this change to have 8 columns (24 tiles) tries to display
> 2.66x the number of tiles, so the regression is expected. However, most
> users will only be able to see 4 or 5 columns anyway.

Ed, switching to 5 tiles makes sense to me.  Meaning 15 tiles would be the max number shown.

Comment 54

[Ed Lee :Mardak]

(In reply to Joel Maher (:jmaher) from comment #52)
> Should we go with 5 columns instead of 8?
Filed bug 1055261 with patch.

Comment 55

[Avi Halachmi (:avih)]

This might be a late suggestion, but following some experimentation with the "dynamic number of tiles" which just landed, I think it could create some disorientation when the number/position of tiles change while resizing the browser (e.g. the thumb on the 4th column of the first row in full screen moves to the first column on the second row when resizing the browser).

Being able to know/expect the tile at a specific position on screen, especially for pinned tiles, has non negligible value IMO.

Some time ago there was an implementation where the tiles would keep their number and position but resize with the browser. I think this could be a more consistent and predictable behavior for the user.

If we feel like going the extra mile, the newtab "menu" could offer few modes:
1. Choice between reflow and fixed positions.
2. Choice between 2 or more density/sizes.

For fixed positions, each of the density choices would imply a different tiles matrix width/height.

Comment 56

[Ed Lee :Mardak]

https://hg.mozilla.org/releases/mozilla-aurora/rev/56ca563b495a

Comment 57

[Cornel Ionce [:noni] [Hubs QA]]

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:33.0) Gecko/20100101 Firefox/33.0
Mozilla/5.0 (X11; Linux i686; rv:33.0) Gecko/20100101 Firefox/33.0

Verified fixed on Windows 7 64bit, Mac OS X 10.8.5 and Ubuntu 14.04 32bit using latest Aurora, build ID: 20140828004002 during verification of bug 1055261.