about:newtab doesn't show thumbnails when opened using ctrl-T. Pressing refresh will show them.

I'm seeing this as well. This isn't specific to "Ctrl-T" -- the "+" button in the tab strip has the same effect. However, if I type "about:newtab" into an existing tab's URL bar and hit enter, then I see the thumbnails (no bug). My nightly browsing profile reproduces this bug 100% of the time. I couldn't initially reproduce in a fresh profile (i.e. there, I see search field + thumbnails in about:newtab) , but after waiting a few minutes and trying again, I was able to reproduce (no more thumbnails in new tabs).

Here's a snapshot of a near-fresh profile (with a bunch of unnecessary files removed) that reproduces this for me. STR: 1. Extract this tarball 2. Run (on Linux at least): firefox -no-remote -profile profile 3. Open a new tab. In the new tab, dashed thumbnail boxes briefly appear, and then disappear after a second. They come back if I reload.

I'm assuming we'll be pushing this bug to Aurora users, when Aurora gets a new trunk snapshot later this week (and bumps to version 31). Setting tracking flag to make sure we don't forget to backport the eventual fix to them.

What ends up showing? Just the search input and buttons? The toggle to show/hide?

The search input and the show/hide toggle button all show up. Just no thumbnails. Screenshots coming.

(Note that the input expands to the width of the thumbnail-grid after I refresh & make the thumbnails appear, too.)

My nightly info, FWIW: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 31.0a1 (2014-04-28)

Thanks, Daniel. With your profile data, I can reproduce on the latest Nightly but not on my freshly built debug build. The tiles actually appear right after opening a new tab but then disappear a split second later. After creating a new profile, the problem starts happening after I copy both experiments.json and prefs.json to the new profile. Maybe that points to an experiments problem. Are experiments disabled on hand-built Firefoxes but enabled on Nightly? That might explain what I'm seeing.

Yeah, this is due to the Tile Switcher experiment add-on I'm pretty sure. Blake, Benjamin, I think you guys worked on that? https://github.com/bwinton/tile-switcher/blob/master/data/newtabicons-content.js Bug 980014 changed how newtab creates its grid. There's no .newtab-row anymore, so the content script at the above URL just ends up removing all the grid cells and never adds them back. How it works now is that cells are appended directly to #newtab-grid, and the grid's width makes them flow into rows naturally.

I would totally believe that, and have seen similar things in Whimsy… I can see a few ways we could handle this. 1) I'm more than happy to update the two add-ons I wrote which are currently using newtab-row. (But that wouldn't catch any other add-ons which may be accessing the newtab-row.) 2) Would it be possible to re-add the newtab-row class? (I suspect it might be difficult, given the description of the new behaviour…) 3) Perhaps we should instead not run the Tile Switcher experiment on Nightly? (Since the data would be decidedly skewed if the layout also changed in the middle of the test.) Benjamin, Ed: Any preferences on which option to go with (or any suggestions of better options ;) ?

We have two options for the experiment: we can either force-kill it now (which would be a reasonably good test of the force-kill feature!) or we can publish an update. If we do an update, it would be nice for it to work with both the old and new nightly styling, but I don't know whether that's feasible.

We could probably add back .newtab-row -- by grouping cells into <span>s each time the grid is resized -- but I'd rather not. (I tried searching https://mxr.mozilla.org/addons/ to see who else uses .newtab-row, but it's timing out or something.) It ought to be possible to make the add-on work with all Nightlies. The only difference is the parent of the cells. The rearranging logic would work the same otherwise.

This seems to work to determine if a cell is visible or not :) for (cell of document.querySelectorAll(".newtab-cell")) console.log(cell == document.elementFromPoint(cell.offsetLeft, cell.offsetTop)) Then that can be used to feed into something that changes the order of the Links returned? Perhaps some monkeypatching: Links._getLinks = Links.getLinks; Links.getLinks = function() { let links = this._getLinks(); return reordered link based on which how many are visible ? };

Here's a new XPI from the latest code at https://github.com/bwinton/tile-switcher which should fix the problem.

http://hg.mozilla.org/webtools/telemetry-experiment-server/rev/4286d696976a Kamil, can you please verify on staging that this upgrades correctly. STR: * Using production (the old .xpi), set the sample-pref and make sure the experiment is installed and broken * Switch the manifest URL to telemetry-experiment-dev.allizom.org. * Test that the new version of the experiment is installed correctly and that control-t works properly. mmucci please add this to the 32.1 iteration.

I can verify my problem went away with this installed :) Thanks!

Added to Iteration 32.1 Benjamin, can you provide a point estimate.

Went through the verification process using the latest Nightly build from the following location: - http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-04-30-03-02-01-mozilla-central/ Reproduced the original issue from comment #0 and comment #1: - Installed the latest nightly from the link above - Changed "experiments.manifest.uri" to "http://kamiljozwiak.com/firefox-manifest.json" which is using the older XPI - Once the experiment has been installed, ensured that selecting "+" and "CTRL + T" would create a new tab without the tiles being visible - Also as per comment #1, ensured that about:newtab would display the tiles correctly Went through the following test cases to ensure that the issue has been resolved: - Installed the latest nightly from the link above - Changed "experiments.manifest.uri" to "https://telemetry-experiment-dev.allizom.org/firefox-manifest.json" which is using the newer XPI - Insured that the experiment was downloaded via "about:support" and "about:addons" - Ensured tiles are visible when creating a new tab via "CTRL + T" - Ensured tiles are visible when creating a new tab via selecting "+" - Ensured tiles are visible when creating a new tab via "File -> New Tab" - Ensured tiles are visible when creating a new tab via "about:newtab" - Went through the above cases in OSX 10.9.2 and Windows 8.1

I can't reproduce anymore. (hooray!) I'm guessing comment 16 & beyond have fixed this -- if so, can we close this out?

Yes, this was deployed in bug 1004024.

Changing this back to [qa!] as testing has already been completed. This only affected Nightly users as the experiment was only launched on the Nightly channel and not on Aurora. Telemetry Experiments is currently enabled on Aurora but the experiment will not be installed as the manifest.json specifies that it install's only on Nightly. The following error will be logged in the Browser Console when attempting to install the current experiment on Aurora: "1399492991180 Browser.Experiments.Experiments DEBUG ExperimentEntry #0::isApplicable() - id=tile-switcher@experiments.mozilla.org - test 'channel' failed"