Open Bug 1452144 Opened 6 years ago Updated 2 years ago

Reinstate a Custom URL setting for New Tab

Categories

(Firefox :: New Tab Page, enhancement, P3)

60 Branch
enhancement

Tracking

()

Tracking Status
firefox60 --- wontfix
firefox61 --- wontfix

People

(Reporter: abenson, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: uiwanted)

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.
Flags: needinfo?(florian)
Flags: needinfo?(dveditz)
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)
See Also: → 1266837
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
Component: Activity Streams: Newtab → New Tab Page

I agree this feature is very much needed. Here's another very similar feature request:

https://bugzilla.mozilla.org/show_bug.cgi?id=1266837

Either this feature or the one I linked would be a very much needed in Firefox. Both do basically the same thing.

A question regarding security concerns: I currently use this autoconfig method to set a local file as my new tab page. If an attacker could theoretically modify the newtab URL via prefs.js, can't they theoretically modify it via this method as well? Why is a preference considered too insecure while this method is not? I would think having a clearly-visible preference is preferable to such obscure options; at minimum a hijacked user could see their preference was modified.

I hope that this feature is reimplemented, or if it truly must be relegated to an extension, that Mozilla publishes an official extension for the purpose. Users shouldn't need to rely on third-party extensions for core features.

I finally wrote a an add-on for this enhancement.

https://addons.mozilla.org/en-US/firefox/addon/newtabplus/

I finally wrote a an add-on for this enhancement.

There are already several add-ons for this purpose, for example https://addons.mozilla.org/en-US/firefox/addon/new-tab-override/. It was the first add-on with this functionality after the feature was removed in Firefox 41, it has more options, it is easier to set-up, it is available in more languages and it is "recommended" by Mozilla. Disclaimer: I am the developer of that add-on.

By the way: Your add-on has a bug. If you save an empty value as new tab URL you will get an infinity loop where tabs open and immediately close forever, making Firefox unsuable until you fix the setting via about:addons.

This (unfortunately closed) enhancement request is blocking having a better UX for new tab extensions, but the ones mentioned above are better than nothing.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.