User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

89.0b3 (64-bit) Desktop. Win 10.
Create new tab, start typing in the "Search with google or enter address" box. Focus immediately goes to the main address bar and what you type ends up being used for auto-complete.

Actual results:

The search box is unusable.

Expected results:

I should have been able to search from the box labelled "Search with google..."

The Bugbug bot thinks this bug should belong to the 'Firefox::Address Bar' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

This is intended. It is part of a new feature called "handoff" enabled in bug 1699834. We want to direct users towards searching in the address bar. We are handling one of the repercussions of this in bug 1645293.

You broke the search bar. I don't want to search from the "awesome bar". I want to search from the search box that's been there for years.

You can press Ctrl+K to focus the address bar and enter search mode with your default engine. From that point, using the address bar is just like using the old search box on the new-tab page.

There's this huge edit control in the center of the screen that says "Search with Google or enter address". And for years upon years it has worked exactly as advertised. But now if you try to use it, focus immediately jumps to a different control. Now, I have already told Firefox don't use that control for search (in Settings / Search / Search Bar). But then, not knowing this edit control now behaves unlike any other edit control in the history of edit controls, I get an error when I hit enter.

Broken UX.

The control in the homepage never really allowed to enter an address, it was a straight search, that means if you typed an address like "facebook.com" into it, you'd have ended up searching for "facebook.com" instead of visiting it. That unfortunately happens a lot to our users because most of us have been trained by search engines to use and (ab)use that field, to a point where many people confuse the browser with the search engine.
The urlbar has a lot more features than a simple field, it can correct mistyped urls, search, provide help and soon it would provide even more utility, thus we feel like the change, while may break some workflows, will be a tangible improvement long term.

"The control in the homepage never really allowed to enter an address, it was a straight search"

Exactly! That's what was useful about it. The little search bar control is too small, so the homepage control made for a much better search UX.

"The urlbar has a lot more features than a simple field, it can correct mistyped urls, search, provide help and soon it would provide even more utility, thus we feel like the change, while may break some workflows, will be a tangible improvement long term."

Then you should get rid of the homepage control. You've already completely destroyed its functionality. Why not just delete it?

(In reply to cleek from comment #7)

"The control in the homepage never really allowed to enter an address, it was a straight search"

Exactly! That's what was useful about it.

There are many workaround to that, CTRL+K as suggested by Drew, or just start your search with a question mark, or type "@engine word".

The little search bar control is too small, so the homepage control made for a much better search UX.

The search bar width can be customized, in Customize just drag the separator between urlbar and search bar. And this is also one of the reasons for which the urlbar is better.

Then you should get rid of the homepage control. You've already completely destroyed its functionality. Why not just delete it?

Because, as I explained, users have been trained by Search Engines to confuse the browser (or the whole Internet concept) with the engine, and due to that training we need this fallback control. We'd be happy to remove that field if that wouldn't disrupt users.

You're already effectively removed it. You're just pretending it's still there.

Regardless, it's clear you think this is the right thing to do. For the record: I 100% disagree. So. I guess that's that.

Have a nice day.

Also, searching from the address bar doesn't work either.

Settings / Search / Search Bar / Use address bar for search and navigation : checked

Type "This doesn't work" into the address bar.

Result: "Hmm. That address doesn’t look right. / Please check that the URL is correct and try again."

You may have flipped the keyword.enabled pref in about:config. it is set to true by default.

Since my bug report was marked as a duplicate, let me copy over the reason I posted it, and why it is a bad idea to lump in search with address:

Here is why this is a problem:

When I search, I want to be very certain that what I type is interpreted as a search query and not an URL. I search for URLs to find information about the site without opening the site. I do this especially if I am suspicious about the safety or reputation of the site. Now, with the text going into the location box, if I type an URL, this will open that page.

Workaround is to open a search site, and then enter the URL I want to do a search on there.

There is also the simpler issue of changing focus after the user has intentionally set focus to the search box.

This may not be a problem once people are untrained from the convenience of having a search box on the blank page, and go back to opening a search site first.

(In reply to Pat Tressel from comment #14)

Workaround is to open a search site, and then enter the URL I want to do a search on there.

As a workaround, you could also press Ctrl+K to enter search mode and search for the URL that way. Alternatively, you could prefix your search with ?, which would also put you in search mode. You could also select the shortcut for the engine you want to search with at the bottom of the address bar dropdown.

Thanks, Harry! Those are good to know. I'll just open the search site and do the search there. That way my safety won't depend on me not typo'ing an option to alter the behavior of the address bar. If I had a separate machine for security-questionable queries, with the OS booted from non-writeable media, preferably no writeable disk at all, and / or more than consumer-grade security, I'd be less worried about goofing up that ? prefix... And it's not just security -- I don't even want to be in the web server logs if it's some site whose (for instance) politics I disagree with. And I don't want to go cleaning out their coo[k|t]ies afterward. :D

NO, just NO.
That should be an OPT-IN at most, and even then, there's a busted UI element left in the middle of a page that literally does NOTHING.

Imagine how stupid and non-intuitive this looks to an average user, how many got frustrated by opening unintended websites and eventually switched browsers merely because of this "intended feature".

You can do better than that, Firefox.

I turned off the handoff to the address bar and can now search as I did before in the NTP.

I used about:config and set browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar to false.

(In reply to cjahn50 from comment #19)

I turned off the handoff to the address bar and can now search as I did before in the NTP.

I used about:config and set browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar to false.

thank you for the Information

@Mozilla: I disagree with your decision regarding the search-box. I hate it when I type a address in the adressbar and some "genius" algorithm decides to alter my input. I'm old school and use the searchbar for search and the adressbar for urls.
I strongly recommend to make the new behavior optional and retain the possibility to use the UI in the previous way.

There is no input altering, we only do some obvious typo fixes (like .ocm => .com) that are benefitting most users. If you have set keyword.enabled to false, then there is a bug that we are tracking and will provide a fix for it.
The input field in the home page is there just because of users habits, as I explained in comment 6.

You can still use the separate search bar, as well as you can still force the urlbar to just be a urlbar or force it to search, you can split its behavior with just a couple settings. All the options are available to do all the things you are suggesting, if you are in doubt on how to achieve something feel free to ask, we have a nice Firefox Desktop Community chat on Matrix https://matrix.to/#/!OjiTSQTpPWGpfDenKT:mozilla.org?via=mozilla.org&via=matrix.org&via=privacytools.io
We also have a new nice feedback tool at https://ideas.mozilla.org that you can use to suggest and vote feedback.

If in doubt, just CTRL(CMD)+K to search, that will always search as you expect.

If you have keyword.enabled set to false, you can follow bug 1713827 for updates about that specific issue.

At least there's "Show search suggestions ahead of browsing history in address bar results", which should've been enabled by default to save so much unnecessary frustration for people.

(In reply to deiwulf from comment #25)

At least there's "Show search suggestions ahead of browsing history in address bar results", which should've been enabled by default to save so much unnecessary frustration for people.

It is enabled by default.

I wouldn't be here if it was, but kudos if it really is in the current builds.
Now just to get rid of the awkward UI element in the FF home page (or rather the option for it) since it serves no purpose.

(In reply to deiwulf from comment #27)

Now just to get rid of the awkward UI element in the FF home page (or rather the option for it) since it serves no purpose.

You can disable it by unselecting "Web Search" in about:preferences#home.

(In reply to cjahn50 from comment #19)

I turned off the handoff to the address bar and can now search as I did before in the NTP.
I used about:config and set browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar to false.

Comments in one of the other bug reports related to this say that the option browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar is going to be removed, so setting it to false is only a temporary workaround. Again, the safe solution is to just open one's desired search site, and do the search there.

(In reply to Marco Bonardo [:mak] from comment #22)

We also have a new nice feedback tool at https://ideas.mozilla.org that you can use to suggest and vote feedback.

Tried that first before going to Bugzilla. It was not a feedback form. Perhaps it is a feedback forum... In any case, I didn't see anything relevant to this.

(In reply to Marco Bonardo [:mak] from comment #8)

Because, as I explained, users have been trained by Search Engines to confuse the browser (or the whole Internet concept) with the engine, and due to that training we need this fallback control. We'd be happy to remove that field if that wouldn't disrupt users.

This seems to be the core confusion. People have not been "trained" by search engines to this confusion. People are simply using a search engine as their homepage, and letting the search engine do a little extra work...for which the search engine gets a tidbit of information about the user. (I am going to use Google as the example here, because I used to work for them.) When a user types a domain name, and intends to go to that site, that is called, by Google, a "nav query". But -- and this is critical -- Google DOES NOT OPEN THAT SITE. They are aware that the user may very well be searching for information ABOUT that site. So, what Google does instead, if it is a prominent site, is show the "OneBox" -- a convenient collection of information about the site, including assorted popular links under that domain. At this point, the user may very well NOT just go to the domain they typed, but rather to one of the offered options. So now, the user has made use of the extra OneBox information -- they did not just do a nav query. What they've now been trained to do is use this extra service provided by Google. And below the OneBox result, guess what! The regular search results are there. So if the user actually wanted information ABOUT the domain, they get that too.

Also, you do not "need" any fallback. Your new address box behavior is NOT, repeat NOT, doing what search engines do. I hope my explanation clears that up.

(In reply to deiwulf from comment #25)

At least there's "Show search suggestions ahead of browsing history in address bar results", which should've been enabled by default to save so much unnecessary frustration for people.

Seems like this is backwards...? It would be pessimal for me if Firefox went off and did a search query and pushed my history or open tab results out with search results. I live by my browser history. It's my offline memory. I highly value having history and other tabs -- and zero search results or other noise -- in the address dropdown. I have somewhere north of 4000 tabs open. I really really need open tabs in that list. And if all I remember of some page I've visited before is the title, then I very much appreciate the history entries. I can get search results from a search engine. I cannot get history or bookmarks or open tabs from a search engine.

I came across the above-mentioned option while looking for a way to turn off search entirely, and was glad to find it unchecked. Please don't take it away in the false belief that people only want search results!

I haven't seen a way to disable the "default search engine". I may go prowl the config...

(In reply to Marco Bonardo [:mak] from comment #8)

(In reply to cleek from comment #7)

"The control in the homepage never really allowed to enter an address, it was a straight search"

Exactly! That's what was useful about it.

There are many workaround to that, CTRL+K as suggested by Drew, or just start your search with a question mark, or type "@engine word".
Why typing "CTRL+K Question" or Typing "Question?" or "@engine Question" on a (small) bar would be better than clink this (big) canvas area "Question"?

The little search bar control is too small, so the homepage control made for a much better search UX.

The search bar width can be customized, in Customize just drag the separator between urlbar and search bar. And this is also one of the reasons for which the urlbar is better.
(Ironically, the urlbar is intended to be be more than ulrbar but still mis-named as urlbar. But this is a different bug painted as feature).
I was not able to rezise the search bar. There is no separator between urlbar and search bar. In fact the separator has been completely removed.
It is not the width that is too small. The height is also to small. Would be possible that on the new tab/windows the urlbar and/or search bar (accessible also via CTRL+K key) to be on a completely separate bar to cover some quarter of the windows size?

Then you should get rid of the homepage control. You've already completely destroyed its functionality. Why not just delete it?

Because, as I explained, users have been trained by Search Engines to confuse the browser (or the whole Internet concept) with the engine, and due to that training we need this fallback control. We'd be happy to remove that field if that wouldn't disrupt users.
The fallback does not work and the disruption already occurs.

(In reply to Harry Twyford [:harry] from comment #2)

This is intended. It is part of a new feature called "handoff" enabled in bug 1699834. We want to direct users towards searching in the address bar. We are handling one of the repercussions of this in bug 1645293.

*** This bug has been marked as a duplicate of bug 1699834 ***

I've set browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar to false and everything is how I want it.

(In reply to Harry Twyford [:harry] from comment #2)

This is intended. It is part of a new feature called "handoff" enabled in bug 1699834. We want to direct users towards searching in the address bar. We are handling one of the repercussions of this in bug 1645293.

*** This bug has been marked as a duplicate of bug 1699834 ***
I kindly ask to explain why (you want to direct users toward the address bar )?
For me: it is easier to click on a big area on canvas rather than on small area on top of the screen where address/search bar is.
Also closing this as "Won't fix" instead of "duplicate" of a work to achieve something else reflects better the case.

There have been dozens of support questions about this in the past few days.

I'm sorry but I must ask you to stay on track and avoid posting comments that don't add new technical insight to the discussion.
Telling us we "don't learn" or similar things is not tolerated, this is a bug tracker we use for everyday work and we'd like to discuss in a respectful way with you. Further similar comments may force us to close the discussion, that we always prefer to avoid, because we like working in a transparent and honest way.
Also please don't ping us, unless there is a critical concern that must be address asap, we are already automatically pinged by Bugzilla at every comment you make, so you double the notifications we get by doing that.
Thank you for your understanding.

Now back on the topic, the urlbar can work exactly like the old field, thanks to Search Mode, it's a matter of configuring things as you prefer them, there's search buttons at the bottom of it to activate search mode, as well as CTRL+K or ?, as said (not very discoverable). The separated search bar is also available. You pointed out a couple reasons that may not satisfy you, we'll keep those in mind. Since this is a change, it is expected that users may be confused by it at the beginning, as any other UI change, it's unfortunately a consequence of muscle memory.

We expect to be able to provide the same level of functionality as before, if there's some functionality loss we'll work on it, as we always did.
As we said, there's a bug if you set keyword.enabled to false: Bug 1713827. Once that is fixed the functionality will be identical. So this group of users for now can flip the pref and we'll provide a solution asap.

We are also evaluating how to handle the disabled search suggestions case in bug 1645293. This is tricky because of privacy implications, would you be ok getting suggestions after you set a checkbox that states "I don't want suggestions"? Probably some users would not like that. Using the same solution as keyword.enabled would technically be sound imo, but we must agree with our product manager over that solution.

If you have ideas to improve the product, please post them to https://ideas.mozilla.org so that the community can ponder over those, bugzilla is the right place to report bugs and regressions, but it's not a great design tool for new ideas.

was just updated to Firefox/89.0 today
Windows 10, 64 bit

I was directed to this when trying to put in what was tagged a duplicate thread.
This is completely ruining the functionality of the search bar in the new page tab. Worse, it's blocking me from going to the google web page., it just kicks me up to the bar. What is going on with these changes when the old one worked fine?

(In reply to thatslowtypingguy from comment #49)

I was directed to this when trying to put in what was tagged a duplicate thread.
This is completely ruining the functionality of the search bar in the new page tab. Worse, it's blocking me from going to the google web page., it just kicks me up to the bar. What is going on with these changes when the old one worked fine?

Can you tell us more about your case? did you set keyword.enabled = false in about:config in the past? Otherwise, how does it disallow you from going to Google? Did you see the bugs I pointed out in comment 45, do they apply to your case? Thanks.

My bug report was marked as a duplicate of this one.

The core of the problem is that the "Search with Google" control on the Firefox home page no longer worked.

I tried control-K as suggested above and it did not restore focus to the Google search control.

The URL bar at the top still says "Search with Google or enter address" despite the fact that searching in the URL bar has been disabled.

On your advice I have customized the toolbar to remove the small search bar at the top.

I set browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar to false

as suggested in Comment 40 above and Firefox's search functionality was restored. This is the solution.

(Probably should be the default.)

(In reply to Marco Bonardo [:mak] from comment #45)

If you have ideas to improve the product, please post them to https://ideas.mozilla.org so that the community can ponder over those, bugzilla is the right place to report bugs and regressions, but it's not a great design tool for new ideas.

Is there a specific discussion about this feature, where we should post?

I do not have a "new Idea" for altering this new feature. What I posted was a potential security issue caused by this change, i.e. opening a potentially dangerous URL rather than searching for information about it. I also provided an explanation of why this change is not equivalent to what search engines do -- search engines do not open URLs entered as a search query. That seems more like a bug report. Providing special keystrokes, that could easily be typo'd, to cause search, not block it, is not a solution.

If this is more a bug than a feature request (as it seems to me), does it belong somewhere else? People have been posting here, but this bug appears to be a duplicate of this other: https://bugzilla.mozilla.org/show_bug.cgi?id=1699834

https://mozilla.crowdicity.com/post/722289(In reply to Pat Tressel from comment #54)

(In reply to Marco Bonardo [:mak] from comment #45)

If you have ideas to improve the product, please post them to https://ideas.mozilla.org so that the community can ponder over those, bugzilla is the right place to report bugs and regressions, but it's not a great design tool for new ideas.

Is there a specific discussion about this feature, where we should post?

I do not have a "new Idea" for altering this new feature. What I posted was a potential security issue caused by this change, i.e. opening a potentially dangerous URL rather than searching for information about it. I also provided an explanation of why this change is not equivalent to what search engines do -- search engines do not open URLs entered as a search query. That seems more like a bug report. Providing special keystrokes, that could easily be typo'd, to cause search, not block it, is not a solution.

If this is more a bug than a feature request (as it seems to me), does it belong somewhere else? People have been posting here, but this bug appears to be a duplicate of this other: https://bugzilla.mozilla.org/show_bug.cgi?id=1699834
Rather than polluting this bug that have already a resolution "Won't fix" I followed the suggestion and created a new "idea":
https://mozilla.crowdicity.com/post/722289.
Unfortunately, the idea is "currently awaiting moderator review". Would be possible for a moderator to whitelist a proper advocacy channel? Thank you.

(In reply to hawkeye7@gmail.com from comment #53)

I tried control-K as suggested above and it did not restore focus to the Google search control.

CTRL+K will either go to the separate search bar (if present) or put the urlbar in search mode, that is 100% the same as using the field in the new tab page.

The URL bar at the top still says "Search with Google or enter address" despite the fact that searching in the URL bar has been disabled.

Searching in the urlbar is not disabled, unless you did it by setting keyword.enabled = false.

I set browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar to false

That pref will be removed once bugs are addressed.

(In reply to Pat Tressel from comment #54)

I do not have a "new Idea" for altering this new feature. What I posted was a potential security issue caused by this change, i.e. opening a potentially dangerous URL rather than searching for information about it.

I don't think that's a critical concern, users can at any time type a url in the urlbar the same way as in this field, and searching doesn't ensure additional security on zero-day or recent threats. Non-recent threats are likely to be catched by SafeBrowsing already. Assuming that a non-technical user would type a url, check all the results and figure it is unsafe is a huge guess.
It's also still possible to search a url with the various ways we already discussed in this bug, so there's no lack of such functionality.

I also provided an explanation of why this change is not equivalent to what search engines do -- search engines do not open URLs entered as a search query.

It doesn't want to be 100% equivalent, it wants to be more useful to most users. Of course it's a change for someone, every change is.
Again, I'd suggest to check whether your case is already included in the 2 bugs we are tracking (see comment 45), because in most cases after we fix those, the functionality will be very close for everyone.

My idea is still not whitelisted, there is no other slightly similar idea so I'll post it here.
Apparently Mozilla decide close as duplicate to this bug (Won't fix) anything trying to report many different separate problems:

1. Awkward jump from search box to " Search and address bar".
   In Edge there is:
   edge://settings/search -> Search on new tabs uses search box or address bar -> dropdown option between "Search Box (Recommeded)/Address Bar".
   Firefox is lacking the option "Search Box (Recommeded)".
   Mozilla call this a "feature" some users call this a "bug". Possible workaround: install a New Tab add on to jump to your search engine home address.
   What's the course of action for this issue?

Force combining search and address exhibits two different issues:
2. Lack of ability to use the address bar as ... address bar only. The address bar would may fallback to search engine use leading to a privacy issue:I would not want to leak on a search engine "SomeMisspeledIntranetURL/SensitiveInformation/Killroy_was_here".

3. Improper way of perform a "search only". Let aside the awkward focus jump, when trying to search something Firefox will "load this address or otherwise search the term". This pose a serious security concern.
   Even if any of this are not new, maybe it is about time to fix it / let the user a choice...

The comment 45 suggest that 2 (and possible 3) will be at least partially fixed in 1713827 (by using keyword.enabled = false).
However, I'm not sure I understand the scope of 1713827. Changing something on about:config implies "Accept the risk and continue". Will be a special setting to have keyword.enabled = false? e.g. "about:preferences#search (*) Add search bar in toolbar"

Lastly, I think the wording on preference page have to be in sync with the latest change of behavior (see bug 1715354). We will have a better understanding what would be a bug and what an enhancement request instead.

(In reply to Tudor Florea from comment #58)

1. Awkward jump from search box to " Search and address bar".

We don't think it's a critical problem atm. It is different from the past, thus it makes people uncomfortable as most ui changes.
Note it's possible to hide the Search field from the New Tab page if one finds it annoying/useless.
We are still collecting feedback anyway.

2. Lack of ability to use the address bar as ... address bar only. The address bar would may fallback to search engine use leading to a privacy issue:I would not want to leak on a search engine "SomeMisspeledIntranetURL/SensitiveInformation/Killroy_was_here".

You can already set keyword.enabled = false to obtain exactly this. We are aware of this request by users and we'd like to do better. We are evaluating to add a clear-cut preference to split the urlbar functionality, where by default it will be just a urlbar, but you can convert it into a search bar on demand. That's still in the brainstorming phase, but as I said with a couple settings you can already do that.

3. Improper way of perform a "search only". Let aside the awkward focus jump, when trying to search something Firefox will "load this address or otherwise search the term". This pose a serious security concern.

I answered in comment 57. I don't think there's any serious concern, because the urlbar is always available to type a url anyway, and there's other mitigations.

However, I'm not sure I understand the scope of 1713827. Changing something on about:config implies "Accept the risk and continue". Will be a special setting to have keyword.enabled = false? e.g. "about:preferences#search (*) Add search bar in toolbar"

I think I just answered this, we are brainstorming a visible solution to this, but we're not ready yet. So for now the only solution is keyword.enabled plus search mode. I must note this is an improvement from the status quo, in the past it was a lot more complex to have separation of concerns in the urlbar alone.

Lastly, I think the wording on preference page have to be in sync with the latest change of behavior (see bug 1715354). We will have a better understanding what would be a bug and what an enhancement request instead.

Yes, we'd like to completely revise all the search related preferences, because honestly they are hard to grasp. We didn't have the time yet.

What's truly puzzling is: why do the automagic-unexpected focus change to the URL box for a search when there's already a search box right next to the URL box?

If you insist on keeping the edit control labeled "Sea

(In reply to Marco Bonardo [:mak] from comment #59)

(In reply to Tudor Florea from comment #58)

1. Awkward jump from search box to " Search and address bar".

We don't think it's a critical problem atm. It is different from the past, thus it makes people uncomfortable as most ui changes.
Note it's possible to hide the Search field from the New Tab page if one finds it annoying/useless.
We are still collecting feedback anyway.

Well, I can't speak for anyone else but the title of the bug, the 10 duplicates and comments that keep being tagged as advocacy gives at least a clue...
Interesting enough no https://ideas.mozilla.org in this area passed the moderation. I would prefer to discuss the feature there.
Firefox wants us to use [ ..search box? ] and instead of a huge box containing in the middle of the screen:

[ Why Firefox wants us to use a tiny box instead of search box? ]

Would be possible to make the address bar/search bar(s) on the new tab to be really HUGE (like half of the screen) and easy to hover/paste on the new tab? This might be better than stealing the focus, while preserving this new and interesting concept of ... just use the address bar.

(In reply to cleek from comment #60)

What's truly puzzling is: why do the automagic-unexpected focus change to the URL box for a search when there's already a search box right next to the URL box?

By default it's not there, must be customized in by the user. If you're saying we should hand-off to that other field instead IF it's present, we don't want to do that because we are fully focused on improving the urlbar and we'll provide new features in the urlbar, not the other field. That field is used very rarely among Firefox users.

(In reply to Tudor Florea from comment #61)

Would be possible to make the address bar/search bar(s) on the new tab to be really HUGE (like half of the screen) and easy to hover/paste on the new tab?

It was one idea, one of the possible outcomes of the previous address bar aspect (so called "megabar") was that if it was noticeable enough, we could have completely removed the new tab page search field. Data demonstrated we cannot remove that field though.
Anyway, as you can imagine someone would not like a huge urlbar, we got some indication of that too, because we also tried it.

(In reply to Marco Bonardo [:mak] from comment #56)

Searching in the urlbar is not disabled, unless you did it by setting keyword.enabled = false.

I don't remember doing this; was it triggered by the preference for a separate search box?

I set browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar to false
That pref will be removed once bugs are addressed.

Okay. I understand now that this is part of a UI change to overload the URL box.

My requirement is simple: I don't want a search engine invoked unless I specifically request one, even (especially!) by accident.
keyword.enabled = false should do the trick, unless the plan is to remove it too. (It would be nice if it was accessible through the GUI.)

Is there an option to set no default search engine? That would be useful.

(In reply to Marco Bonardo [:mak] from comment #57)

(In reply to Pat Tressel from comment #54)

I do not have a "new Idea" for altering this new feature. What I posted was a potential security issue caused by this change, i.e. opening a potentially dangerous URL rather than searching for information about it.

I don't think that's a critical concern, users can at any time type a url in the urlbar the same way as in this field, and searching doesn't ensure additional security on zero-day or recent threats. Non-recent threats are likely to be catched by SafeBrowsing already. Assuming that a non-technical user would type a url, check all the results and figure it is unsafe is a huge guess.

Did you read my explanation of what a search engine does when it receives text with periods in it? Because yes, absolutely 100% it "protects" against unwanted opening of the site...because the search engine does not open the site. It is the act of opening the site that introduces the security hole. This is nothing whatsoever to do with how savvy users are. I did not say they were doing a search to see if the site delivered malware, because that is completely avoided if the site is not opened. I did not say that they were planning to open the site if they search results indicted it was "safe". They may not ever ever ever intend to open that site. They just may want to find out what it is. Forcing upon them the opening of a site that they wanted and intended to search for is the security hole. I am running out of ways to say this...

As I also said, the workaround is to artificially assure that searches are done directly on a search engine by opening that search engine first. Never type anything in the address bar that one wants to be sure isn't treated as an URL and opened. That is what I am now doing.

(In reply to hawkeye7@gmail.com from comment #65)

(In reply to Marco Bonardo [:mak] from comment #56)

Searching in the urlbar is not disabled, unless you did it by setting keyword.enabled = false.

I don't remember doing this; was it triggered by the preference for a separate search box?

no, the only way to set that pref is by the user.

My requirement is simple: I don't want a search engine invoked unless I specifically request one, even (especially!) by accident.
keyword.enabled = false should do the trick, unless the plan is to remove it too. (It would be nice if it was accessible through the GUI.)

that pref is not exposed through the gui yet because as-is it's a footgun, the user can easily cut themselves out of search not understanding how it works. We'll look into exposing something easier to understand in preferences in the future. A default search engine is mandatory to exist anyway.

https://mozilla.crowdicity.com/post/722881

I also submitted a bug, now marked as duplicate.

The behaviour of different searches in different boxes is not the key issue. To me, it is that if I start typing in the very prominent "enter your search here" field in the centre of a new tab page, my cursor jumps, and this is very unusual and unexpected.

Either have a search box which behaves like a search box, or remove it and tell people to use the separate search and address bar option in preferences.

You can remove it already, from the New Tab Page options.

My bug was marked -- incorrectly I think -- as a duplicate of this one. My bug is that when the search bar is separated from the url bar, handoffToAwesomebar should shunt to the search bar, but instead shunts to the url bar. And it's doubly bad with keyword.enabled = false because then you get a 404 (Bug 1713827).

Also, I know you don't like hearing this, but maybe if enough people say it bluntly you'll finally listen: handoffToAwesomebar is a terrible idea. Using the url bar for search is a terrible idea. These things shouldn't be defaults. They probably shouldn't even be optional features.

The url bar should be for urls (only!). The search bar should be for searches (only!). The new tab search widget should be for searches (only!), and without any of this focus-jumping crap.

It should be telling that not one single person has responded to your comments in this bug thread with "OK, I understand now, and now that I understand I see how this is a good change." Instead, the overwhelming response has been to tell you that this is a profoundly dumb idea. Because it is. It's time to swallow your damn pride and admit handoffToAwesomebar is a bad idea that needs to be scrapped.

(In reply to cwbussard from comment #74)

My bug was marked -- incorrectly I think -- as a duplicate of this one. My bug is that when the search bar is separated from the url bar, handoffToAwesomebar should shunt to the search bar, but instead shunts to the url bar.

The urlbar is our target, we plan to change its behavior with keyword.enabled in Bug 1713827, but not to focus the separate search bar. You can use CMD (or CTRL) + K to do that.

The url bar should be for urls (only!). The search bar should be for searches (only!). The new tab search widget should be for searches (only!), and without any of this focus-jumping crap.

We know that there is a group of users that like that separation of concerns, it's something we have worked on, and that can already be achieved today with keyword.enabled and the new Search Mode in the urlbar. Our plan long term is to provide a better visual option that will allow to achieve it more easily (without having to play with hidden options).

My comment protesting this was hidden. Who do I call to discuss this severe usability problem?

When I click on the search area, I want to search. If I type in a URL there, I want my URL sent to the search engine. I don't want to go to the website with that URL. I don't want my cursor to be moved to the "awesome bar". I want to be able to type in my search, in the text box labeled: "Search".

(In reply to Marco Bonardo [:mak] from comment #72)

You can remove it already, from the New Tab Page options.

I did, but my point remains. Typing in one place that jumps to another is very unexpected and should not happen. To then uninitiated, it looks broken, or like they've done something wrong.

Having a search bar on the new page tab is a default option, not an experimental feature, and should behave in a boring and predictable way or it should be removed (I agree it duplicates existing functionality).

(In reply to Clark C. Evans from comment #76)

When I click on the search area, I want to search.

If you set keyword.enabled to false you should refer to bug 1713827.
If you disabled search suggestions in the urlbar you can refer to bug 1645293.
Otherwise, you're in the right place, and for now there's no plan to revert the change, we read every single comment here and on other forums anyway, so you can be sure we got your feedback.

(In reply to cjahn50 from comment #19)

I turned off the handoff to the address bar and can now search as I did before in the NTP.

I used about:config and set browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar to false.

Thank you. Now the web search bar is behaving like it should be.

Set browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar to false.

Thank you for this work-around.

I would wish to report that less technical colleagues have this same issue. However, their response isn't to file a ticket to find the magic incantation. Instead their response is: "I should just use Chrome". Self-inflicted usability defects such as this design decision are not helping Firefox adoption.

(In reply to Clark C. Evans from comment #84)

Set browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar to false.

Thank you for this work-around.

I would wish to report that less technical colleagues have this same issue. However, their response isn't to file a ticket to find the magic incantation. Instead their response is: "I should just use Chrome". Self-inflicted usability defects such as this design decision are not helping Firefox adoption.

As I said in comment #78 above,

Having a search bar on the new page tab is a default option, not an experimental feature, and should behave in a boring and predictable way or it should be removed (I agree it duplicates existing functionality).

I like to add here as already stated in bug: 1718664 that for me this is a safety issue, as the UI design doesn't follow standard design rules.
It's not the question whether or not the entry field is "awesome" or not, the point is that the focus NEVER should jump out of the input field the user set the focus on. This is a behavior only to be expected from malware and so it alerts the user.

1. The solution I would suggest is to remove the input field from the start page, when the "awesome" searchbar is active.
2. make an menu point and / or icon to toggle this "awesome" feature. (not hide it in the settings 99% of the users don't know about)
3. inform the user about such a change due to an firefox update.

reading through the comments here it seem I'm not the only one getting the creeps with by this change.

Setting browser.newtabpage.activity-stream.improvesearch.handoffToAwesomebar to false is an awesome workaround.
Unfortunately does not work for private windows. Any hints on this?

There's no pref to control this behaviour in private windows. Per comment 56, that pref will also be removed now that we've worked out the major reported issues (bug 1713827 and bug 1645293). We're still working on bug 1713953.

Can I ask everyone to calm down a bit please?
The search bar in the new tab page exists only as a fallback, our main search access point is and will continue be the urlbar, the urlbar can help you achieve everything you wish better, and we are happy to gather your constructive feedback to improve it. Adding more comments in closed bugs is unlikely to help achieve your goal.

(In reply to Marco Bonardo [:mak] from comment #6)

The control in the homepage never really allowed to enter an address, it was a straight search, that means if you typed an address like "facebook.com" into it, you'd have ended up searching for "facebook.com" instead of visiting it. That unfortunately happens a lot to our users because most of us have been trained by search engines to use and (ab)use that field, to a point where many people confuse the browser with the search engine.
The urlbar has a lot more features than a simple field, it can correct mistyped urls, search, provide help and soon it would provide even more utility, thus we feel like the change, while may break some workflows, will be a tangible improvement long term.

Hi Marco,

sorry to reply on an old post, but you are completely wrong on this.
You will agree, that nothing hindered the user from entering to type an URL in the search bar. The result was that the URL was handled by the selected search engine and the search result contained the clickable link with a lot of additional information (depending on the search engine).
I ask some non technical Firefox users in my surrounding about there expectation an more than 50% said, that this how it should work.
Where can I find the Mozilla user clinic results on this?

Working against the user expectation will always result in bug reports for an UX. An UX should always be

• simple
• honest
• predictable
• effective
• pleasing

And I agree that it is an clicking on an URL link generated by an search engine is a security issue, if you cannot trust the search engine provider. But this is the wrong way to take the dumb user on reins to lead him in the land of thoughtless surfing. ;-)
If the search bar should not by used - remove it!
Than give an information to the users why and ask for feedback. This would be the way for an OPEN system for mature users.

Regards,
Lubensius

That is interesting feedback, but it's not new. We answered multiple times to each of those concerns, I don't think repeating the same things again would be a good use of this bug tracker.
The address bar allows to do all you asked for, check previous comments. Feel free to file enh. requests or ideas if some functionality is hidden or undiscoverable.

(In reply to cwbussard from comment #97)
Although I'm extremely disappointed by how Mozilla is handling this, a proper language should be always used.
For further reference: the next workaround I found is: on the new page you simply click on the search bar and hit enter and you will have a new tab with the homepage of your search engine: then you can search without risking to load page.
However this interfere with another bug not fixed for more than 9 years: https://bugzilla.mozilla.org/show_bug.cgi?id=248955
Is this "allowed"?

Sorry Marco,

I have to apologize, I did not want to heat up an cold thread.
I'm actually aware of the awesome features of the new address bar and all the work-a rounds (10+) experienced users can do to have it in their favored way. But this was not what I was writing about.
I was writing about a bug. A bug confusing all those non experienced users, which never heard about:config and would be scared off by the disclaimer if the would ever go to about:config.
The bug is, I repeat it here, is:

1. user clicks in an entry box which says "search the web"
2. cursor is in the entry box
3. user types the first letter
4. cursor is in the address bar
5. user is confused

So what is the problem? -> There is a entry box which cannot be used -> Solution: remove it.

So let's assume the box is removed.
The user will either
-> use the awesome bar and is happy
-> navigate to let's say "www.google.com" and is ....
-> find the setting "add search bar to symbol bar" and --- well there we have the next bug.

I'd like to comment on one aspect of the challenge: the duality of a text input that is either a "Search" or a "URL". What if, when you activate the edit area, there is a small slider/toggle between the two modes? I could default to "Search" for example, but if you click/slide it, it can be converted to a URL. It could also remember which one you used last, URL or Search; or, by right clicking, a user could set the preference for which is the default.

The second aspect of the challenge is the duplication between the toolbar and the "new" page. I think you could just leave both, each with the same toggle. Don't do any focus magic. What would make it useful though is if the "new" page were a multi-line text area with wrap enabled. So many cases I want to type/edit a URL or search string... however, I can't do it in the toolbar since there's not enough room.

Regardless, the work here isn't done. I think Mozilla should go back to the drawing board, since it's a usability problem.

(In reply to Clark C. Evans from comment #100)

I'd like to comment on one aspect of the challenge: the duality of a text input that is either a "Search" or a "URL". What if, when you activate the edit area, there is a small slider/toggle between the two modes? I could default to "Search" for example, but if you click/slide it, it can be converted to a URL. It could also remember which one you used last, URL or Search; or, by right clicking, a user could set the preference for which is the default.

The second aspect of the challenge is the duplication between the toolbar and the "new" page. I think you could just leave both, each with the same toggle. Don't do any focus magic. What would make it useful though is if the "new" page were a multi-line text area with wrap enabled. So many cases I want to type/edit a URL or search string... however, I can't do it in the toolbar since there's not enough room.

Regardless, the work here isn't done. I think Mozilla should go back to the drawing board, since it's a usability problem.

Clark, I totally agree. Have you check the behavior, when "search box in toolbar" is checked in the search settings? (maybe called different I have re-translated from my language) It goes in the right direction, although it is messed up because the address bar now has a search symbol and locks identically to the search box.

(In reply to lubensius from comment #99)

-> find the setting "add search bar..." --- well there we have the next bug.
Here we are; not one but three bugs:

1. "The search bar in the setting bar is too sma.."
2. The input text size is small. That is affecting people with visual impairment. A way to fix this is that the zoom level should be applicable to url and search bar as well. That will affect the bug 1 above: the bar will become "...aller". On the other hands I'm aware that such a change will upset others. Is there any other solution? Possible. I won't advocate.
3. Bug 248955: The seach text contents is not cleared after the search. For instance my search bar shows me on the new tab:
   "Jumping focus is awkward". Nobody cared this for 9 years. Was that box ever used? That bug became more important now because this is the "standard" way of searching...

Should I open 2 separate bugs? is anyone intend to fix the 3rd one?

(In reply to lubensius from comment #99)

The bug is, I repeat it here, is:

1. user clicks in an entry box which says "search the web"

The box says "Search the web or enter an address".

4. cursor is in the address bar
5. user is confused

If this is an actual concern (we don't have strong evidence about it so far, it will require dedicated user studies) there are surely ways to reduce that confusion visually.

(In reply to Tudor Florea from comment #102)

1. "The search bar in the setting bar is too sma.."

What do you mean? The search bar on the toolbar?
We tried to make the urlbar larger previously and some users went very vocal for us to stop doing it.
Sounds like another case where we can't satisfy everyone.

2. The input text size is small. That is affecting people with visual impairment. A way to fix this is that the zoom level should be applicable to url and search bar as well. That will affect the bug 1 above: the bar will become "...aller". On the other hands I'm aware that such a change will upset others. Is there any other solution? Possible. I won't advocate.

There is an experimental pref browser.urlbar.experimental.expandTextOnFocus to increase the size of the text, but I can't promise it will stay, it's very experimental and unsupported. Fwiw you can play with your OS text settings to find a good compromise.

3. Bug 248955: The seach text contents is not cleared after the search. For instance my search bar shows me on the new tab:
   "Jumping focus is awkward". Nobody cared this for 9 years. Was that box ever used? That bug became more important now because this is the "standard" way of searching...

While it's being maintained, the separate search bar won't get new features, we're concentrated on the address bar as our single Search Access Point. If you have suggestions to improve searching from the Address Bar please let us know.

(In reply to Marco Bonardo [:mak] from comment #104)

(In reply to Tudor Florea from comment #102)

3. Bug 248955: The seach text contents is not cleared after the search. For instance my search bar shows me on the new tab:
   "Jumping focus is awkward". Nobody cared this for 9 years. Was that box ever used? That bug became more important now because this is the "standard" way of searching...

While it's being maintained, the separate search bar won't get new features, we're concentrated on the address bar as our single Search Access Point. If you have suggestions to improve searching from the Address Bar please let us know.

I never use address bar for searching and don't intend to start doing so. Address bar is for URLs, there must be a separate field for searching (and only searching) to prevent confusion and misinterpretation, as evidenced by multiple commenters here and in the duplicate bugs. If you're going to to remove the separate search field then I'll probably have to use another browser.

I never said we're removing it, I just said it may not get new features.

(In reply to Marco Bonardo [:mak] from comment #106)

I never said we're removing it, I just said it may not get new features.

You said you were "concentrated on the address bar as our single Search Access Point." Which implies the other fields are considered redundant and potentially will be removed, e.g. due to resource constraints.

I'm saying I don't accept the address bar as a single access point.

I'm sorry, I meant "main" but I typed "single", I'm not English mother tongue.

(In reply to Marco Bonardo [:mak] from comment #104)

We tried to make the urlbar larger previously and some users went very vocal for us to stop doing it.

There is no surprise here. The display canvas is expensive. It should be used by the contents and not by the browser items (like tab bar). ( off topic: the tab bar size just become bigger; and I don't like that. I want more of the page instead).
The problem that you admit to exist can be easily fixed. In fact was fixed for the last 20 years or so. A "fix" suggestion is in comment 94 or in various forms in ten other hidden comments or duplicate bugs.

We're concentrated on the address bar as our *Main Access Point.

What do you want to achieve with this? How we can be can we benefit from this?
You should know by now what we cannot achieve with this.

If you have suggestions to improve searching from the Address Bar please let us know.

That an impossible task:
You constantly get the feedback that combining the two (address and search) would make unreliable and unsafe either one and you constantly hide out those suggestions as advocacy...

Here is another kind of suggestion:
Add two pictograms: "runner"/"magnifier" in the box. One box, two different functions. One would have to click the right pictogram for the right function.
This should be (also) in the middle of the new page. Jumping focus from the center of the screen to the a margin is ...erm .. well... edgy .

Can anyone see this idea?
https://mozilla.crowdicity.com/post/720724
I've been told after two months that my "idea" of bringing back the search functionality "is now posted to the public for votes and comments" but I my own comment is moderated:
I'll put that comment here:

I do not understand how this is supposed to work.
The idea is really not yet "posted to the public". I can only see this after being logged in.
Some 20 bugs has been closed as duplicated to this one:
https://bugzilla.mozilla.org/show_bug.cgi?id=1707701
There we were constantly told to use this forum to present our "ideas" rather than polluting a bug tracking system. Various people said there the "idea" is really to bring back the old search functionality. I'm not sure those people can see the discussion [there]. I don't see anything similar or related [there].
Who is supposed to see this idea?
Something is wrong with how Mozilla is trying to gather (or filter?) the feedback.
On the other hands, after 2 months of destroying the browser there is at least a sign that something is happening.

I'm sorry about your troubles with the ideas website, I can confirm that Bugzilla often is not the right place for feedback, and I hope ideas becomes the right place for feedback.

Firefox 92 contains some fixes to the search behavior, that should now work closely to what you expect. The only major difference should be trying to search for strings that look like domains (like "mozilla.org"), for which enforcing a search requires to prepend a question mark. Any other strings should be searched exactly like before.

cjahn50

Thanx for the about:config trick for this dumb address bar 'feature'.

I'm going to say this once, to any mozilla guys listening.
I downloaded and was using the very first NCSA Mosaic v0.1 the same day it was available. By that afternoon I'd written my first web page with inline graphics, our company logo. I believe that was in 1993.
That means I've probably been using browser tech since most of you were in diapers.
I was already in my TENTH year of computer technology support in 1993. There WAS no CERN WorldWideWeb when I started in this business. There was no NeXT around to MAKE a NeXT Cube to run the first web server on.

And I can tell you categorically and without fear of contradiction that the ONLY correct response from Mozilla (when they were made aware of this 'non documented feature' regarding the address bar search), the only correct response was (and still is) "You're right, we're wrong, and we'll switch it back."

Having a useless control in the middle of a page that YOUR OWN SETUP PAGE is supposed to turn on has got to be the worst example of a 'non documented feature' I have ever seen.
"non documented feature" is what real programmers call "bugs" that they've been called out on by endusers who are the final arbiters of what really works, and what really doesn't.
Why the kjhgf do you think 'beta test' users are people who DON'T work for your company? Because they don't make decisions about software design based on the presumption of ignorance on the part of their own kdjf customer base.

Let me please see if I can lend a little light here. First of all, the program is not for the programmers, but is for the users. If the users do not like something that has been changed, then it should be changed back to what it was. Period. It is not rocket science.

Thru-out this thread we have heard over and over that search engines have trained users. That is not true. We need to stop assuming that to be so.

A screen that offers something and than takes it away is a broken UI. Period. Please fix it. And by "fix it", I mean to put it back like it was.

I do not understand the reticence of programmers to listen to users. I also do not understand the need to make changes to existing good code when there are so many real problems needing attention. Simple and intuitive design is the standard, and almost all software fails in this regard. This issue is a clear example of that failure.

Again, please put it back like it was.

Thank you.