PSA: Updates to the new tab page in Chrome 138

[Oliver Dunk]

Hi all,

Starting in Chrome 138, we are updating the new tab page UI with a new footer. This will show when the new tab page is provided by an extension and offer easier access to the "Customize Chrome" menu. It also makes it easier to see the extension providing the new tab page.

It looks like this:

Users can turn the footer off with the "Show footer on New tab page" toggle or by right-clicking the footer and selecting “Hide footer on New Tab page” in the menu.

If you build a new tab page extension, you may want to check if you need to accommodate this in your UI. You can do so by enabling "NTP Footer" at chrome://flags in Chrome Beta or Canary.

This change will be gradually rolling out to users over the coming weeks. As always, if you have any questions, please do let us know.

Thanks,
Oliver on behalf of Chrome Extensions DevRel

[Jackie Han]

Custom themes should be part of Chrome's settings, and the absence of this footer should not affect users. So in my opinion, this footer should not be part of NTP.

It shouldn't always appear in daily use. If it must be displayed, one suggestion is to add a close button on the footer (similar to website cookie banner). Clicking it will stop displaying the footer and guide the user to adjust the settings in the browser settings.

Users can turn the footer off by right-clicking the footer and selecting “Hide footer on New Tab page” in the menu.

I didn't see this menu by right-clicking the footer (Chrome Canary 139.0.7245.0)

 

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/35838641-eae6-4632-9a00-77b4d6831a81n%40chromium.org.

[Oliver Dunk]

I didn't see this menu by right-clicking the footer (Chrome Canary 139.0.7245.0)

Thanks for testing! We're still landing some final changes - hopefully this will be there shortly.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[Mythical 5th]

I have the toggle in version 138. I don't like it, it looks like a clunky hack to let users be able to edit the toolbar.

Have the designers considered adding the Profile Name and Avatar to the Customise Chrome sidebar rather than adding a footer to the NTP?

The "Customise profile" settings page has 3 sections: Name, Theme and Avatar, and can be accessed directly from the ellipsis menu and the profile menu (where it has a different label in each menu!). Unlike the sidebar equivalent, the settings page has no button/link to edit the toolbar, but one can be found in the Appearance menu. Clicking this opens the sidebar (which feels wrong).

If the menu options for Customise Profile/Customise Your Chrome opened the sidebar instead of the settings page, and if the sidebar included Profile Name and Avatar (as well as the theme and the link to edit the toolbar), we would not need the NTP footer.

[Anton]

Dozens of popular extensions, like Momentum, deliver clean, minimal new-tab experiences—until an intrusive, empty bar appears at the bottom of the screen BY DEFAULT...
Bad design. Bad decision. Delivers zero value to an end user. Should be disable it by default!

[Anton]

What are the possible reasons for this to be shown?

[Mythical 5th]

Why can't we just use the profile menu?

- The profile menu button opens a settings panel for the user to select a profile name, theme and avatar.

- The NTP footer button opens a panel for theme, toolbar shortcuts and NTP options.

So there is already some crossover, why not combine it all and access it from one place?

[Alexander Ostapenko]

Hi Oliver and team,

Thanks for raising this topic here. I’m getting negative feedback from users who think the new footer is part of our UI.

1. Can an extension opt out of the NTP footer via manifest?

2. Wouldn’t it be better to provide an API for programmatically opening the “Customize Chrome” panel from an extension?

   That would let us expose it in a natural place inside our UI, without the intrusive footer breaking the design.

Thanks, 

Alexander Ostapenko

Homey

пятница, 15 августа 2025 г. в 00:57:27 UTC+2, Mythical 5th:

[Lithium]

Are there new APIs or other ways for extensions to determine whether this footer is being displayed? Then, extensions could objectively prompt those users to turn off the footer if they don't want to see it.

[al]

I'm not able to test since the change hasn't appeared for me but can you not check by comparing say the outerWidth > innerWidth or some other window measurement?

Then if you detect it, just prompt the user with a tooltip, for example. 

My question is: if the Chrome team is encouraging more user customization - which, great, all for it - might they consider supporting the themes API for extensions to adapt to the browser theme?

Actually, I can see Chrome is supportive, in which case, might this NTP update be a signal that an implementation is on the horizon?

[Oliver Dunk]

Hi both,

There isn't an API which returns the state of the footer. It's possible there is a workaround using width properties like al suggested, but I wasn't able to figure one out with a quick play just now.

To clarify, I don't think we have a stance on themes API right now. However, we are interested in supporting a way to have color theme based extension icons: https://github.com/w3c/webextensions/blob/main/proposals/dark_mode_extension_icons.md. We have started implementation of this but I don't think it has moved anywhere in a little while, so I can't say when that work would be finished.

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[al]

That's true, my apologies Oliver, I think I misinterpreted the GitHub issue and Chrome stance.

Certainly looking forward to the icons change.

As for a workaround, I was wrong in my initial theory, with comparing inner/outer heights, but I think I've got a fairly reliable hack - 

let thisTab = (await chrome.tabs.getCurrent())

let tabs = await (chrome.tabs.query({currentWindow: true}))

let footerShown = false;

if (tabs.length > 1) {

  let previousTabHeight = tabs[thisTab.index - 1].height

  if (thisTab.height < previousTabHeight) {

    console.log("Footer shown")

    footerShown = true

// Display a tooltip/other ui

  }

  else {

    console.log("Footer hidden")

  }

}

else {

  // no other tab reference

}

if (footerShown) {

  // listen for 'resize' event

  // onResize: check page height to see if the footer was hidden

}

The idea is that it uses the Tabs API to compare the NTP tab and another (non NTP) tab's height, where a difference - I believe - indicates whether the footer is shown. 

I can't think of other Chrome UI that could affect it, off the top of my head, but it's possible.

I still think there might be a simpler solution.

[Oliver Dunk]

Smart thinking!

One case would be if the user opens DevTools.

Out of interest, what is the use case for detecting the footer? Is there a particular adjustment you want to make to your UI?

Oliver Dunk | DevRel, Chrome Extensions | https://developer.chrome.com/ | London, GB

[al]

Good catch

Just to preface - I don't use or develop a NTP ext, but I see what's happening now - 

Google PMs want the cutomization ability surfaced, since the default NTP has it, and store NTPs hide it. 

But there's not really an elegant way to display it, hence the footer - and I get it; it's a safe approach. 

As a result, since it visually conflicts with custom NTPs or as Alexander said, users might get confused, devs want to hide it or guide the user to hiding it (hence the hack).

I think I personally agree with Jackie here, a hide button (like Hide) would work in conjuction with Chrome UI/dialogs that might say "Customize Chrome by going to X Y Z".

Though I'd also suggest surfacing the "Customize Chrome" settings menu item by one, or maybe adding it to "Customize Profile" per Mythical 5th's suggestion.

I don't think the current Google way is that bad though, it's two fairly obvious clicks to hide the menu.

Maybe for developer agency, it could be added to the action.userSettings API or something more appropriate.

[Anton]

[Alexander Ostapenko]

I was thinking about how to simplify al’s workaround — instead of comparing different tabs, you can just detect the footer directly by its fixed 57px height. Luckily, there aren’t many other Chrome UI elements that affect the window height.

// Constants
const BASE_CHROME_UI_HEIGHT = 87;     // tab strip + omnibox
const FOOTER_HEIGHT = 57;
const BOOKMARKS_BAR_HEIGHT = 34;

async function isFooterShown() {
  // Get current browser window
  const currentWindow = await chrome.windows.getCurrent();

  // Get current active tab
  const currentTab = await chrome.tabs.getCurrent();

  // Overhead = the difference between full window height and the tab content height
  const overhead = currentWindow.height - currentTab.height;

  // Possible scenarios when footer is present
  const candidates = [
    BASE_CHROME_UI_HEIGHT + FOOTER_HEIGHT,                        // footer only
    BASE_CHROME_UI_HEIGHT + BOOKMARKS_BAR_HEIGHT + FOOTER_HEIGHT  // footer + bookmarks bar
  ];

  // Strict match (1-to-1)
  return candidates.includes(overhead);
}

// Example usage
isFooterShown().then(shown => {
  console.log(shown ? "Footer SHOWN" : "Footer HIDDEN");
});

воскресенье, 24 августа 2025 г. в 23:57:31 UTC+2, Anton:

[al]

Yeah, that's way better - nice find Alexander.

I have to be honest, I tried looking for the footer height as well, but couldn't find it, and then thought it could be dynamic perhaps.

Is it in /browser/ui/webui/new_tab_footer/ ?

Nice work. 

[Mythical 5th]

Any workaround based on calculations of vertical space usage needs to account for variations in font size and display resolution.

For example, when I adjust my operating system's default font size, the workaround above breaks. This is because the bookmarks bar height changes to accommodate the new font size (I had to restart Chrome for this to take effect).

The footer *does not* respond to the OS font size, and also remains constant regardless of the user's stated font size in Settings > Appearance > Font Size. So checking the available height might provide a way to detect the footer, but other heights definitely should not be hard-coded.