1460412 - API to set the new tab page URL

Status: NEW

(WebExtensions :: Frontend, enhancement, P3)

Description

[Mike Conca [:mconca]]

The platform team is considering adding back the capability to set the New Tab page to a user specified URL. If/when that happens, a method to allow extensions to set that value should exposed via the WebExtensions API. 

This would allow extension developers to support user-defined URL's as the new tab page in a secure manner, avoiding the tabs.update() method many of them use now (and which lead to less-than-ideal user experiences).  It also allows users to see which extension is controlling their URL-new-tab, and take back control if desired, via the infrastructure already in place to support chrome_url_overrides.

Comment 1

[Mark Striemer [:mstriemer]]

Would we be clearing and focusing the address bar in this case? That seems like a bad idea for remote content so I'm not sure there'd be much benefit to an extension author without that. I would think users may as well set the URL themselves in that case.

Comment 2

[Mark Striemer [:mstriemer]]

Attachment: placeholder.png

I guess something quick might be to set the placeholder to the New Tab URL in this case. Something like the attached screenshot. A long URL would be spoofable here and the identity block is hidden in search mode, however.

Comment 3

[Mike Conca [:mconca]]

I see what you are saying, Mark, and I'd be curious if comment 1 has been addressed in the parent bug.  Because for WebExtensions, I'm leaning on the front-end team to "do the right thing" for user security and privacy.  That is, assuming that team comes up with a UX and prefs strategy that Mozilla and Firefox are comfortable with, WebExtensions will simply expose setting the new tab URL programmatically instead of being set by the user in about:prefs.

Comment 4

[azhao]

what about adding a configuration option to set the new tab url instead of adding an API?  It seems like that would cover most of the use cases with much less complexity.

Comment 5

[tmijul1]

This is still a problem. When you click to open a new tab, you instinctively begin to type your search terms. However, as soon as you press keys, nothing at all happens.

Comparatively, Chrome opens new tabs with a blank address bar without a problem. Even Internet Edge, of all browsers, at least pre-selects the text in the address bar so that it is overwritten when you start typing.

I have been using FireFox for well over a decade, since version 1.7 back in 2004. Ideally I would like to continue to use FF, as it was the most user-oriented and web developer-centric browser I felt most at home with. Unfortunately, lately its becoming more apparent that relevant alternative browsers exist that still offer features that FireFox no longer will.

Comment 6

[Mark Striemer [:mstriemer]]

How do you have your New Tab configured? I don't see how you would be running into this. Perhaps it's a bug?

Are you using an extension to redirect new tabs to a remote URL? If that's the case I think bug 1452144 is what you're looking for. Doing that with an extension isn't supported yet and I didn't see a way to do it in Chrome either.

Comment 7

[Kevin]

Firefox team, I'd love to help move this conversation/feature forward. Is there a way I can be helpful?

The current options are still subpar for new tab extensions: we either have to iframe the remote content or interrupt the user's typing. Either option leads to bugs, limitations, or user complaints.

Comment 8

[gaveitatry]

Dear God, I can't believe that this issue has been going on for about two years now. I would have switched from 56.0.2 to Firefox Quantum ages ago, if there weren't so many problems with the newer version. I'm attempting to make the switch again, but there is just so much about Firefox Quantum that has regressed. I had to install Linux on my computer for the first time in my entire life in hopes that I can edit the Firefox shortcut keys so I can do things like press F2 for the Bookmarks Sidebar, F3 for the Downloads window, etc. Why are you trying to take something so wonderful and make it unusable?

Anyway, so there is this blah blah talk about how it is okay to remove instinctive and necessary functionality (auto focus in URL bar) because of some security concerns that are so unlikely and uncommon (that some malicious add on developer will use the auto focus to inject a new URL or to record what you type?), but as others have pointed out there are more likely security scenarios that would be potentially more dangerous such as addons letting you inject javascript into pages. So really, it is braindead logic that these developers are using. But I will propose a solution. Whenever we bookmark a page in Firefox Quantum, it brings up a blue alert popup window that says Saved to Library! It's so hard to miss because the blue is so dark and the text is so white. Among other things, like cool placement and animations, etc. So why not just have something like that for add-ons that give you the option to auto focus in a URL bar? Have it trigger an official Firefox Quantum window popup in similar styling that tells you that you are focused in the URL bar. If the user didn't intend to focus in the URL bar, or if they change their mind, the alert will let them know they should click somewhere in the page before typing. Wouldn't this situation give all parties involved a good compromise? Millions of users can go back to instinctively typing in the URL bar after opening a custom new Tab (and only because they purposely installed that addon to do that), and the few malicious webextension developers who try to do something sneaky with their addons won't be able to be as sneaky because of the blue Firefox window popup alerts.

I just want some peace of mind, and I'm tired of small steps forward and billions of steps backwards. Give us the degree of functionality we deserve to make utilization easy and painless instead of tedious and aggravating. Grant us the enjoyment that millions of other users in older version of Firefox, Internet Explorer, Google Chrome, Microsoft Edge, and God knows how many other browsers out there LET US HAVE (auto focus in URL bar). Stop overthinking things and hurting your users, and start making some progress instead of regressing a billion steps.

Comment 9

[MemphiZ]

If there would be an option to upvote comments here, this comment would have a billion likes IMHO.
I myself was trying to move the conversation forward when it was still #1409675. If it takes more than 2 years to fix a simple but very annoying bug like this, I can fully understand people leaving the browser. What I can't understand is that the devs are ok with this. The last sentence from gaveitatry sums up my feelings as well: "Stop overthinking things and hurting your users, and start making some progress instead of regressing a billion steps.", except for me its too late. I won't coming back from Brave anymore. Good Luck!
(In reply to gaveitatry from comment #8)

Dear God, I can't believe that this issue has been going on for about two years now. I would have switched from 56.0.2 to Firefox Quantum ages ago, if there weren't so many problems with the newer version. I'm attempting to make the switch again, but there is just so much about Firefox Quantum that has regressed. I had to install Linux on my computer for the first time in my entire life in hopes that I can edit the Firefox shortcut keys so I can do things like press F2 for the Bookmarks Sidebar, F3 for the Downloads window, etc. Why are you trying to take something so wonderful and make it unusable?

Anyway, so there is this blah blah talk about how it is okay to remove instinctive and necessary functionality (auto focus in URL bar) because of some security concerns that are so unlikely and uncommon (that some malicious add on developer will use the auto focus to inject a new URL or to record what you type?), but as others have pointed out there are more likely security scenarios that would be potentially more dangerous such as addons letting you inject javascript into pages. So really, it is braindead logic that these developers are using. But I will propose a solution. Whenever we bookmark a page in Firefox Quantum, it brings up a blue alert popup window that says Saved to Library! It's so hard to miss because the blue is so dark and the text is so white. Among other things, like cool placement and animations, etc. So why not just have something like that for add-ons that give you the option to auto focus in a URL bar? Have it trigger an official Firefox Quantum window popup in similar styling that tells you that you are focused in the URL bar. If the user didn't intend to focus in the URL bar, or if they change their mind, the alert will let them know they should click somewhere in the page before typing. Wouldn't this situation give all parties involved a good compromise? Millions of users can go back to instinctively typing in the URL bar after opening a custom new Tab (and only because they purposely installed that addon to do that), and the few malicious webextension developers who try to do something sneaky with their addons won't be able to be as sneaky because of the blue Firefox window popup alerts.

I just want some peace of mind, and I'm tired of small steps forward and billions of steps backwards. Give us the degree of functionality we deserve to make utilization easy and painless instead of tedious and aggravating. Grant us the enjoyment that millions of other users in older version of Firefox, Internet Explorer, Google Chrome, Microsoft Edge, and God knows how many other browsers out there LET US HAVE (auto focus in URL bar). Stop overthinking things and hurting your users, and start making some progress instead of regressing a billion steps.

Comment 10

[oscar.wittamsnangle]

The issue with this is that even back when this was #1409675, there was arbitrary worry about extensions redirecting users to pages, which isn't really a thing that can happen. Selecting some text is different to selecting some text, then deleting it, then putting in some new text.

Comment 11

[jeremy]

I have seen several things in my search through this bug and related bugs:

1. Firefox removed the ability to load a custom url into a new tab. The reason for this I believe was to reduce a reliance on external pages for an action that should be "fast".
2. The community countered this by adding a number of extensions that add back in the ability to provide a custom url for a new tab.
3. However, there exists a discrepancy between the native functionality and the extension functionality. That is, with extension functionality, a user can not open a new tab and immediately start typing in the Awesomebar.

This is the problem in a nut shell. Some users of Firefox want the ability to:

1. Open a tab and have it land on their own custom url.
2. Immediately start typing into the Awesomebar upon opening a new tab.

That's the problem. Extension providers are trying to implement this functionality but have been blocked.
(see: https://bugzilla.mozilla.org/show_bug.cgi?id=1409675)

Until Firefox provides a native solution, the easiest course of action is for users using a custom extension is to use <kbd>Ctrl</kbd> + <kbd>T</kbd> followed immediately by <kbd>Ctrl</kbd> + <kbd>L</kbd> to focus the Awesomebar.

Comment 12

[Twisted_Code]

(In reply to Kevin from comment #7)

Firefox team, I'd love to help move this conversation/feature forward. Is there a way I can be helpful?

The current options are still subpar for new tab extensions: we either have to iframe the remote content or interrupt the user's typing. Either option leads to bugs, limitations, or user complaints.

I'd like to see this change implemented as well. A newtab plug-in I've been using lately tends to break when Strict Tracking Protection is enabled because of how Iframes work. I can access the page they are trying to insert via iframe just fine (at least if I disable tracking protection for the page), but the new tab doesn't work the same way and disabling tracking protection seemingly does nothing. For the example in question, see Tab for a Cause.
I even looked to see if I could work around my specific issue by editing the new tab page manually (as a few people here have mentioned) rather than programmatically, and was surprised to see that it's no longer an option, or at least not as simple as "go to settings, find the right option for setting the new tab page, and set it". Interestingly, I can still set my homepage to the page the plugin is trying to use, but that doesn't really do what I want (the newtab page won't be overridden by the custom home page).
(Please note, I am trying to be constructive here, not just offering my opinion in an "I see this too" way. I'm just not sure how I can offer my support toward a resolution other than explain the situation I came across. I'm hoping that a specific use case where the current way things are implemented leads to other bugs is sufficient to demonstrate why this ought to be changed)

Comment 13

[Josh Berry]

I have one more use-case for this feature that I don't think has been mentioned: optionally allowing users to set a moz-extension:// page as their new tab page.

More specifically, I am the developer of Tab Stash, an extension which offers both a sidebar and tab-based UI for saving and managing tabs. I've received a feature request asking to use the Tab Stash UI as the default "New Tab" page. But I can't offer this option without forcing it on my entire user base (since there is no way to disable a new-tab page set in manifest.json without disabling the entire extension).

Right now, there is no workaround at all for users to opt-in to Tab Stash (or any other extension) as their new-tab page. The most common method of setting a user-defined new-tab URL, the "New Tab Override" extension, doesn't work because New Tab Override cannot navigate to moz-extension:// URLs for other extensions.

Ideally, I would like to use the proposed API to set the new-tab URL on an opt-in basis--for example, a user could go to the Tab Stash settings and click a checkbox or button to "Set Tab Stash as my New Tab page", and then I would call the API accordingly to set or clear the appropriate moz-extension:// URL.

Comment 14

[Kevin]

The increasing restrictions on third-party cookies make this issue more urgent. Currently, some new tab extensions iframe their HTTPS page within the moz-extension:// new tab page as a workaround to ensure the address bar is cleared for typing. However, we obviously can't expect iframed pages to work as they do when they're the top frame, even when the extension and HTTPS page are owned by the same developer.

In this case, we're left with the option of overriding with a filled address bar (unworkable UX).

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:mixedpuppy, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 16

[imbacen]

Is there a bug that tracks simply configuring a custom page on new tab to be brought back as a core feature? I don't want to install some random unvetted extension just to achieve this, even if the API supported it, that is in itself dangerous.. in fact, it is probably more likely I would get compromised installing such an extension on Linux/MacOS than getting owned by some random malware that would switch it on me.

All I want is to open a local custom page like file:///home/me/new_tab.html which has everything set up as I want it. Other than that, it should behave exactly the same as default firefox page (url bar gets cleared and focused).

The malware aspect shouldn't be a reason to block useful features like this. Hide the config change behind the master password or something.