Theme breaks when using autoconfig to set newTabURL
Categories
(Firefox :: New Tab Page, defect)
Tracking
()
People
(Reporter: arbitrarytrajectory, Unassigned)
References
Details
Attachments
(2 files)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:135.0) Gecko/20100101 Firefox/135.0
Steps to reproduce:
I use a barebones html file as a homepage and use the following autoconfig code to set it as the new tab URL.
autoconfig.js
// IMPORTANT: first line is a comment
pref("general.config.filename", "autoconfig.cfg");
pref("general.config.obscure_value", 0);
pref("general.config.sandbox_enabled", false);
autoconfig.cfg
// IMPORTANT: first line is a comment
var { utils:Cu } = Components;
try {
Cu.import("resource:///modules/AboutNewTab.jsm");
var newTabURL = "/home/[user]/Documents/Computer/Firefox config/homepage.html";
} catch(e){Cu.reportError(e);} // report errors in the Browser Console
Actual results:
New tabs open the homepage file as expected, but my Firefox theme is broken in new windows (see attached screenshots). The bookmarks toolbar is also visible in new windows despite being set to "Only Show on New Tab".
When the autoconfig file is active, the following errors appears in the browser console upon opening a new window:
Uncaught NS_ERROR_MALFORMED_URI: Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIIOService.newURI]
_newTabURI chrome://browser/content/browser-places.js:1451
isOnNewTabPage chrome://browser/content/browser-places.js:1444
isOnNewTabPage chrome://browser/content/browser-places.js:1443
setToolbarVisibility chrome://browser/content/browser.js:4613
updateBookmarkToolbarVisibility chrome://browser/content/browser.js:760
onBeforeInitialXULLayout chrome://browser/content/browser-init.js:72
browser-places.js:1451
NS_ERROR_MALFORMED_URI: Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIIOService.newURI]
_newTabURI chrome://browser/content/browser-places.js:1451
isOnNewTabPage chrome://browser/content/browser-places.js:1444
isOnNewTabPage chrome://browser/content/browser-places.js:1443
setToolbarVisibility chrome://browser/content/browser.js:4613
updateBookmarkToolbarVisibility chrome://browser/content/browser.js:760
onLocationChange chrome://browser/content/browser.js:3364
callListeners chrome://browser/content/tabbrowser/tabbrowser.js:1009
_callProgressListeners chrome://browser/content/tabbrowser/tabbrowser.js:1023
_callProgressListeners chrome://browser/content/tabbrowser/tabbrowser.js:7256
onLocationChange chrome://browser/content/tabbrowser/tabbrowser.js:7731
tabbrowser.js:1014:23
and upon opening a new tab:
NS_ERROR_MALFORMED_URI: Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIIOService.newURI]
_newTabURI chrome://browser/content/browser-places.js:1451
isOnNewTabPage chrome://browser/content/browser-places.js:1444
isOnNewTabPage chrome://browser/content/browser-places.js:1443
setToolbarVisibility chrome://browser/content/browser.js:4613
updateBookmarkToolbarVisibility chrome://browser/content/browser.js:760
onLocationChange chrome://browser/content/browser.js:3364
callListeners chrome://browser/content/tabbrowser/tabbrowser.js:1009
_callProgressListeners chrome://browser/content/tabbrowser/tabbrowser.js:1023
updateCurrentBrowser chrome://browser/content/tabbrowser/tabbrowser.js:1266
_setupEventListeners chrome://browser/content/tabbrowser/tabbrowser.js:6688
set selectedIndex chrome://global/content/elements/tabbox.js:235
set selectedPanel chrome://global/content/elements/tabbox.js:245
set selectedIndex chrome://global/content/elements/tabbox.js:555
set selectedItem chrome://global/content/elements/tabbox.js:579
set selectedTab chrome://global/content/elements/tabbox.js:83
set selectedTab chrome://browser/content/tabbrowser/tabbrowser.js:427
addTab chrome://browser/content/tabbrowser/tabbrowser.js:2896
openLinkIn resource:///modules/URILoadingHelper.sys.mjs:569
openTrustedLinkIn resource:///modules/URILoadingHelper.sys.mjs:729
openTrustedLinkIn chrome://browser/content/utilityOverlay.js:111
wrappedJSObject chrome://browser/content/browser-commands.js:347
openTab chrome://browser/content/browser-commands.js:333
<anonymous> chrome://browser/content/browser-sets.js:25
tabbrowser.js:1014:23
NS_ERROR_MALFORMED_URI: Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIIOService.newURI]
_newTabURI chrome://browser/content/browser-places.js:1451
isOnNewTabPage chrome://browser/content/browser-places.js:1444
isOnNewTabPage chrome://browser/content/browser-places.js:1443
setToolbarVisibility chrome://browser/content/browser.js:4613
updateBookmarkToolbarVisibility chrome://browser/content/browser.js:760
onLocationChange chrome://browser/content/browser.js:3364
callListeners chrome://browser/content/tabbrowser/tabbrowser.js:1009
_callProgressListeners chrome://browser/content/tabbrowser/tabbrowser.js:1023
_callProgressListeners chrome://browser/content/tabbrowser/tabbrowser.js:7256
onLocationChange chrome://browser/content/tabbrowser/tabbrowser.js:7731
tabbrowser.js:1014:23
I'm able to reproduce this on a new profile.
Expected results:
The autoconfig code should overwrite the new tab URL without affecting the theme or causing errors. The same code behaved without issue as of Firefox 115 esr on my old computer (macOS if that's relevant).
| Reporter | ||
Comment 1•8 months ago
|
||
| Reporter | ||
Comment 2•8 months ago
|
||
Comment 3•8 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Tabbed Browser' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 4•7 months ago
|
||
Hi arbitrarytrajectory,
Your customization script is a bit out of date. To be clear, we don't explicitly support updating New Tab to a custom URL using the mechanism that you're using (there is, however, a WebExtension API to do it that we recommend instead - see "newtab" in this table).
However, if you still want to use the unsupported way, this script might work (I've not tested this myself):
// IMPORTANT: first line is a comment
var { utils:Cu } = Components;
try {
const { AboutNewTab } = Cu.importESModule("resource:///modules/AboutNewTab.sys.mjs");
AboutNewTab.newTabURL = "/home/[user]/Documents/Computer/Firefox config/homepage.html";
} catch(e){Cu.reportError(e);} // report errors in the Browser Console
Closing this bug as INVALID, as what broke here is an unsupported approach to setting the default New Tab page.
Updated•7 months ago
|
| Reporter | ||
Comment 5•7 months ago
|
||
Mike, thanks for the explanation and suggested changes. Fingers crossed that version works without issues.
I'd certainly rather use a supported method for this. Unfortunately all of the approaches I'm aware of have severe drawbacks that make them infeasible for my use case. chrome_url_overrides is one I haven't seen before, but seems to have the same problems as other extension-based solutions, most crucially that it only supports local files bundled with the extension. Not very convenient if minor edits to my homepage require an extension update!
Maybe what I ought to do is try to start a new conversation on why the user can't set a new tab URL directly. Quick question as I'm not well-versed in the etiquette here. The most relevant discussion (bug 1452144) was marked wontfix and stagnated many years ago, but is still marked open. Do old bugs ever get wontfix removed after reconsideration, or would it be more appropriate to open a new bug?
Comment 6•7 months ago
|
||
Maybe what I ought to do is try to start a new conversation on why the user can't set a new tab URL directly.
The New Tab URL used to be stored in a preference. The problem that we had to deal with was malware overwriting that preference to hijack the new tab experience. It was trivial for malware to find the Firefox profile directories, and for each user profile, overwrite the new tab URL with something nefarious. We wanted users to be able to set custom new tab URLs, but needed to avoid this hijacking scenario. The solution was to introduce the WebExtension API to allow the override at runtime. The signing requirements for extensions add a much, much higher barrier for malware to attempt to override the new tab URL.
Do old bugs ever get wontfix removed after reconsideration, or would it be more appropriate to open a new bug?
Old bugs sometimes stagnate, or they might get WONTFIX'd. If that one is still open, you're welcome to add your commentary, but I'm quite certain we'll not be revisiting this decision anytime soon, for the security/reliability reasons stated above.
| Reporter | ||
Comment 7•7 months ago
|
||
Yes, I gathered all that from the linked bug, and while I want to revisit that decision it certainly shouldn't be carelessly reverted. The issue is that the homepage is still stored in a preference, implying that either a significant vulnerability has gone ignored for 11 years or that greater new tab flexibility would be low risk.
I'll write up a deeper analysis of the concerns raised and possible solutions elsewhere.
Description
•