If you are viewing a web page in nightly and you click the dropdown arrow for the awesome bar and then click a search one off button, it searches for the URL that is currently displayed. This seems like the wrong behavior. Either we shouldn't show the one off buttons in this cases or we should come up with something else that should be searched. Or maybe we should just navigate you to the search engine? Also note that the one off buttons don't work at all if you are on about:home. Clicking them does nothing. On about:preferences, they actually search the search engine for "about:preferences"

(In reply to Mike Kaply [:mkaply] from comment #0) > If you are viewing a web page in nightly and you click the dropdown arrow > for the awesome bar and then click a search one off button, it searches for > the URL that is currently displayed. > > This seems like the wrong behavior. why, it's exactly what you asked for, you clicked on a search button. > Either we shouldn't show the one off buttons in this cases or we should come > up with something else that should be searched. Or maybe we should just > navigate you to the search engine? that would be completely unexpected, imo. > Also note that the one off buttons don't work at all if you are on > about:home. Clicking them does nothing. this should be filed apart. > On about:preferences, they actually search the search engine for > "about:preferences" sounds correct to me.

Why should we give the user a result that means absolutely nothing? Searching on a URL will almost never produce results. Was this thought about when adding the one off buttons to the URL bar? The one off search buttons are designed to be used as the user is typing. They are useless when there is already a URL in the bar.

(In reply to Mike Kaply [:mkaply] from comment #2) > Why should we give the user a result that means absolutely nothing? > Searching on a URL will almost never produce results. > > Was this thought about when adding the one off buttons to the URL bar? Yep. It's currently working in a coherent way, clicking on a button always runs a search for what is in the input field. Very simple. Complicating that is going to give us headaches imo. For example what is a url? is "a.b" a url? what about "mylocaldomain"? what if the user expects those to work like urls since they are for him and if he visits them we go to a page? If make the buttons disappear, we will cause flicker AND suprise the user on things he thinks are not urls but we think otherwise (and viceversa). Visiting the search engine page is a possibility but it'd be surprising maybe. Plus if the previous url is a search it would be much nicer to repeat the search on the new engine. I think that for the first incarnation in the product coherency wins over edge-cases. Then we can always brainstorm and experiment with improvements.

From bug 1380538: (In reply to Stephen Horlander [:shorlander] from comment #6) > (In reply to Drew Willcoxon :adw from comment #4) > > A separate issue is what to do when a URL is selected and then you hit a > > one-off. My idea was to disable the one-offs when a URL is selected, and > > Stephen was open to that, if I remember right, but of course that hasn't > > been implemented yet. > > I don't really see this as a problem, and in fact there might be a reason > you want to search for a URL as a string and not go there directly. e.g. to > search for whether other people think a site is legitimate. I actually have done what Stephen suggests in the past, so I agree with him and Marco that we should keep the current behavior here.