All the "New Tab" features should be disabled when the "New Tab Page" is disabled ("browser.newtabpage.enabled"=false)
Categories
(Firefox :: New Tab Page, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox146 | --- | fixed |
People
(Reporter: whimboo, Assigned: thecount, NeedInfo)
References
(Depends on 1 open bug, Blocks 2 open bugs)
Details
(Whiteboard: [hnt])
Attachments
(1 file)
I’ve noticed a recurring issue in our WebDriver implementation, which intentionally disables about:newtab. Each time a new feature is added to the New Tab page — such as wallpapers, the activity stream content, or other enhancements — a number of new preferences are introduced. This requires us to manually identify and disable each feature individually to ensure it doesn’t interfere with our automation scenarios, and that even with about:newtab disabled.
To prevent this extra work in the future, we suggest that any new feature on the New Tab page should only be enabled if the browser.newtabpage.enabled preference is set to true. This would act as a single, overarching check to ensure features dependent on the New Tab page remain inactive when the page itself is disabled.
This adjustment would significantly streamline automation workflows by reducing the need for repeated manual intervention whenever new features are added. It would also ensure consistency across testing environments and avoid potential disruptions caused by inadvertently enabled features.
|
Assignee | |
Comment 1•10 months ago
|
||
Can you help me understand if the issue is the pref itself, or the functionality the pref enables?
I would imagine right now, if weather is set to true, but newtab is not enabled, that weather itself would not be present, even if the pref is true.
So are you asking the pref itself is set to false, if newtab is turned off, or are you just making sure the feature itself is not on, even if the pref is true?
|
|
Assignee | |
Updated•9 months ago
|
|
Reporter | |
Comment 2•9 months ago
|
||
Sorry I was unexpectedly off this week.
So this is about all the individual features the new tab page offers and that those are not automatically disabled when the new tab page is disabled. Instead for each feature you have to find the right prefs and disable them. The problem with automation is that this can have side-effects eg a new feature downloads external sources and causes tests in CI to crash due to non-local network connections. But there can be as well new notifications that we are not aware of but could cause issues with user interactions like blocking parts of the page so that clicks do not get through.
Also it means that services are running that are not used at all unless someone explicitly navigates to about:newtab.
For the weather feed I found that:
https://searchfox.org/mozilla-central/rev/b0b003e992b199fd8e13999bd5d06d06c84a3fd2/browser/extensions/newtab/lib/WeatherFeed.sys.mjs#30-62
It's not checking for the about new tab enabled but only for its own preferences. Other components / services might behave the same.
|
||
Comment 3•9 months ago
|
||
The severity field is not set for this bug.
:thecount, could you have a look please?
For more information, please visit BugBot documentation.
|
|
Reporter | |
Comment 4•8 months ago
|
||
Hey Scott. Do you have some more information what could be done here? Did my feedback help do you still need more details? Thanks.
|
|
Assignee | |
Comment 5•7 months ago
|
||
Sorry, I missed this.
Yeah, you answered my question.
Your issues seems to be feeds that are controlled by prefs are still active during your tests even though the newtab pref is flipped off.
Curious, are you flipping the newtab pref off before you run the tests or at run time?
I would agree this is unexpected and not very efficient. My solution would probably be to ensure the uninit event gets fired when the newtab pref is flipped off, and the feeds can then listen to and handle that, instead of checking a new pref in each feed. (tbh I though that already happened.)
I think in general we don't purposefully leave features on or need features on when newtab is off, so I suspect something is not working as expected.
|
|
Assignee | |
Comment 6•7 months ago
•
|
||
nvm, I see it in the title. It's browser.newtabpage.enabled
Actually, I don't think it's obvious to me how you are turning off newtab.
Is there a pref you flip to turn off newtab?
|
|
Assignee | |
Comment 7•7 months ago
|
||
nvm, I see it in the title. It's browser.newtabpage.enabled
|
|
Assignee | |
Comment 8•7 months ago
|
||
Using weather as the feed to test this.
So looks like it doesn't matter if you flip browser.newtabpage.enabled at run time or not, the feed lifecycle methods still run.
That feels wrong to me, not sure if that was like a decision or an oversight on the original implementation. I'll investigate more.
|
|
Assignee | |
Comment 9•7 months ago
•
|
||
Looks like "browser.newtabpage.enabled" is specifically used for setting the newtab page to blank only for newtab. Not homepage and new windows. So we probably don't want to use that here. (Which is a very misleading pref name)
So we think what we should do.
We should add a pref "browser.newtabpage.shouldInitialize" that we can check against in init in AboutNewTab.sys.mjs: https://searchfox.org/mozilla-central/source/browser/modules/AboutNewTab.sys.mjs#48
And if it's false, bail out.
This should stop every feed from initializing, which would now mean you don't need to care about anything else going forward.
|
|
Reporter | |
Comment 10•6 months ago
|
||
As mentioned earlier on Slack this would be a good approach and would help a lot. I assume that this preference can be set/updated at any time and not requiring a restart of Firefox?
|
|
Assignee | |
Comment 11•6 months ago
|
||
I think if it needs a restart or not depends on how we build it.
It is much easier for us to have it require a restart, but it's helpful to know what requirements you have for something like this for it to be useful to you. Do you need it to not require a restart?
If you were to turn on this pref after the browser has started, would it be too late, and a newtab has already made external network connections?
|
|
Reporter | |
Comment 12•6 months ago
|
||
Thanks Scott. I think we should focus on the easiest implementation for you here. If it makes it easier to have it not mirrored and read only during startup we can accommodate for that. I wonder if it would still work when we would set it as recommended preference for automation very early during startup - this would be helpful so that not each and every WebDriver client would have to set this preference but we have it centralized in Firefox itself. In our case we set those prefs before the final-ui-startup which means that no window is loaded yet. Maybe this should work.
To check that only add the new pref to the list of recommended prefs and start Firefox with --marionette or --remote-debugging-port. They will enable Marionette or the Remote Agent (for WebDriver BiDi respectively). Then check if any new tab feature has been initialized or not.
|
|
Assignee | |
Comment 13•6 months ago
|
||
I think yeah as long as it's set before newtab start to initialize, it should work.
Also assuming there isn't a race condition.
|
|
Reporter | |
Comment 14•6 months ago
|
||
Perfect. Do you maybe have a rough idea of when this might could get implemented?
|
|
Assignee | |
Comment 15•6 months ago
|
||
Not sure, it's not a priority but I was going to try to sneak it in when I get a chance.
|
||
Updated•6 months ago
|
|
|
||
Updated•6 months ago
|
|
||
Updated•6 months ago
|
|
|
Reporter | |
Comment 16•2 months ago
|
||
(In reply to Scott [:thecount] Downe from comment #15)
Not sure, it's not a priority but I was going to try to sneak it in when I get a chance.
Hi Scott, any chance that someone could have a look at this bug if you cannot find time for it? We would appreciate. Thanks.
|
|
Assignee | |
Comment 17•1 month ago
|
||
I'm going to take another chance at trying to sneak this in this week.
|
|
Assignee | |
Comment 18•1 month ago
|
||
|
||
Comment 19•1 month ago
|
||
|
|
||
Comment 20•1 month ago
|
||
|
||
Comment 21•1 month ago
|
||
|
|
||
Comment 22•1 month ago
|
||
|
||
Comment 23•1 month ago
|
||
| bugherder | ||
Description
•