On Tue, 07 Apr 2026 20:45:20 -0400 "Daniel Richard G." wrote:
> On Tue, 2026 Apr 7 13:06-04:00, Andres Salomon wrote:
> >>
> >> I can try a couple old snapshots to try to find when the behavior
changed.
> >
> > I've verified that it changed between 145 and 146.
>
> Got it nailed down: the behavior changed between
>
> 146.0.7680.164-1
> 146.0.7680.177-1
>
> No relevant notes in Ahrotahn's pull request for .177:
>
> https://github.com/ungoogled-software/ungoogled-chromium/pull/3721
>
> Not even the big Git changelog seems to show anything for "tab" or
> "search". And I don't see anything clearly relevant in the full diff.
> It's got to be in there somewhere, but I can't tell my omniboxes from my
> contextual chips...
>
> On Tue, 2026 Apr 7 18:31-04:00, Andres Salomon wrote:
> >
> > Meanwhile, chromium 146+ uses what's in
> > /etc/chromium/master_preferences'
search_provider_overrides::new_tab_url
> > for what to display on the new tab page. If you set it to about:blank
> > for example, and run chromium --temp-profile, the new tab page will be
> > blank. I still haven't narrowed down what changed between 145 and 146,
> > but this might also be a good excuse to change how
> > search_provider_overrides is handled..
>
> Confirmed that this gets the new-tab page offline again, though it would
> be nice to have back the big search field in the middle of the page.
>
>
What is extremely bugging is, that the version 145.0.7632.159-1–deb13u1
from the stable repository does not contain this bug, while the version
146.0.7680.177-1~deb13u1 from the stable-security repository contains
this changed behavior.
Hiding such a change in a security update is not what I expect, neither
from debian nor from chromium.
