Closed Bug 335827 Opened 18 years ago Closed 18 years ago

Selecting new search provider should re-search terms

Categories

(Firefox :: Search, enhancement)

2.0 Branch
All
macOS
enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX
Firefox 2 alpha2

People

(Reporter: pamg.bugs, Assigned: pamg.bugs)

References

Details

When the search box is not empty, selecting a new search provider from the drop-down list should search for them again with the new provider.
This really should only happen if the engine provider dropdown is to the right of the text, unified with the search button itself.  See beltzner's comment in the dropdown bug about Search <foo> with <bar>.  If the parsing is Search <bar> for <foo> then I don't think behaviour feels right.  (We've tossed this idea around before)
No longer blocks: 335435
Blocks: 335435
Because context search for selected text uses the current engine, whenever I use anything other than Google, I have to switch back to Google as soon as I've done my search. Add this in, and my steps to search Amazon would be

1. Change search dropdown to Amazon.
2. Type query, hit enter.
3. Select query, delete.
4. Change search dropdown to Google.

At that point, I'd probably stop using anything but Google in the search bar, and  I search Google in the addressbar anyway, so I'd actually just stop using the search bar completely.
(In reply to comment #2)
> Because context search for selected text uses the current engine, whenever I
> use anything other than Google, I have to switch back to Google as soon as I've
> done my search. Add this in, and my steps to search Amazon would be
> 
> 1. Change search dropdown to Amazon.
> 2. Type query, hit enter.
> 3. Select query, delete.
> 4. Change search dropdown to Google.

That's a valid critique--maybe we could tweak the behavior so that it only does post-search on drop-down if you haven't navigated away from the previous result page that you got?

> At that point, I'd probably stop using anything but Google in the search bar,
> and  I search Google in the addressbar anyway, so I'd actually just stop using
> the search bar completely.

It sounds to me like part of your problem is that the context menu search is tied to the toolbar searchbox setting.  (You use the urlbar rather than the searchbox for searching google, yet you need to keep the searchbox set to google for the contextual search.)  Would it be better if the context menu offered "Search for '...' in >" submenu that let you pick the engine you wanted (ordered in the same order as the searchbox options)? 

(In reply to comment #2)
> Because context search for selected text uses the current engine, whenever I
> use anything other than Google, I have to switch back to Google as soon as 

See, I see that sort of interaction as a problem right *now*. What you're really asking for is one of the following things:

1) a way to do a one-time search using a different engine in the searchbar, or
2) a way to quickly reset the search bar to use a "default" engine, or
3) a way to associate the context menu search with a "default" engine

Another proposed option would be to have a cascading menu which lets you pick the engine for the context menu search, but I'd rather avoid that if possible.
(In reply to comment #2)
> Add this in, and my steps to search Amazon would be
> 
> 1. Change search dropdown to Amazon.
> 2. Type query, hit enter.
> 3. Select query, delete.
> 4. Change search dropdown to Google.

It's certainly a valid point, but I'll just point out that we could simplify those steps a bit by selecting and focusing the searchbox after an auto-search:

1. Type query
2. Change dropdown to Amazon, prompting immediate search
3. Hit delete, since search text is already highlighted
4. Change dropdown back to Google

...all up in the top-right corner.  As opposed to now, when I guess you

1. Choose Amazon
2. Select text somewhere else and context-menu search
3. Head back to the top-right and choose Google again

Is that enough less convenient to block this change, or should we make this bug's change and think more about the general problem of how to make one-time searches with another engine easier?
Depends on: 335441
What is this optimizing for? If it's for checking the above-the-fold results without following them, I'd buy that behavior (and suggest that it might belong in a SE and SEO Pro extension), but otherwise I want focus on the page so I can scroll/pagedown.

I'm not sure how well navigation would predict whether or not it's a continued search, either: if I open three links in new tabs, versus clicking three links and then hitting Back, does that change what I want next? If I search IMDb for a movie title, because I can't remember how to spell an actor's name, does the lack of navigation mean I want to search Google Images for the movie title rather than the name?

If we were solving a big and common problem, I wouldn't be such a roadblock, but I'm pretty sure that "people don't check their searches on other engines like they should" has been the most common complaint of search professionals since before I started using the internet because people don't care, not because they have to press enter after changing a dropdown. Optimizing for something most people don't do seems like it ought to have a higher "don't mess up other things and don't be surprising" bar.
(In reply to comment #6)
> What is this optimizing for? If it's for checking the above-the-fold results
> without following them, I'd buy that behavior (and suggest that it might belong
> in a SE and SEO Pro extension), but otherwise I want focus on the page so I can
> scroll/pagedown.

One justification for this is to make the specialized engine options more useful, as discussed here:

http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/81a7c84484762e7/bccf1ca54c43e1f3?rnum=2#bccf1ca54c43e1f3

and also

http://groups.google.com/group/mozilla.dev.apps.firefox/browse_thread/thread/e5c7ee082c75f68/2f5e304339bfd7e3?rnum=1#2f5e304339bfd7e3

> I'm not sure how well navigation would predict whether or not it's a continued
> search, either: if I open three links in new tabs, versus clicking three links
> and then hitting Back, does that change what I want next? If I search IMDb for
> a movie title, because I can't remember how to spell an actor's name, does the
> lack of navigation mean I want to search Google Images for the movie title
> rather than the name?

Fair critique of that particular optimization.
 
> If we were solving a big and common problem, I wouldn't be such a roadblock,
> but I'm pretty sure that "people don't check their searches on other engines
> like they should" has been the most common complaint of search professionals
> since before I started using the internet because people don't care, not
> because they have to press enter after changing a dropdown. Optimizing for
> something most people don't do seems like it ought to have a higher "don't mess
> up other things and don't be surprising" bar.

I agree with that rationale.  (On the other hand, your problematic use case also highlighted the tying of the contextual search to the search box, which doesn't necessarily make sense as-is.)

I don't see how this is necessary if a go button is implemented.
(In reply to comment #8)
> I don't see how this is necessary if a go button is implemented.

Exactly. This used to be a real pain when there was no search button, since after changing the engine you had to click in the field and hit Enter. However, once there is a search button, this is going take one easy click, especially as the drop-down from which you choose the engine is right next to the button.

With that in mind, I'm voting against the proposed optimization.

Having said that, one potential solution to Phil's problematic use case would be a close button to clear the field, like the one recently introduced in the Places Organizer. That's just a thought, though, as I'm not sure this is appropriate in this case (it probably belongs more to "filters" which modify the current view).
The conclusion is that this is not a good idea and unnecessary to boot, so I'm WONTFIXing.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
*** Bug 225715 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.