24-03-2026 03:38 PM
Before update 149.0: I typed a word into the top right search box and then clicked the preferred search engine icon to complete the search. This took two (2) actions.
After update 149.0: When I type a word into the top right search box I then have to click the drop down menu to the left and select the preferred search engine by clicking and then press enter or click the arrow to complete the search. Now it takes four (4) actions.
Last time I made a similar post about this regarding the address bar, I was provided with a partial fix. On 'about config' change "browser urlbar scotchBonnet enableOverride" to false.
Is a similar fix possible here? Can the instant click searching be brought back?
31-03-2026 07:10 PM
I want to have a separate address bar, for when I wish to type in an address I have already.
I do not want it to open a search window, unless I ask for in a separate search bar. Can you at least help with that?
01-04-2026 02:49 PM - edited 01-04-2026 02:52 PM
Thank you for taking the time to take on board user feedback. I really appreciate it. I hope the feedback below is useful to you.
I am not necessarily advocating to a return to the old design, I accept a new design could be just as good if not better if done properly, but what we have now is definitely worse, which I will demonstrate further below.
However, the stated reason for the change - to improve accessibility for non-mouse users - doesn't scan for me as the new design is also harder to use by keyboard. Further, if it were such a bad design for accessibility, then why does the main address bar still work basically the same as the search bar used to? I would've assumed that the address bar would've been "fixed" before the search bar given the former is likely used by more people.
Also, you stated that one can use Alt+DownArrow to open the list of search engines. This does not work for me at all. Even if it did, I don't see that as an intuitive feature one would discover organically. Speaking as an avid user of keyboard shortcuts, I would try tabbing and arrowing about (which all work as you'd expect in the old design and don't in the new), but I would never think to try Alt+Arrow.
To demonstrate why the new design is worse for both Keyboard-only users and Mouse users, I will now walk through and compare, action-by-action, the process of searching with one's 2nd search engine, then 3rd, then back to 'default'. In all cases I will use the most optimal input flow I can think of, thus assuming the user doesn't get lost or confused in the UI.
Keyboard Only, Old Design
Keyboard Only, New Design
By my count, excluding typing the actual search term, the Old Design requires 12 key presses, whereas the New Design 24 key presses. Literally twice as much work to achieve the same thing.
Mouse+Keyboard, Old Design
Mouse+Keyboard, New Design
By my count, the Old Design requires 6 clicks, whereas the New Design requires 12. Again, literally twice as much work to achieve the same thing. Also the "clickable areas" in the new design are quite a bit thinner than the equivalent areas were in old design, requiring one to be slower and more accurate to click the right things.
I will conceed that the new design would reduce the amount of work if your intent is to switch to and use a given search engine for several searches in a row. However, whilst I can't speak for others, that is absolutely not how I use my search bar. I use the default search engine 95% of the time, clicking the others for the odd one-off search every now-and-then. So for me, the search bar "remembering" my most recently selected search engine is usually an active hinderance. Indeed, why even have a 'default' if you have to keep explicitly telling it to go back to the default each time? Perhaps this could be a setting somewhere to allow the user to select their preferred behaviour.
There are two things I can see that the new search bar experience brings to the table:
Both are nice, but not worth the level of clunk in new design, and I strongly suspect both could've been implemented into the old design if desired. If you can preserve these capabilities in the improved new design you're presently prototyping then great, but I don't think they're must-haves.
Also the @ shortcuts are partially broken anyway, as they only work when you don't have a non-default search engine selected. So, once you've used, say, @wikipedia you have to explicitly clear the wikipedia search engine from the search bar before you can select, say, @ecosia in the same way.
Finally, in fiddling with the @ shortcuts, I discovered a really weird bit of UX in the new design. Having no search engine selected (and thus searches go to your default search engine) is not the same thing as having explicitly selected the search engine that happens to be your default. They both send your searches to the same place, but in other ways they behave differently: in the latter case @ shortcuts don't work, and you need to do extra actions to 'clear' the selection back to the default before you can choose something else.
P.S. To answer some of your questions: Yes I think clickable search icons being visible by default (or "pinned" as an option) would solve the issue for Mouse users, and possibly also keyboard users depending how they can be accessed. I am indifferent whether the search icons have labels or not. I have six search engines.
01-04-2026 03:11 PM - edited 01-04-2026 03:12 PM
Thanks for the detailed feedback. I hear you! I can't address every point in this reply as I've also got a search bar to design 😅 but here are a couple of things:
Accessibility was one of the reasons for the change, but not the only one, and it wasn't about the accessibility of the search box. As I understand it, the icons in their old position made navigating the toolbar more difficult for people who do not use a mouse. I won't go into the details as these replies would become incredibly long, but bear in mind that this would also include people who have their computer read the interface aloud, or people who navigate by voice – it doesn't necessarily mean keyboard users.
Another reason for the change was that introducing the same change last year in the address bar led to a statistically significant increase in the number of users searching with alternative search engines. Our data scientists crunched the numbers: people just weren't finding that feature in its old location. If you're seeing an address bar that works differently to the new design then maybe you have a config setting set that has kept it stuck on an old design. The new design of the search box brought it in line with the address bar (which also means code re-use, so the browser will be less bloated by the same thing being coded twice in different ways).
We already plan to address some of your tangentially related suggestions. For example, I agree that 'search mode' is confusing, where you have selected a non-default search engine, and the search bar works differently as a result. Removing the need to click the 'x' is already in the works.
Leave it with me, and we'll get things back on track soon.
Thanks again!
01-04-2026 03:42 PM - edited 01-04-2026 03:57 PM
Fair enough, I had not considered (nor do I have any way of testing) the experience for users of screen readers and voice navigation.
Now that you mention it, I do vaguely remember having to change some settings to revert a change to the address bar in the past. I think it was because the newer style address bar doesn't allow me to turn off searching-from-the-address-bar reliably, which is a pet peeve. I never want a search results page because I've mistyped a URL! But anyway, that's not an argument for this thread... 😅
As a developer myself, I totally hear you on code re-use and discoverability. However, I would like to suggest that people who use the separate search bar may do so specifically because they want a different and separate experience to what the address bar offers (as I do). Obviously I don't have access to hard numbers, but as we all know 90% of users stick to the defaults in any program, and the separate search bar is not present in Firefox by default as of many years ago - one has to actively choose to add it via a not-very-easy-to-find customization menu. Therefore I think its safe to assume that the people that do so are already likely to be reasonably capable users, and are much less likely to have missed that they can add/remove/use additional search engines. Basically, as I see it, the separate search bar is already a power-user feature, so perhaps we should treat it as one.
01-04-2026 05:06 PM
Agreed. That's why we're going to improve the standalone search box for power users, to bring back some of the functionality lost in this update without making it a completely different element.
01-04-2026 05:02 PM
Alarm-Siren, while I agree that there are more key presses needed than necessary, there are ways to decrease them.
Pressing alt+down while in the edit field puts you in the same position as having pressed shift+tab then down. (Although in both cases you will still need a seemingly redundant further keypress to enter the newly opened menu at position #1.)
You can also reduce the need for arrowing by pressing the first letter of the desired search engine.
For example, if while in the edit field you press alt+down then D, this will select DuckDuckGo straight away. (Assuming that there are no other search engines in the list that start with D of course. If there are you may need to press D more times to cycle between them.)
01-04-2026 05:06 PM
It's on our list to make these hidden keyboard shortcuts more discoverable.
02-04-2026 05:40 PM
How about instead of implementing new keyboard shortcuts, you just keep it the way it was before the change? Why are you TAKING options away from your users? That's what I don't understand. If this was Micro$lop, I would expect this, but not Firefox.
All I used to have to do is type my search, then either hit enter to use my default search engine, or just click the icon of the one I wanted. A two-step process. No alt-arrows, or any of that. Making it more complicated isn't "Accessibility;" it's the exact opposite: it just makes it a pain.
06-04-2026 01:59 PM - edited 06-04-2026 02:00 PM
The real problem is this: you're making the process clunky, and your users are telling you they don't want that. My suggestion is to make the dev team understand that, and don't proceed with killing the old widget. You've already angered users by just introducing the new widget without warning us about it, and not telling us about the procedure to change it back. Now just imagine how angry we're going to be if you change the widget WITHOUT giving us a way to change it back.
Bottom line: Don't be Micro$lop, don't force unnecessary changes on your users.
02-04-2026 01:39 AM
I did say in my post that I tried Alt+Down and it did not work for me. I also made the point that even if it did work, its not organically discoverable.
Yes using the first letter shortcut would save a keypress, but only if the search engines have unique first letters which isn't the case for me - e.g. Google vs Google Maps search engines are both on 'G'. I was trying to keep my example generic and without assumptions of what search engines they have installed and, tbh, whilst I did know about the first letter shortcut it was only from reading this thread - so again, a problem of discoverability.
Either way I think we might be splitting hairs: we both agree the new design is clunkier than it needs to be.
02-04-2026 06:53 AM
Alarm-Siren, yes the time-saving methods that I referred to do require some advance knowledge. Not everyone will be aware that in many applications and OS elements you can press alt+down while in an edit box to expand a dropdown list, or press single letters to move to items in menus and lists.
But anyway, not sure why alt+down would not work for you. Just a thought but you could try alt+up instead.
06-04-2026 03:44 AM
Some of this has already been covered by others but:
The fundamental issue is doubling the amount of inputs (2 > 4) needed to run a search, which makes the interface less efficient and more irritating. It seems to contradict a core principle of good UIs.
Another key negative behaviour is making the selected search engine the default. I do most searching through DDG and that should always be the default. When I change engine because I'm searching for a location, lyric, game info etc., I almost never want to search the same place again next time. So I'm being forced to select a search engine every time I search, adding even more friction to the experience.
From a UX perspective the new search is more confusing. Having to click so many times to run a search doesn't make sense - why, having chosen a search engine, would I then have to click another time to run the search? When I first encountered this behaviour I assumed search was broken, and it took me a while to understand what the expected behaviour is.
Having to click to view the list of available search options is also annoying.
Alt+down doesn't help at all. It requires even more inputs, and also that I take my hands off the mouse (many of my searches are C&P).
To answer your questions: don't care about list v grid. Labels are useful but then they're visible when you finally get to the list, so not sure if that's something which has changed. I have 9 search engines I use. Pinning by default would probably be annoying because that's a lot of icons and where would they fit?
06-04-2026 01:03 PM - edited 06-04-2026 01:06 PM
My issue is relatively minor; I evidently have a habit of pressing CTRL+L -> tab to reach the search box, and lately I've been selecting the search *engine* rather than the text field. In my case the issue would be resolved by moving the search engine selection *after* the search text field, but this may impact other people. Probably better if I get used to hitting CTRL+K instead.
Other people's issue with not being able to select the search engine as quickly as they used to is more significant.
07-04-2026 05:51 AM
Regarding accesibility, my current method of using the old search bar doesn't use the mouse at all:
CMD+K - cursor moves to the search bar
CMD+up/down arrows - cycles through the search engines
Type in search term then hit enter.
The new version breaks this method, making it *less* accesible!
08-04-2026 05:28 AM
Hi Errrm – CMD+K still works, and if you switch to Option up/down arrows instead of CMD, it should be pretty similar. Still all accessible with the keyboard. We're also going to make other improvements so that it gets better too.
27-03-2026 07:05 PM
I just found this: It seems to fix it, at least it did for me:
https://www.askvg.com/how-to-restore-old-classic-search-bar-in-mozilla-firefox-149-and-later/
30-03-2026 12:26 PM
Using the tab key to switch between the address bar and search bar has been the default for 20+ years.
Anyone who approved breaking this behaviour under the guise of "accessibility" should be shot into space.
31-03-2026 05:06 PM
Just here to give a quick +1 to this. The new search bar is far less convenient to use. I'd certainly prefer if we went back to the previous UI.
01-04-2026 02:41 PM
Agreed. It's not just that there's more clicking involved, but it used to not require clicking at all: ctrl+K to get into the search bar, then tab to change search engine. There's something using alt I got to work for that once, but then I needed to use the mouse to get back to my default search engine next time I needed to find something.
Mozilla, we're begging you to put it back, or give us the option to turn this off.
01-04-2026 02:52 PM
Hi Luke. There's a config option to revert it, but that won't work forever. We'll be sure to make improvements to it before we remove that.
If it's useful to know, I believe you can still use CTRL+K to get into the search bar, and then you can use Alt+ up/down arrows to navigate the search engine switcher without touching the mouse, Enter to select it (and from release 150 we're changing it so that it should also run the search, whereas today it takes another Enter to run the search).
02-04-2026 05:42 PM
Why not? Why take away features that users actually like instead of making them more complicated whether we like it or not? This isn't "Accessibility;" this is just garbage. It wouldn't be so bad, but every now and then, Firefox will just decide on its own to update, even though I have it set not to ever do that. Unless you're going to make the updated feature as streamlined as it used to be, then I don't want it.
08-04-2026 05:29 AM
@Didymus20X6 wrote:
Unless you're going to make the updated feature as streamlined as it used to be…
That's the plan! Or even… to make it more streamlined.
03-04-2026 02:28 PM
Why do you insist on double down on these decisions that people obviously dislike? I know that people won't be posting when they like the change, but this is obviously not a change that people like. The search bar is already horrible compared to how it was and now it's being made even worse. The option to remove it should be a permanent option at least and I would like to know why it shouldn't be. What could the cost of keeping it possibly be?
15-04-2026 04:47 AM
@PaulFirefoxUX
Now that you're fixing the search bar, I'd like to be able to add random search engines to the search bar (like it used to be). I still very much miss that feature (as a long time power user of the search bar).
I know it's possible to add a keyword to a search, that can't be added to the search bar, but that's not as efficient as being able to directly search from the search bar.
I'd also like to be able to add icons to those for the search bar.
For example I'd like to be able to add https://www.jamieoliver.com/search/
to the search bar with the favicon (incon that's displayed in the tab) or be able to add a my own custom favicon if the site doesn't provide one.
28-04-2026 12:44 AM
I found a way to add custom search engines to the OLD ADDRESS BAR.
It seems this functionality is maintained for the new bar. If not, please continue it.
Here's how to go about it:
Adding a custom search engine:
(Works for GET requests and POST requests)
1. Open a new tab and type about:config in the address bar
2. In the search box type: browser.urlbar.update2.engineAliasRefresh
3. Click on the little + symbol on the right. It should look like after you pressed it: boolean true value after pressing plus sign
4. Go to firefox Settings → Search. Or enter this in the address bar: about:preferences#search
5. In the "Search Shortcuts" section you should notice a new "add" button.
6. Press the add button and fill in the name, search engine url and a keyword(optional).
7. Go to the "Search Box" and select the engine you just added.
Note that the engine url should contain a "%s" in the url. Firefox replaces the %s with your search terms. An example of this is https://www.jamieoliver.com/search/%s
(See attached screenshot)
28-04-2026 12:50 AM - edited 28-04-2026 01:25 AM
28-04-2026 03:21 AM
In Firefox, currently 150, browser.urlbar.update2.engineAliasRefresh, the preference, no longer exists.
No need to add browser.urlbar.update2.engineAliasRefresh.
Add custom search engines in Firefox, it works.
In Firefox 140, browser.urlbar.update2.engineAliasRefresh, the preference already exists, defaut value true. Add custom search engines in Firefox, it works.
08-04-2026 02:52 PM - edited 09-04-2026 02:23 AM
Paul, I know that the plan is for searches to take place as soon as a provider is selected from the menu, but will this change be optional?
I personally prefer being able to select a provider before typing a query, or being able to change to a different one while still editing the query, with nothing happening until I press enter. If that is possible.
01-05-2026 05:50 AM
I also think the new change is really bad. It makes switching search engines so hard, especailly using a touch pad.
I add some specific search engines to Firefox to search in different content subscriptions of my institution. The reason why I still put the search bar next to the address bar is to switch to some new search engines just by a single click.
This new change in 149 is really horrible for me.