Reinstate a Custom URL setting for New Tab

NEW
Unassigned

Status

()

enhancement
P3
normal
a year ago
19 days ago

People

(Reporter: abenson, Unassigned)

Tracking

(Blocks 1 bug, {uiwanted})

60 Branch
Points:
---

Firefox Tracking Flags

(firefox60 wontfix, firefox61 wontfix)

Details

(Reporter)

Description

a year ago
Some needed context in 1417155 and 1118285.

Within the new Home section in Preferences (spec details: https://mozilla.invisionapp.com/share/65FPNL9RH4V), there is the ability to set a New Window / Home page to a custom URL but you cannot set your New Tab to a custom URL (see above issues as to why).

The concerns raised above are understandable however the resulting user experience suffers as a result. A person would understandably be confused about why one surface can have a custom URL applied to it while the other cannot. 

We should investigate a way to securely and safely save custom URL preferences and reinstate this functionality as part of the new preferences page. I'm pinging some folks in the related issues to start a conversation. Please pass along to others that might need to know or that can help.
(Reporter)

Updated

a year ago
Flags: needinfo?(florian)
Flags: needinfo?(dveditz)

Comment 1

a year ago
It looks like part of the reason it was more dangerous before was that the user would get "stuck" and not know how to fix things as the easiest way was via about:config. If there was this about:preferences UI, that would maybe help users realize their new tab page is set to something else and have a way to change it.

Although even with a UI, keeping it as a pref (or any plain storage ?) still means another application can just constantly overwrite any user value. Although storing the data slightly differently could make it a little bit harder to reduce some abuse. ?
about:config used to not be enough to de-hijack the new tab page. The pref was abused in at least 2 ways:
- overwriting the prefs.js file in the profile when Firefox was not running
- injecting a DLL into our Firefox process and using the XPCOM binary APIs to register a pref observer, which was used to set the value of the pref again to the hijacked value whenever the user changed the value from about:config.

At this point I think our binary XPCOM APIs are gone, so the main concern that remains is third party software writing directly to the preferences file. I think a reasonable way to mitigate this would be to save a verification hash along with the pref containing the url, to ensure the pref value has been written by Firefox. This is what the search service does when saving search settings (that are very tempting to hijack). See https://searchfox.org/mozilla-central/rev/7ccb618f45a1398e31a086a009f87c8fd3a790b6/toolkit/components/search/nsSearchService.js#770-775

Such a measure should also be applied to storing the homepage URL, see bug 1051082.
Flags: needinfo?(florian)
Severity: normal → enhancement
Flags: needinfo?(dveditz)
We constantly get requests to add a WebExtensions API to override the new tab page with a custom URL. To date, we have chosen not to implement it for all of the reasons listed here and indirectly in comment 0. This has led to extensions using ugly, not-user-friendly workaround that trap new tab creation. Nothing malicious, but it leads to a bad user experience.

It feels like if the product supports it in a native and secure manner, then exposing that via WebExtensions makes more sense. Native Firefox users are happier, and developers don't have to resort to hacks, so extension users are also happier (which makes me happier).

Tim, I'm not sure where this falls in your list of priorities, but I can safely say that there would be huge demand from an extension developer point-of-view.
Flags: needinfo?(tspurway)
Blocks: 1460412
I don't know that I can add much to the existing discussion, other than to say that if UX (and end-users) want this feature, and Engineering can enable safely and sanely without opening new doors to hijackers, then, by all means, let's do this.

Another thing to consider is bug 1401194, which enables an API so that developers can add a new section to Activity Stream as a Web Extension.  The idea here is to give a more integrated mode of customization.  We suspect that many use cases that replace the newtab page entirely will be better served by a finer grained mechanism like this.
Flags: needinfo?(tspurway)

Updated

10 months ago
See Also: → 1266837

Updated

9 months ago
Duplicate of this bug: 1476043
Comment hidden (off-topic)
Comment hidden (spam)

Comment 8

6 months ago
This nuisance (that there's no programmatic way to select/clear/set the text in the URL bar) stands in the way of usability of this featured extension: https://github.com/cadeyrn/newtaboverride/issues/24#issuecomment-436997741
You need to log in before you can comment on or make changes to this bug.