2007810 - new tab page always empty/gray/grey, tab tooltip shows it as about:blank but settings list about:newtab as url to open

Status: VERIFIED FIXED

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

Description

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

[Tracking Requested - why for this release]: Should get at least an assessment how many profiles are impacted to not see about:newtab.

This behavior has been observed twice by me: Once on a Windows 11 machine of a different person with Firefox in German and no opportunity to investigate, and on a Windows 10 machine with Firefox 146.0.1 in English on a Windows in German.

If the browser is launched (without session restore), the only tab is empty/grey/gray and its tooltip reads "New Tab about:blank". Settings > Home > New Tab lists "Firefox Home (default)" as page to open. There is nothing related in the Browser console.

About the Windows 10 installation: It is a relatively bare-bones Firefox profile which was used to create profile clones for testing. The issue started after all the Firefox prompts had been manually denied: Firefox backup, location for weather widget on about:newtab and at least one more prompt if I remember correct.

The Windows 11 installations has no add-ons and the Windows 10 only something to block some webrtc requests.

Comment 1

[Dianna Smith [:diannaS]]

pinged maxx on slack to take a look

Comment 2

[Maxx Crawford [:maxx]]

Attachment: New Tab Hover Text

Note I shared this with the new tab team and we're investigating.

If I set my new tab to "Blank page" (via the New tabs and windows" section on about:preferences#home), when I hover over the new tab page, it shows this (see screenshot)

I do have a follow-up question: Does this affect only the first about:home visit or if does it also affects newly opened tabs?

Additionally, what is the pref browser.settings-redesign.enabled set to? (We recently landed code that controls how this works and may be affecting/not respecting the about:settings settings)

Thanks!

Comment 3

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

browser.settings-redesign.enabled is set to false.

This affects every new tab opened in addition to the one opened at start and also in new windows.

If the default page for new windows and tabs gets changed to "Blank Page", the tab tooltip will show "about:newtab" as expected, not about:blank.

I can try to bisect this later by adding and removing values from the preferences file. Or would a different data storage be more interesting? Because it is a barebones profile, sharing it with you is also possible.

Comment 4

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

The removal of preferences from the prefs.js file in the profile fixes the issue but there is no determinism which preference needs to be removed based on bisection attempts. For the latest attempt, the removal of these preferences fixed it:

user_pref("extensions.ui.dictionary.hidden", false);
user_pref("extensions.ui.experiment.hidden", true);
user_pref("extensions.ui.extension.hidden", false);
user_pref("extensions.ui.lastCategory", "addons://list/locale");
user_pref("extensions.ui.locale.hidden", false);
user_pref("extensions.ui.mlmodel.hidden", true);
user_pref("extensions.ui.plugin.hidden", false);
user_pref("extensions.ui.sitepermission.hidden", true);
user_pref("extensions.update.notifyUser", false);

Comment 5

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:thecount, could you have a look please?

For more information, please visit BugBot documentation.

Comment 6

[Simona Rosu [:srosu], Ecosystem QA]

Hi, Maxx! I managed to consistently reproduce this issue while using the stage‑preview server. I’m not entirely sure what triggers it, since all I do is accept the Terms of Use and then close and reopen the browser. I thought it might be related to some experiments I’m enrolled in, so I tried unenrolling from them one by one, leaving only a single experiment active on the profile, but in that case I can no longer reproduce the issue. I haven’t been able to reproduce it on the prod server or on stage. It is reproducible only on stage‑preview, and it doesn’t depend on locale, since I can reproduce it even on en-* builds with English OS language. It’s reproducible on the latest version of Nightly 148.0a1 (Build ID 20260111214232), Firefox Beta 147.0 (Build ID 20260105210555) and Firefox Release 146.0.1 (Build ID: 20251217121356) on Windows 10 x64, macOS 15.5 and Ubuntu 24.04.1.

Here is the user.js I’ve used on testing.

And here is the screen recording of the issue: link.

Comment 7

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

This is not reproducible except with the backup of the old profile.

Comment 8

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Hitting this again with v148.0: A profile works as expected but if the profile folder is copied, the copy does not show the new tab content.

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:thecount, could you have a look please?

For more information, please visit BugBot documentation.

Comment 10

[Scott [:thecount] Downe]

It kinda feels like there might be 2 issues? Not sure.

:aryx Seems to only hit this with the backup of the old profile.
:srosu Seems to have different steps related to the stage‑preview server.

I don't yet see a connection.

Comment 11

[Simona Rosu [:srosu], Ecosystem QA]

Hi, I retested this issue today, and I was still able to reproduce it on the stage-preview server. After further investigation, I found that I was enrolled in a session restore experiment where one of the branches was configured so that the first new tab after startup would be blank, so in this case, the behavior is intended. I can confirm that the issue is no longer reproducible after removing the study.

Comment 12

[Scott [:thecount] Downe]

I can reproduce consistently on both Linux and Windows with these steps:

Build an xpi

1. In browser/extensions/newtab/manifest.json, bump the version by one minor (e.g. 150.2.0 → 150.3.0)
2. Build and run firefox
3. Find and copy obj-x86_64-pc-linux-gnu/dist/xpi-stage/[e-mail] (obj-x86_64-pc-linux-gnu might be different for you if you are on a mac), save that somewhere.
4. Reset browser/extensions/newtab/manifest.json

Install the xpi

1. Build and run with a fresh profile
2. In about:config, set:
   a. "xpinstall.signatures.required" to false
   b. "browser.newtabpage.trainhopAddon.version" to whatever you set it to in step 2 (for me 150.3.0)
3. In about:addons, install the xpi we stashed from before.
4. Restart, about:support should list the installed xpi version (for me 150.3.0)

Trigger the bug

1. Go to about:support
2. Open Profile Directory
3. Copy the profile folder
4. Paste it somewhere, (I used mozilla-central)
5. Build and run with the new profile dir (for me this was ./mach build && ./mach run --profile /home/scott/mozilla-unified/14bshfzh.blank/ --jsdebugger)

Comment 13

[Scott [:thecount] Downe]

Attachment: Bug 2007810 - Newtab trainhop XPI fix if paths don't match, if we have an XPI but the paths are different, we can correct it.

Comment 14

[Luca Greco [:rpl] [:luca] [:lgreco]]

Based on the STR described in comment 12, this looks like a duplicate of Bug 1429838.

I'm going to take a closer look to confirm if that is the case as it looks, in the meantime I'm adding Bug 1429838 as a seealso.

Comment 15

[Mike Conley (:mconley) (:⚙️)]

While moving profile folders like this is not a common user action, the backup / restore mechanism that we've been working on and that we've been rolling out to Win 10 users (and soon to more users) may also expose this, and may make this more of an issue.

@thecount, when you have a second, can you re-run your STR in 12, but for your triggering scenario, try:

1. Make sure browser.backup.archive.enabled and browser.backup.restore.enabled are set to true in about:config
2. Go to about:settings, and click on the "Sync" pane
3. Scroll down to the "Backup" section, and click the "Turn on backup" item
4. In the dialog that appears, choose a folder to save the backup to (any will do, just remember it), and then click on "Turn on backup". For this test, it is not necessary to backup sensitive data (passwords, payment methods)
5. This will immediately start the backup process for the current profile. Once it completes, an HTML file should be written to the folder selected in (4).
6. In about:settings#sync in the same instance of Firefox you created the backup in, click on "Restore" to restore from the backup
7. Choose the backup file that was created, and click "Restore and restart"
8. After the browser restarts, check to see if the newtab XPI is properly loaded.

Comment 16

[Scott [:thecount] Downe]

@mconley, I can confirm these steps expose this and make it more of an issue.

Comment 17

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #15)

While moving profile folders like this is not a common user action, the backup / restore mechanism that we've been working on and that we've been rolling out to Win 10 users (and soon to more users) may also expose this, and may make this more of an issue.

I was wondering if that backup/restore feature would also be hitting the same issue and after reading the implementation I was pretty sure that was going to be the case, I also found Bug 1886235 which based on its comment 0 looks like it was filed for exactly for this kind of backup/restore issue with addons (and this bugzilla issue is how that pre-existing issue surface for a newtab train hop xpi).

I'm link also Bug 1886235 as a see also to this bug.

Comment 18

[Luca Greco [:rpl] [:luca] [:lgreco]]

I've attached to Bug 1429838 (the pre-existing bugzilla ticket mentioned in comment 15, which is tracking fixing the same kind of underlying issue hit on Firefox profile that have been relocated since the last browser session) a new patch and a new test case mocking the "relocated Firefox profile" scenario to cover the changes applied by that patch with explicit automated tests.

While working on the new patch for Bug 1429838 I noticed that there is at least a couple other edge cases where the newtab page may fail to load in the same way:

• if the XPI file has been removed or if it corrupted and we are unable to read the assets packaged in the zip file (e.g. faulty disk/filesystem)

These edge cases would not be handled by Bug 1429838, but would lead to a similar outcome.

While the new Bug 1429838 patch is waiting for a review pass, I'm taking a look into what we could do on the AboutNewTabResourceMapping.sys.mjs side to handles these edge cases more gracefully, which I think should also mitigate the issue hit with the "Firefox profile relocated" scenario.

If the approach will feel reasonable and low risky, that may be what we may consider requesting an uplift for 149 beta (given that this issue is being already hit by users based on what I learnt from Scott yesteday in our brief chat over slack, and that Bug 1429838 may have additional potential side effect and be potentially riskier even if we keep it as simple as possible).

I'll come back with more updates (and possibly a draft patch attached to this bugzilla issue) asap.

Comment 19

[Scott [:thecount] Downe]

I'm taking a look into what we could do on the AboutNewTabResourceMapping.sys.mjs side to handles these edge cases more gracefully, which I think should also mitigate the issue hit with the "Firefox profile relocated" scenario.

Does this part "should also mitigate the issue hit with the "Firefox profile relocated" scenario", does this mean the fixes in D286884 do not fix the backup/restore path in about:settings#sync?

if the XPI file has been removed or if it corrupted and we are unable to read the assets packaged in the zip file (e.g. faulty disk/filesystem)
These edge cases would not be handled by Bug 1429838, but would lead to a similar outcome.

This is probably fine, as long as it's fixing the backup/restore path in about:settings#sync, I think the edge cases are less urgent.

If the approach will feel reasonable and low risky, that may be what we may consider requesting an uplift for 149 beta

If it's too risky, could we consider a very small less risky fix just for this case, along side the larger more complete more risky patch?

Comment 20

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to Scott [:thecount] Downe from comment #19)

Does this part "should also mitigate the issue hit with the "Firefox profile relocated" scenario", does this mean the fixes in D286884 do not fix the backup/restore path in about:settings#sync?

The issue with backup/restore is exactly the same "Firefox profile relocated" scenario that D286884 should be handle and so D286884 would handle that edge case once completed and landed.

if the XPI file has been removed or if it corrupted and we are unable to read the assets packaged in the zip file (e.g. faulty disk/filesystem)
These edge cases would not be handled by Bug 1429838, but would lead to a similar outcome.

This is probably fine, as long as it's fixing the backup/restore path in about:settings#sync, I think the edge cases are less urgent.

It is for sure not that easily hit as the one that backup/restore on a different path would consistently trigger.

If the approach will feel reasonable and low risky, that may be what we may consider requesting an uplift for 149 beta

If it's too risky, could we consider a very small less risky fix just for this case, along side the larger more complete more risky patch?

That is what I meant with "what we could do on the AboutNewTabResourceMapping.sys.mjs side", changes on the XPIProvider side and at that low level of its logic does rarely feels like low risky (but I'm also waiting to see how Rob feels about the changes, I tried to keep them as small and low risky as possible, included not breaking compatibility by not changing the addonStartup.json.lz4 and extensions.json file formats).

And so I wanted to also double-check what we could do on the AboutNewTabResourceMapping.sys.mjs side" that could hadle more gracefully the issue with relocated Firefox profile (while proper fix for Bug 1429838 is ready to land and ride the train) along with handling more gracefully the other edge cases mentioned in my previous comment.

Comment 21

[Luca Greco [:rpl] [:luca] [:lgreco]]

Attachment: Bug 2007810 - Make sure AboutNewTabResourceMapping fallbacks to map builtin resources if XPI file is not inside the current Firefox profile path.

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/891eff1b0862
https://hg.mozilla.org/integration/autoland/rev/d98916e2873b
Make sure AboutNewTabResourceMapping fallbacks to map builtin resources if XPI file is not inside the current Firefox profile path. r=mconley,thecount,home-newtab-reviewers

Comment 23

[rperta]

https://hg.mozilla.org/mozilla-central/rev/d98916e2873b

Comment 24

[BugBot [:suhaib / :marco/ :calixte]]

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 25

[BugBot [:suhaib / :marco/ :calixte]]

The patch landed in nightly and beta is affected.
:thecount, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox149 to wontfix.

For more information, please visit BugBot documentation.

Comment 26

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Breaking newtab for users that have done a profile backup after being in a new tab trainhop
• Code covered by automated testing?: yes
• Fix verified in Nightly?: no
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: Steps to test are in bug 2007810, comment 12 and 15. Those steps should be sufficient for the whole stack.
• Risk associated with taking this patch: low
• Explanation of risk level: This is unlikely to make anything worse than it already is for the impacted users, and the changes are as minimal and purpose built for an uplift as we could.
• String changes made/needed?: None
• Is Android affected?: no

Comment 27

[Scott [:thecount] Downe]

Attachment: Bug 2007810 - Make sure AboutNewTabResourceMapping fallbacks to map builtin resources if XPI file is not inside the current Firefox profile path.

Original Revision: https://phabricator.services.mozilla.com/D286973

Comment 28

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/76a74aaec286
https://hg.mozilla.org/releases/mozilla-beta/rev/675865703182

Comment 29

[Simona Rosu [:srosu], Ecosystem QA]

I have verified this issue using the latest Firefox Nightly 150.0a1 (Build ID: 20260315085700) and Firefox Beta 149.0b8 (build ID: 20260313102041) on Windows 10 x64, macOS 15.7.3, and Ubuntu 24.04.1.

• After following the steps outlined in the comment 12, I can confirm that the new tab addon is correctly displayed and enabled in the ‘about:support” page.