Blank new tab page after browser.newtabpage.enabled is turned off and back on
Categories
(Firefox :: Tabbed Browser, defect)
Tracking
()
People
(Reporter: florian, Unassigned)
References
(Blocks 1 open bug)
Details
NewTabPagePreloading observes none of the three prefs its own enabled getter reads, so it never discards a preload those prefs have invalidated. about:newtab resolves to chrome://browser/content/blanktab.html while browser.newtabpage.enabled is false, and AboutNewTabRedirector reads that pref when it opens the channel rather than when loadURI is called, so a preload issued before the pref went false comes back blank. While the pref stays false getPreloadedBrowser early-returns, so the blank browser is neither consumed nor dropped; when the pref goes back to true it is served to the next new tab.
The cost is one blank new tab page, and reloading it fixes it. The pref is a visible setting -- New Tabs, in about:preferences#home -- and is written by Sync, so nothing about this needs a test harness, but in the browser the flip has to land inside the load window. In CI it is reliable: browser_enabled_newtabpage.js flips the pref while a preload is in flight and leaves the blank browser for the next test in the newtab browser-chrome manifest to consume, which is one cause of bug 1970996.
defineLazyPreferenceGetter takes an onUpdate callback, so discard preloadedBrowser across BrowserWindowTracker.orderedWindows when an input changes, with the ungated take factored out of getPreloadedBrowser, which today early-returns exactly when the discard is needed. Enterprise policy cannot reach this: it locks the pref before any window exists.
Description
•