Closed Bug 1950457 Opened 8 months ago Closed 7 months ago

Theme breaks when using autoconfig to set newTabURL

Categories

(Firefox :: New Tab Page, defect)

Firefox 135
defect

Tracking

()

RESOLVED INVALID

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).

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.

Component: Untriaged → Tabbed Browser

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.

Status: UNCONFIRMED → RESOLVED
Closed: 7 months ago
Resolution: --- → INVALID
Component: Tabbed Browser → New Tab Page

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?

Flags: needinfo?(mconley)

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.

Flags: needinfo?(mconley)

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.

Duplicate of this bug: 1952142
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: