Closed Bug 1680791 Opened 5 years ago Closed 5 years ago

[PI-873] New “about:newtab” pages are blank if a user is enrolled after creating a profile but before the first restart

Categories

(Firefox :: New Tab Page, defect, P1)

Desktop
All
defect

Tracking

()

VERIFIED FIXED
Tracking Status
firefox84 --- fixed
firefox85 --- fixed

People

(Reporter: mheres, Unassigned)

References

Details

Attachments

(1 file)

Attached video blank newtab.mp4

[Affected versions]:

  • Firefox Beta 84.0b8 (Build ID: 20201203211213)

[Affected Platforms]:

  • Windows 10
  • macOS 10.15
  • Linux Mint 20

[Prerequisites]:

  • Have Firefox installed.
  • Have this user.js file saved (made for web+normandy://stage/recipes/1325, used for testing PI-873).

[Steps to reproduce]:

  1. Create a new profile.
  2. Go to “about:support” and open the Profile Directory folder.
  3. Copy paste the user.js file from prerequisites.
  4. Make sure you have no “about:newtab” page open and restart the browser.
  5. Open a new tab.

[Expected result]:

  • The “about:newtab” page is populated with content.

[Actual result]:

  • The “about:newtab” page is completely blank.

[Notes]:

  • The issue is also reproducible using a VPN set to the US and removing the region specific preferences from user.js.
  • about:newtab pages already open before the restart will contain content.
  • The issue is also reproducible for the Control branch.
  • This issue is not reproducible if the user restarts the browser once after the region is set and then enrols in the experiment.
  • Attached is a recording of the issue.
Blocks: 1680784
No longer blocks: 680784
Flags: needinfo?(sdowne)

I'm not able to reproduce.

So unless I'm missing something with the setup, there might be something else happening that we're not seeing to cause this, that's not in the steps to test.

Flags: needinfo?(sdowne)

After further investigation:

  • it seems on Windows and macOS, it might be required to copy the user.js file in the profile folder before opening that profile for the first time to reproduce the issue.
  • the issue is not reproducible if a user.js file that only changes the preferences needed for the stage environment and the "browser.search.region" preference is used.
  • the issue is not reproducible for other experiments.
  • the issue was also reproducible for a different recipe made for the same experiment.

Update: observation not accurate
Observation: The issue seems to be related to the "browser.search.region" preference, as these steps will reproduce it (using Linux as a reference):

  1. Create and open a profile.
  2. To enroll in the study, copy in the profile folder a user.js file which also changes the browser.search.region preference (linked in the original steps).
  3. Restart the browser.
  4. Open a new tab.

But these will not:

  1. Create and open a profile.
  2. Go to "about:config" and change the browser.search.region.
  3. Restart the browser.
  4. To enroll in the study, copy in the profile folder the user.js file, but this time make sure it doesn't contain a change of the browser.search.region preference.
  5. Restart the browser.
  6. Open a new tab.

The Observation in the previous comment does not seem to be accurate. Following those steps while not settings the region at all also leads to the same results, so region is most likely not the one affecting the result.

The prerequisites are missing something: when testing on Beta or Release, an environment variable is needed. Instructions on how to set it can be found in this document.

:thecount, can you reproduce if the environment variable is set?

Flags: needinfo?(sdowne)

After some investigations and a discussion with @andreio, we've discovered that if the "messaging-system.rsexperimentloader.enabled" pref is set to "false" the issue is no longer reproducible.

It seems that there were several dummy experiments on the “Stage” server which were incomplete that might’ve caused this behavior. Andrei has removed them from the “Stage-Preview” server and we will only be able to verify that the fix worked once the changes are in the “Stage” server.

See Also: → 1681488

We've verified that the issue is no longer reproducible after the fix mentioned in comment 5 landed in the "Stage" server using Firefox RC 84 (Build ID: 20201207203640) on Windows 10 x64, macOS 10.15.6, and Linux Mint 20.

Flags: needinfo?(sdowne)

@romartin, can we close this?

Flags: needinfo?(romartin)
Priority: -- → P1

Hey @Scott,

Sure, this bug can be closed. As soon as it is closed I will mark it as VERIFIED.

Flags: needinfo?(romartin)
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED

I have verified that the issue is not reproducible by following the steps provided in comment 2 using Firefox Beta 85.0b2 en-US (Build ID: 20201215185920) on Windows 10 x64, macOS 10.15.6, and Ubuntu Linux 20.04.

Considering the above and the verification done in comment 6, I'm marking this issue as VERIFIED FIXED.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: