Proposal: expose the new tab URL

[NV]

Even among Chromium browsers, the URL of a blank tab isn't consistent:

Chrome, Brave: chrome://newtab/ Edge: edge://newtab/

I propose to add:

chrome.tabs.BLANK_TAB_URL = "chrome://newtab/"

I'm also fine naming it "NEW_TAB_URL".

---

My extension auto-archives old tabs. There's no point in archiving blank tabs, so I need to separate them from the rest. Currently, I need to hardcode blank tab URLs for each browser.

[hanguokai]

(BTW: Blank URL is about:blank. All browsers support it and are consistent.)

Interesting question. New Tab URL is indeed inconsistent, which is a browser specific URL. And it is a fake URL, for example, browser.tabs.query() return "chrome://newtab/", but location.href is "chrome://new-tab-page/" or "chrome-extension://ext-id/newtab.html".

It would be helpful if there was a consistent way to judge these URLs.

[hanguokai]

Some additional common URLs.

	Chrome	Firefox	Safari
New Tab	chrome://newtab/ edge://newtab/	about:newtab	favorites:// topsites:// (Legacy)
Homepage	No URL	No URL	No URL
Default homepage	No URL	about:home	No URL
Extensions management	chrome://extensions/	about:addons	No URL (In browser settings)
Extensions shortcuts	chrome://extensions/shortcuts (for all)	No independent URL (In about:addons)	—
Extensions details	chrome://extensions/?id=ext-id	No independent URL (In about:addons)	No URL (In browser settings)
Browser history	chrome://history/	No URL (In a independent window)	history://
Browser bookmarks	chrome://bookmarks/	No URL (In a independent window)	bookmarks://
Browser settings	chrome://settings/	about:preferences	No URL (In a independent window)

Different browsers may have significant differences. But extensions sometimes need to guide users to adjust certain settings, such as setting shortcuts, run in incognito mode, site permissions, allow access file URL, etc. In these cases, developers can only write user guide separately.

[carlosjeurissen]

A common usecase for extensions is when opening new tabs. If the user is already on the new tab page, it does not always make sense to open another tab, but to just replace the new tab page.

[xeenon]

I added Safari's values to @hanguokai's table above.

[tophf]

In Opera it's chrome://startpageshared/. In Vivaldi it's chrome://vivaldi-webui/startpage. There may be more browsers around with an unusual newtab URL.

[carlosjeurissen]

Considering there are so many alternatives, and potentially also extension URLs used as new tab page. Would it not make sense to introduce a boolean typed isNewTab property on tabs.Tab? This way an extension can, independently what the new tab page might be, determine if it is the new tab page or not. Would this not be more useful than adding something like browser.tabs.BLANK_TAB_URL?

[hanguokai]

Before proposing a solution, we first need to collect and determine what users(developers) needs are. For example,

• Determine whether a tab is a new tab page, or a bookmark page.
• Open the extension management page, or open this extension details page or shortcuts page.
• Open browser history, download or settings page.

Welcome to add your needs.

[hanguokai]

(I don't know if the browser is willing to support it, I'm putting this issue here)

Another common hardcoded URL is the product page (especially the writing review link) of the extension store. Developers have recently discussed this issue. The link needs to be modified to a specific store link before each release. A simple solution is adding a openStoreReviews() method, and supporting feature detect.

Considering all the common URLs listed above, and the different implementations of different browsers, we should design a flexible API.

[carlosjeurissen]

@hanguokai while I see value in further exploring handling any kind of special page and / or URL and how extensions interact with them across browsers, the original issue was about figuring out if a certain tab is a new tab page or not.

This use case for tab archive extensions and for the use case I described, being able as developer to figure out if the current tab is a new tab page so it can overwrite it, if not, open a new tab. For both use cases, the proposed solution, exposing isNewTab on tabs.Tab seems to pretty much cover the use cases described in this issue.

A few benefits:

• easy to align and agree across browsers
• privacy friendly (the new tab page URL does not need to be exposed to an extension)
• other boolean metadata properties already exist (isArticle, isInReaderMode)

[hanguokai]

@carlosjeurissen Don't worry, we are all just expressing our ideas, and we don't have the final say.

[hanguokai]

@carlosjeurissen Do you suggest open a new issue for a general solution?

[carlosjeurissen]

@carlosjeurissen Do you suggest open a new issue for a general solution?

@hanguokai yeah, I think this makes sense. The current issue is more about detecting if you are on a new tab page, while some of the use cases you are describing are more about being able to open special pages. The ability to open the management page and keyboard shortcuts page of the extension would be very useful. Opening the reviews page might be a bit more tricky as there is no 1:1 connection with stores and browsers. In addition, an extension could be installed without being on a store.

[hanguokai]

I will open a new issue.

For tabs.Tab.isNewTab, personally I think this is a bad design. Browsers needs to add a new property for every Tab instance. And add more properties like Tab.isBookmarks, Tab.isDownloads, Tab.isHistory in the future. Because there are many special pages.

[dotproto]

I took the liberty of adding the user's current and the browser's default homepage to the table in @hanguokai's comment.

[tophf]

More ideas:

1. extend chrome.tabs.query with property ui that can be a string like 'newtab' or 'history' and so on.
2. expose this ui property in the Tab object.

The benefit is that there'll be no need to request the tabs permission to see the URL of a tab.

[carlosjeurissen]

I took the liberty of adding the user's current and the browser's default homepage to the table in @hanguokai's comment.

Can you potentially add this to https://github.com/w3c/webextensions/issues/473 as well? Edit: nvm, has been added already

[hanguokai]

Can you potentially add this to https://github.com/w3c/webextensions/issues/473 as well?

You overlooked something? He already updated the table in two issues at the same time two days ago.

[carlosjeurissen]

You overlooked something? He already updated the table in two issues at the same time two days ago.

Assumed it was only updated here. Thanks for noting!

[Rob--W]

Added https://github.com/w3c/webextensions/labels/opposed%3A%20firefox ; copied from the meeting notes (see minutes for full discussion, including perspectives from others).

• [rob] I'm opposed to the suggestion for the described use case. The new tab URL is not static, and there is not only one. Can be overridden by extensions, and can be different between private and non-private browsing. For the use case a way to query whether the tab should be archivable would be more useful.