Reinstate a Custom URL setting for New Tab
Categories
(Firefox :: New Tab Page, enhancement, P3)
Tracking
()
People
(Reporter: abenson, Unassigned, NeedInfo)
References
(Blocks 1 open bug)
Details
(Keywords: uiwanted)
Reporter | ||
Updated•7 years ago
|
Comment 1•7 years ago
|
||
Comment 2•7 years ago
|
||
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Comment 3•7 years ago
|
||
Comment 4•7 years ago
|
||
Comment hidden (off-topic) |
Comment 8•7 years ago
|
||
Comment hidden (off-topic) |
Comment hidden (off-topic) |
Assignee | ||
Updated•6 years ago
|
Comment 13•4 years ago
|
||
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.
Comment 14•3 years ago
|
||
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.
Comment 15•3 years ago
|
||
I finally wrote a an add-on for this enhancement.
Comment 16•3 years ago
|
||
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.
Comment 17•3 years ago
|
||
This (unfortunately closed) enhancement request is blocking having a better UX for new tab extensions, but the ones mentioned above are better than nothing.
Updated•3 years ago
|
Comment 18•4 months ago
|
||
Reading through the related bugs again, I'm struck by how few obstacles remain in the way of this change. This proposal has waited long enough that many of the concerns raised simply no longer apply, so we should get the ball rolling before new obstacles appear.
To summarize the other threads, the malware concerns around the old pref fell into two categories: specific vulnerabilities and user knowledge. The vulnerabilities have already been discussed in this thread. The user concerns focused on (lack of) awareness of homepage vs new tabs and the distinct pre-Activity Stream default pages. With the pref absent from about:preferences, users might be less likely to notice malicious changes, especially users who rarely used new tabs.
At present the default home and new tab pages have been unified, the associated prefs are now in about:preferences, and per comment 2 XPCOM pref hijacking is no longer possible. The only remaining obstacle is the prefs.js
vulnerability... which is shared by not-removed browser.startup.homepage
! And given that's gone unaddressed for eleven years I can only assume it's not a significant security issue.
So, possible solutions. A few come to mind:
- Reinstate the new tab URL pref more or less as it was, just visible in about:preferences this time.
- Add a "same as homepage" option to the new tab setting, allowing use of the same custom URL for both homepage and new tab.
- Allow setting a new tab URL via policies, as can be done for the homepage.
- Reinstate the new tab URL pref and finally secure both it and the homepage pref.
I'm inclined towards #2. Avoids re-adding the original vulnerability, relatively minor change, should satisfy most power users. If someone more official approves it I'd be happy to implement this.
Comment 19•4 months ago
|
||
Florian, as the one here involved in removing the original pref, do you know who would be appropriate to make this decision?
Description
•