Allow optional overriding default newtab/bookmarks/history pages

[hanguokai]

https://developer.chrome.com/docs/extensions/mv3/override/

Chrome allows developers to override browser's default new tab, bookmarks and history pages. But it is not allowed to be an optional behavior for users. Developers face A) Some users want to override default page, B) others don't want to override.

The overriding page is just a web page. For example, user can click the extension icon to open the functional page in a new tab, not override the default page to use it.

I suggest that browser supply a setting(checkbox), which let the user decide whether to override the default page. Developers don’t need to do anything.

[carlosjeurissen]

Seems a pattern used on Android when it comes to homescreen apps could be used. Every time a new homescreen app is installed, when you got to the homescreen, it asks the user what homescreen it wants to use.

In the case of extensions. First time you open up a new tab, bookmarks page or history page it can offers the option to switch to a different extension / the browser default. With optionally a way to change it in settings and using potentially some toggle in the addressbar.

[hanguokai]

Not only control overriding behavior, but also let users use both browser default function and extension function.

For example, I have a bookmark manager extension. It provides another style of management function. But it does not supply importing bookmarks function, because there is no api to do it. A user said:

option to avoid replacing standard chrome bookmarks manager: this would allow to keep both managing possibilities, this extension, and standard chrome

You can think of it this way: Extensions provide complementary functionality, not a replacement. Currently, if I want to supply overriding and not overriding behavior, I need to publish two same extensions, which is prohibited by the policy.

[carlosjeurissen]

Maybe I'm missing something tho seems this behavior can be covered for by opening the extensions bookmarks manager version when you click the extension icon using the browserAction / action API. If you handle this in the background page, you could even focus the already open tab if it's available.

[hanguokai]

Maybe I'm missing something tho seems this behavior can be covered for by opening the extensions bookmarks manager version when you click the extension icon using the browserAction / action API. If you handle this in the background page, you could even focus the already open tab if it's available.

The key of this issue is that the bellowing code in manifest.json is forceable, whether to add it is a dilemma. Developers can't publish two same extensions just with this difference.

  "chrome_url_overrides" : {
    "newtab": "mypage.html" // or bookmarks or history
  }

[carlosjeurissen]

The key of this issue is that the bellowing code in manifest.json is forceable, whether to add it is a dilemma. Developers can't publish two same extensions just with this difference.

  "chrome_url_overrides" : {
    "newtab": "mypage.html" // or bookmarks or history
  }

Sure. Yet when the browsers would implement the user to either override it or not, this becomes optional to the user. And you get the behavior you want. Users who want to override can choose to do so, and other users can use the extension just by clicking the icon.

[mikecann]

Apologies for chiming in this a little late but we have a fairly popular game (https://chrome.google.com/webstore/detail/battletabs/mjcklhnhfiepmofggcoegkmkokbljmjd) that works by replacing the newtab page.

When we survey our users why they uninstall, the single largest reason is that they dont want us to replace their newtab page. So, as @hanguokai has mentioned, we are in a bit of a dilemma as a lot of users like us replacing the newtab page and a lot dont but we dont have a way programmatically to disable the functionality as it is hardcoded in the manifest.

We are currently doing a "hack" where the user is given a setting that allows them to choose a new URL for us to bounce you to when our newtab.html page opens instead of displaying the game.

We default this URL to "chrome-search://local-ntp/local-ntp.html" on Chrome and "edge://newtab/" on Edge.

The problem is the users are still annoyed because they might have other extensions that are replacing the newtab but we as developers have no way of letting the user choose those instead.

Anyways, some programmatic solution to this problem would be greatly appreciated.

[hanguokai]

Thanks for raising this issue. This is a long standing but unresolved issue. Looks like it's never discussed in the regular meeting, maybe we can discuss it in the next meeting.

[hanguokai]

Add some information.

Optional Override Bowser New Tab Page

This is real users and developers' need. Currently, developers give an option(whether override NTP) to users and use a hacky way to implement it (update tab url to chrome-search://local-ntp/local-ntp.html).

Here are some links from Chromium Extension Forum

• Toggle New Tab override
• Slight Change on New Tab Page
• Optional new tab page
• New tab extension and redirect url chrome-search://local-ntp/local-ntp.html

In the past, Simeon Vincent replied:

Chrome does not support optional new tab pages in extensions. Rather, I believe that our current stance is that new tab pages are considered a single purpose for the sake of policy enforcement. As such, if you wish to provide an optional new tab page you should publish a separate extension that implements the new tab page functionality in order to give the user control over their new tab page experience.

A lot of NTP extensions face this problem. In my opinion, browsers should provide a way to do it.

Optional Override Bowser Bookmarks and History Page

This problem is simpler than NTP, because it doesn't involve single purpose. Developers could give an option to users, if users don't want to override browser's default page (for example, the default bookmark page supply import/export bookmarks function), then extensions can open extension page in a tab for users to use it.

[hanguokai]

I think this is technically outside the scope of this group's remit. The features and UX around those features are product decisions made by a given browser vendor. For the purposes of specifying a common we can discuss APIs, developer expectations, development patterns, etc., but I don't expect that any browser vendor will want to specify aspects of their program policies or store requirements. -- Simeon

This is about product experience (improving user experience), but I don't think it's against the policy. There are several possible ways to solve this problem, so I didn't come up with specific proposal details before.

Note that this demand is mainly from users, not from developers. Therefore, the choice should be left to the user, which is the responsibility of user agents.

Now, let me propose my first solution.

If the extension manifest contains "chrome_url_overrides" field, then in the UI of the extension management (e.g. users right click the extension icon or goto chrome://extensions/?id=extension-id), the browser provides users with an option like below (only show one of them, since "chrome_url_overrides" only allow one override behavior):

• Allow override newtab
• Allow override bookmarks
• Allow override history

If the user unchecks the option, the browser remove the extension's override behavior. And when the user clicks on the extension icon, the browser opens the corresponding page (forcibly) in a tab .

I think this solution:

• does not change the current policy
• developers do not need to do anything
• extensions retain their core functionality
• users gain the choice

[xeenon]

Safari does this today with New Tab Page. We prompt the user, and they can say no. The extensions are shown in the list of options for new tabs or windows.

[dotproto]

To make @xeenon's comment a little more concrete, I just went through the install flow in Safari with Momentum and saw the following prompt.

After installation, I was able to go into Safari's preferences and select which extension I wanted to use as my new tab page or my new window page (list of one in this screenshot).

Firefox also offers a similar experience, showing a similar confirmation at install time and allowing the user to control which extension is used in settings.

[dotproto]

During today's meeting someone suggested exposing an API that would allow an extension to become the currently active new tab page. This feels to me like it could be a good path to provide the kind of capability being requested without being too prescriptive about browser UI or settings management.

Briefly, what I'm currently imagining is introducing a new method that would be named something like .setNewTabPage() .setOverrideUrl(), namespace TBD. In order to help ensure that the method is only called when intended by the user, this method would require a user gesture. Browsers might also choose to present the user with a setting change confirmation in trusted UI.

[hanguokai]

For current Firefox and Safari, to use the extension's function page when the extension is not selected, the extension need to support action.onClicked event.

For overriding bookmarks or history extensions, optional overriding feature is more obvious. For example, a bookmark manager extension, users can click the extension icon or open chrome://bookmarks/ to use it. When user cancel overriding chrome://bookmarks/ (currently don't support), this extension still can be used by clicking the extension icon. So users can use this bookmark manager extension with or without overriding chrome://bookmarks/.

[dotproto]

I think we're on the same page. I agree that there's value to allowing a user to have multiple extensions installed that provide similar functionality and allowing the user to choose which one they want to use as the default. The main question from my point of view is what's the right way to specify that capability while also leaving space for browser vendors to diverge when they choose to.

Chrome kind of supports optional overriding, but it's not very obvious or easy to use. If you install two extensions that replace the bookmarks page, the most recently installed extension will be exposed at chrome://bookmarks/. The other extension will still be installed and functional, it just wont be accessible unless either the extension exposes another way to open (using your terminology) the extension's function page or if the user knows the correct URL to open.

[mikecann]

Briefly, what I'm currently imagining is introducing a new method that would be named something like .setNewTabPage() .setOverrideUrl(), namespace TBD. In order to help ensure that the method is only called when intended by the user, this method would require a user gesture. Browsers might also choose to present the user with a setting change confirmation in trusted UI.

We have been hoping for something like this for years now so super big YES to this!

Chrome kind of supports optional overriding, but it's not very obvious or easy to use. If you install two extensions that replace the bookmarks page,

Yes the order of install is important.. not exactly the most friendly thing to explain to our users however.

Thanks guys for continuing to push this forward!

[joshgpurvis]

It would also be nice if each extension could point to another extension to honor which the user picks.

Here's our current UI. We tried to find a way to point to other extension's with newTab experiences but because their uri endpoint can be custom, it's too hard. If we had a way to just point to them, that'd be so nice. I'm happy to honor the user's choice.

Better if we can detect upon installation that there's already a new tab so that upon overriding, we can present an option to the user to pick their default rather than us overriding by default (looks bad on us). I'd much rather place nice than lose the user altogether.

[NV]

@mikecann

When we survey our users why they uninstall, the single largest reason is that they dont want us to replace their newtab page.

I have the exact same uninstall survey data with my extension (tab-cellar.app, not public yet).

Maintaining two different versions (one that overrides the new tab and one that doesn't) adds a lot of complexity. What if you want to migrate from one version to another? You'd need to sync your personal data and settings.

We are currently doing a "hack" where the user is given a setting that allows them to choose a new URL for us to bounce you to when our newtab.html page opens instead of displaying the game.

We default this URL to "chrome-search://local-ntp/local-ntp.html" on Chrome and "edge://newtab/" on Edge.

Thank you for mentioning this! I'm going to use it for the time being.

[Lomde]

Hi, I would like to express my current need for new tab override to be an optional feature.

I have an extension whose main purpose is to be an organizer.
Users can save links and organize them on an option_ui page.
"options_ui": {
"page": "options.html",
"open_in_tab": true
},

Some users, like myself, find it useful to be able to see this page when they open a new tab.
Therefore, I would like new tab settings to be optional, because that is not the main purpose of the extension, and some users could prefer to keep their own new tab.

The problem here is that new tab override is not optional.
Users don't get the choice to have the extension without the new tab (extension will be disabled if user opts out for the new tab override... frustrating).

I can't even tell my users to change their new tab URL manually because there is no (more?) settings in Chrome for custom new tab URL.

[jspivack]

During today's meeting someone suggested exposing an API that would allow an extension to become the currently active new tab page. This feels to me like it could be a good path to provide the kind of capability being requested without being too prescriptive about browser UI or settings management.

Briefly, what I'm currently imagining is introducing a new method that would be named something like .setNewTabPage() .setOverrideUrl(), namespace TBD. In order to help ensure that the method is only called when intended by the user, this method would require a user gesture. Browsers might also choose to present the user with a setting change confirmation in trusted UI.

I was looking for a similar solution and stumbled upon your comment. This sounds like an ideal API surface, is it worth breaking out into its own ticket?