Newtab search handoff can't be disabled anymore

👁 Image	u785190 Reporter
	Description • 4 months ago

hallo guten tag
das Problem ist mit „browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar“
nicht gelöst
ich finde das die suche jetzt in der Adressleiste angezeigt wird schlicht weg scheiße
ich kann mich nicht mehr um stellen nach 20 jahren
es betrifft ja alle Nutzer
Entfernen Sie den alten UI-Code für die Inhaltssuche ohne Übergabe ist nicht Gelöst?????

👁 Image	Daniel Veditz [:dveditz]
	Updated • 4 months ago

👁 Image	BugBot [:suhaib / :marco/ :calixte]
	Comment 1 • 4 months ago

The Bugbug bot thinks this bug should belong to the 'Firefox::New Tab Page' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

👁 Image	Monica Chiorean
	Comment 2 • 3 months ago

Hammer, can you please add steps to reproduce for your issue? Thank you.

👁 Image	u785190 Reporter
	Comment 3 • 3 months ago

das Problem ist das die suche in der Adessleiste stadt findet.
im internet gibt es verschiedene möglichkeiten über/ about:config/
ich habe einige ausprobiert kein erfolg
ich habe windows 11 und firefox 143.03
ich will das die suche wieder in der mitte ist also das ist die "Internetsuche" so ist es auch bei Firefox zu finden
und die habe ich auch Jahre benutzt und ich kann mich mit dem neuen schlecht anfreunden
und erlich sehe ich darin keinen sinn das es geändert würde
mfg
hammer

👁 Image	Maxx Crawford [:maxx]
	Updated • 3 months ago

👁 Image	Moritz Beier [:mbeier]
	Comment 5 • 3 months ago

Sorry for the inconvenience, please see this comment for an explanation why that change was made. Also note that we are currently working on bringing an improved search bar to the new tab page that will not hand off to the address bar.

If using the address bar to search feels weird to you, you can also add a dedicated search bar next to it: https://support.mozilla.org/de/kb/meine-suchleiste-ist-weg-wie-kann-ich-sie-wieder-hinzuf%C3%BCgen

👁 Image	u785190 Reporter
	Comment 6 • 3 months ago

(In reply to Moritz Beier [:mbeier] from comment #5)

Sorry for the inconvenience, please see this comment for an explanation why that change was made. Also note that we are currently working on bringing an improved search bar to the new tab page that will not hand off to the address bar.

If using the address bar to search feels weird to you, you can also add a dedicated search bar next to it: https://support.mozilla.org/de/kb/meine-suchleiste-ist-weg-wie-kann-ich-sie-wieder-hinzuf%C3%BCgen

hallo herr Moritz Beier
danke für ein sehr gute antwort den link habe ich schon ausprobiert die such leiste ist trotzdem oben in der leiste
besten dank
schön wenn sie sich dem problem gestellt haben und eine Lösung suchen ???

warum die suchleiste hat die ganzen Jahre funktioniert bis warscheinlich ein Updat das zunichte gemacht hat
ich würde mich über eine Lösung wenn sie die gefunden haben sehr freuen auch andere
mfg
hammer

👁 Image	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 7 • 3 months ago

We were caught off guard a bit by how many people were relying on this unsupported search mode for accessibility reasons. We're going to attempt to temporarily revive the non-handoff capability until the new inline address bar is ready.

👁 Image	Mike Conley (:mconley) (:⚙️) Assignee
	Updated • 3 months ago

👁 Image	Mike Conley (:mconley) (:⚙️) Assignee
	Updated • 3 months ago

👁 Image	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 9 • 3 months ago

This is an almost verbatim revival of the ContentSearchUIController that used to live inside
of a script called "contentSearchUI.js", which got removed in Bug 1999334. We place this inside
of contentSearchHandoffUI.mjs so that the search handoff component can use it in a "non-handoff"
mode.

👁 Image	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 10 • 3 months ago

Alongside adding the required integration between ContentSearchHandoffUI and
ContentSearchUIController, this also adds a pref-read to SearchUIUtils for the
external widget registrar for newtab to choose whether or not to use handoff
or non-handoff mode.

Probably the most notable absence in this wiring up is a complete lack of tests.

We've decided not to revive / modify our automated tests for this mode, mainly
due to the challenge of maintaining the test support for both cases while we
work on completely replacing this mechanism down the road. So we're relying
entirely on manual testing here, and the majority of the automated testing
is really just to ensure that the handoff mode hasn't regressed somehow
from this revival.

👁 Image	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 11 • 3 months ago

This is pretty ham-fisted, but it's also a temporary kludge until we can get the inline
search mechanism done and we can remove all of this.

Essentially, this revives and inlines the old non-handoff CSS from contentSearchUI.css into
contentSearchHandoffUI.css, but only uses it in non-handoff mode. It also includes a bunch
of additional overrides that newtab had historically been applying to contentSearchUI.css,
but those are now inlined directly. This way, we can get the behaviour and appearance that
we want without relying on newtab needing to update its sheets / send out a train-hop release
to support this revived mode.

The CSS rules have not been de-duplicated / simplified, beyond the inlining of various variables
that historically had lived within activity-stream.css. I honestly don't think such a
simplification / cleanup is worth the effort since this is so temporary.

👁 Image	Mark Banner (:standard8)
	Updated • 3 months ago

👁 Image	Phabricator Automation
	Updated • 3 months ago

👁 Image	Phabricator Automation
	Updated • 3 months ago

👁 Image	Phabricator Automation
	Updated • 3 months ago

👁 Image	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 12 • 3 months ago

[Tracking Requested - why for this release]:

We removed support for the non-handoff version of the New Tab search input based on the fact that it was a non-default, non-exposed, and essentially unsupported configuration - and the number of clients making searches using that mode was so small (see bug 1999334 comment 5). We've now gathered enough evidence and feedback to suggest that a significant portion of these users was using the unsupported non-handoff settings for accessibility reasons, and that the handoff mode is not accessible for them. PM has decided to let this preference limp along for a few releases further until we can complete the inline search input experience (MCAB), to reduce user-pain.

We're going to see if we can get this reversion / revival of the pref into the next planned dot release after Firefox 148 hits the release channel.

👁 Image	Mike Conley (:mconley) (:⚙️) Assignee
	Updated • 3 months ago

👁 Image	Marco Bonardo [:mak]
	Updated • 3 months ago

👁 Image	Donal Meehan [:dmeehan]
	Updated • 3 months ago

👁 Image	Pulsebot
	Comment 13 • 3 months ago

Pushed by csabou@mozilla.com: https://github.com/mozilla-firefox/firefox/commit/3ff9c73a9fd1 https://hg.mozilla.org/mozilla-central/rev/b5d4651976e1 Part 1: Revive ContentSearchUIController and put it into contentSearchHandoffUI.mjs. r=Standard8,ayeddi https://github.com/mozilla-firefox/firefox/commit/4b0bd10d5a6c https://hg.mozilla.org/mozilla-central/rev/ba24cc9d1d5c Part 2: Wire up ContentSearchUIController to ContentSearchHandoffUI component and revive handoff pref support. r=Standard8 https://github.com/mozilla-firefox/firefox/commit/c557d14aa83a https://hg.mozilla.org/mozilla-central/rev/b3d840c58f16 Part 3: Revive contentSearchUI styles and inline newtab style modifications. r=Standard8

👁 Image	Cosmin Sabou [:CosminS]
	Comment 14 • 3 months ago
bugherder

https://hg.mozilla.org/mozilla-central/rev/b5d4651976e1
https://hg.mozilla.org/mozilla-central/rev/ba24cc9d1d5c
https://hg.mozilla.org/mozilla-central/rev/b3d840c58f16

👁 Image	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 15 • 3 months ago

Testing instructions:

• In a build with the patches applied, ensure that handoff mode on New Tab and about:privatebrowsing in a Private Browsing window still works.
• Then, in about:config, set browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar to false
• Test searching in New Tab - the legacy inline experience should be displayed in a dropdown. This should work with both light and dark themes.
• Test searching in about:privatebrowsing in a Private Browsing window. Despite the pref-flip, this should still use the handoff mechanism.

👁 Image	Mark Banner (:standard8)
	Updated • 3 months ago

👁 Image	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 17 • 3 months ago

This is an almost verbatim revival of the ContentSearchUIController that used to live inside
of a script called "contentSearchUI.js", which got removed in Bug 1999334. We place this inside
of contentSearchHandoffUI.mjs so that the search handoff component can use it in a "non-handoff"
mode.

Original Revision: https://phabricator.services.mozilla.com/D284289

👁 Image	Phabricator Automation
	Updated • 3 months ago

👁 Image	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 18 • 3 months ago

Alongside adding the required integration between ContentSearchHandoffUI and
ContentSearchUIController, this also adds a pref-read to SearchUIUtils for the
external widget registrar for newtab to choose whether or not to use handoff
or non-handoff mode.

Probably the most notable absence in this wiring up is a complete lack of tests.

We've decided not to revive / modify our automated tests for this mode, mainly
due to the challenge of maintaining the test support for both cases while we
work on completely replacing this mechanism down the road. So we're relying
entirely on manual testing here, and the majority of the automated testing
is really just to ensure that the handoff mode hasn't regressed somehow
from this revival.

Original Revision: https://phabricator.services.mozilla.com/D284290

👁 Image	Phabricator Automation
	Updated • 3 months ago

👁 Image	Phabricator Automation
	Comment 19 • 3 months ago

firefox-beta Uplift Approval Request

• User impact if declined: Clients that were relying on the unsupported browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar pref for accessibility reasons will find that it doesn't work anymore, resulting in enough of an accessibility problem that we've decided to revive support temporarily until the inline search experience is ready.
• Code covered by automated testing: yes
• Fix verified in Nightly: no
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: To be clear, the handoff mode is tested in automation. This new non-handoff mode is not tested, and we've made an intentional choice not to revive the tests that had existed previously, since that would really complicate our current search testing code for the handoff mode.

We've made the deliberate decision to rely on manual testing for this unsupported mode.

Testing instructions here: https://bugzilla.mozilla.org/show_bug.cgi?id=2017049#c15

• Risk associated with taking this patch: low
• Explanation of risk level: We've got plenty of automated test coverage for the handoff case, which accounts for the vast majority of searches in Firefox. This patch adds the unsupported pref back and the old prior experience, mainly using revived code that we've moved into a more appropriate place as a stopgap. The new code doesn't run unless the pref is set to the non-default setting.
• String changes made/needed: None.
• Is Android affected?: no

👁 Image	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 20 • 3 months ago

This is pretty ham-fisted, but it's also a temporary kludge until we can get the inline
search mechanism done and we can remove all of this.

Essentially, this revives and inlines the old non-handoff CSS from contentSearchUI.css into
contentSearchHandoffUI.css, but only uses it in non-handoff mode. It also includes a bunch
of additional overrides that newtab had historically been applying to contentSearchUI.css,
but those are now inlined directly. This way, we can get the behaviour and appearance that
we want without relying on newtab needing to update its sheets / send out a train-hop release
to support this revived mode.

The CSS rules have not been de-duplicated / simplified, beyond the inlining of various variables
that historically had lived within activity-stream.css. I honestly don't think such a
simplification / cleanup is worth the effort since this is so temporary.

Original Revision: https://phabricator.services.mozilla.com/D284291

👁 Image	Ardelean Oana, Desktop Test Engineering [:oardelean]
	Updated • 3 months ago

👁 Image	Donal Meehan [:dmeehan]
	Updated • 3 months ago

👁 Image	Mathew Hodson
	Updated • 3 months ago

👁 Image	Ardelean Oana, Desktop Test Engineering [:oardelean]
	Updated • 3 months ago

👁 Image	Ardelean Oana, Desktop Test Engineering [:oardelean]
	Comment 22 • 3 months ago

Reproducible on a 2026-02-20 Firefox Nightly build on Windows 10.

Verified as fixed on Firefox Nightly 150.0a1 on Windows 10, Ubuntu 22, macOS 15.

With browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar set to true, handoff mode on New Tab works as expected in both normal and private browsing windows.

With browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar set to false, the New Tab search field works as expected - both dropdown and search term are visible with the default light/dark theme- and the search is submitted without any issues. Handoff mode works as expected in Private Browsing windows, as per Comment 15.

👁 Image	Donal Meehan [:dmeehan]
	Comment 23 • 3 months ago

:mconley, could you add a release uplift request when you have a moment?
We can aim to include it in the Fx148 planned dot release.

👁 Image	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 24 • 3 months ago

Thanks, yep - I just rebased these patches locally onto release to make sure they worked and will now request uplift.

I suspect they're not going to uplift cleanly because of a simple conflict in firefox.js, but we'll cross that bridge when we get there.

👁 Image	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 25 • 3 months ago

This is an almost verbatim revival of the ContentSearchUIController that used to live inside
of a script called "contentSearchUI.js", which got removed in Bug 1999334. We place this inside
of contentSearchHandoffUI.mjs so that the search handoff component can use it in a "non-handoff"
mode.

Original Revision: https://phabricator.services.mozilla.com/D284289

👁 Image	Phabricator Automation
	Updated • 3 months ago

👁 Image	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 26 • 3 months ago

Alongside adding the required integration between ContentSearchHandoffUI and
ContentSearchUIController, this also adds a pref-read to SearchUIUtils for the
external widget registrar for newtab to choose whether or not to use handoff
or non-handoff mode.

Probably the most notable absence in this wiring up is a complete lack of tests.

We've decided not to revive / modify our automated tests for this mode, mainly
due to the challenge of maintaining the test support for both cases while we
work on completely replacing this mechanism down the road. So we're relying
entirely on manual testing here, and the majority of the automated testing
is really just to ensure that the handoff mode hasn't regressed somehow
from this revival.

Original Revision: https://phabricator.services.mozilla.com/D284290

👁 Image	Phabricator Automation
	Updated • 3 months ago

👁 Image	Mike Conley (:mconley) (:⚙️) Assignee
	Comment 27 • 3 months ago

This is pretty ham-fisted, but it's also a temporary kludge until we can get the inline
search mechanism done and we can remove all of this.

Essentially, this revives and inlines the old non-handoff CSS from contentSearchUI.css into
contentSearchHandoffUI.css, but only uses it in non-handoff mode. It also includes a bunch
of additional overrides that newtab had historically been applying to contentSearchUI.css,
but those are now inlined directly. This way, we can get the behaviour and appearance that
we want without relying on newtab needing to update its sheets / send out a train-hop release
to support this revived mode.

The CSS rules have not been de-duplicated / simplified, beyond the inlining of various variables
that historically had lived within activity-stream.css. I honestly don't think such a
simplification / cleanup is worth the effort since this is so temporary.

Original Revision: https://phabricator.services.mozilla.com/D284291

👁 Image	Phabricator Automation
	Updated • 3 months ago

👁 Image	Phabricator Automation
	Comment 28 • 3 months ago

firefox-release Uplift Approval Request

• User impact if declined: Clients that were relying on the unsupported browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar pref for accessibility reasons will find that it doesn't work anymore, resulting in enough of an accessibility problem that we've decided to revive support temporarily until the inline search experience is ready.
• Code covered by automated testing: yes
• Fix verified in Nightly: yes
• Needs manual QE test: yes
• Steps to reproduce for manual QE testing: To be clear, the handoff mode is tested in automation. This new non-handoff mode is not tested, and we've made an intentional choice not to revive the tests that had existed previously, since that would really complicate our current search testing code for the handoff mode.

We've made the deliberate decision to rely on manual testing for this unsupported mode.

Testing instructions here: https://bugzilla.mozilla.org/show_bug.cgi?id=2017049#c15

• Risk associated with taking this patch: low
• Explanation of risk level: We've got plenty of automated test coverage for the handoff case, which accounts for the vast majority of searches in Firefox. This patch adds the unsupported pref back and the old prior experience, mainly using revived code that we've moved into a more appropriate place as a stopgap. The new code doesn't run unless the pref is set to the non-default setting.
• String changes made/needed: None.
• Is Android affected?: no

👁 Image	Phabricator Automation
	Updated • 3 months ago

👁 Image	Phabricator Automation
	Updated • 3 months ago

👁 Image	Phabricator Automation
	Updated • 3 months ago

👁 Image	Lando Automation
	Updated • 3 months ago

👁 Image	Pulsebot
	Comment 29 • 3 months ago
uplift

https://github.com/mozilla-firefox/firefox/commit/21e251410bac https://hg.mozilla.org/releases/mozilla-beta/rev/9117519681c8 https://github.com/mozilla-firefox/firefox/commit/6bfdd4c9c817 https://hg.mozilla.org/releases/mozilla-beta/rev/ca03f9e35f19 https://github.com/mozilla-firefox/firefox/commit/ae90ce696104 https://hg.mozilla.org/releases/mozilla-beta/rev/36ec63aa20eb

👁 Image	Ardelean Oana, Desktop Test Engineering [:oardelean]
	Comment 30 • 3 months ago

Verified as fixed on Firefox 149.0b2 (treeherder build) on Windows 10, Ubuntu 22, macOS 13.

👁 Image	Donal Meehan [:dmeehan]
	Updated • 3 months ago

👁 Image	Phabricator Automation
	Updated • 3 months ago

👁 Image	Phabricator Automation
	Updated • 3 months ago

👁 Image	Phabricator Automation
	Updated • 3 months ago

👁 Image	Lando Automation
	Updated • 3 months ago

👁 Image	Pulsebot
	Comment 32 • 3 months ago
uplift

https://github.com/mozilla-firefox/firefox/commit/cd91f141c5f0 https://hg.mozilla.org/releases/mozilla-release/rev/fe98897d289b https://github.com/mozilla-firefox/firefox/commit/f29be4997c10 https://hg.mozilla.org/releases/mozilla-release/rev/6939e9d58a7a https://github.com/mozilla-firefox/firefox/commit/099e04744386 https://hg.mozilla.org/releases/mozilla-release/rev/3e8eaac09c1a

👁 Image	Brindusa Tot, DTE
	Updated • 3 months ago

👁 Image	Ardelean Oana, Desktop Test Engineering [:oardelean]
	Comment 33 • 3 months ago

Verified as fixed on Firefox 148.0.2 on Windows 10, Ubuntu 22, macOS 13.

👁 Image	Mark Banner (:standard8)
	Updated • 2 months ago