Closed Bug 441208 Opened 16 years ago Closed 5 years ago

site-specific dynamic search plugin and change of method of adding auto-discovered search plugins

Categories

(Firefox :: Search, enhancement)

3.0 Branch
enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 360907

People

(Reporter: keith.mcauley, Unassigned)

Details

(Whiteboard: DUPEME?)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

It's quite a hassle that you have to permanently add a site's search plugin before you can use it, especially because you don't know just what, specifically, the site's search field will do until you use it. This is especially a problem when a site has options on its HTML search field, or even multiple search fields, that it can't expose to the toolbar search, and thus has to guess at some "useful default" options.

I propose that, instead of the current "Add X" menu entry on the search plugins dropdown list, there instead be a "dynamic search plugin." That is, it will appear, whenever a search plugin has been auto-discovered from a <link rel="search"> tag, after the horizontal rule in the list, that whatever search plugin has been discovered has already been installed and is ready to use. It may be necessary to pre-fetch the search plugin XML files to achieve this, if you want to use the search plugin's real icon, or the dynamic plugin could be more statically displayed as the site's favicon with a small search overlay icon (similar to the shortcut overlays in the WIMP metaphor.)

When you first attempt to actually perform a search using a search plugin displayed dynamically by this "dynamic search plugin" menu entry (that is, every time you first use the dynamic entry after auto-discovery of a new search plugin, not just the first time you use the menu entry), that search plugin's required data will be downloaded just-in-time and stored temporarily. It will not be added to the search plugins list or dropdown yet.

As long as the "dynamic search plugin" menu entry is focused, however, there will be some extra bit of chrome--I'm imagining something similar to the bookmarking star in the smart location bar--located in the toolbar search box. This button will permanently add the current auto-discovered search plugin to the bottom of the search plugins list, and make it the active search plugin rather than the dynamic entry. This button could, like the smart bar's, be displayed at all times in different visual states, and allow for things such as removing the active search plugin and configuring options (this wouldn't require any additional chrome of a search plugin option dialog--it would simply forward the user to the site's hypothetical "plugin configuration page", had it one listed in its search plugin XML, that would likely just set a cookie of search preferences that the search plugin's server-side script would refer to from then on.)

There is the additional problem of what happens when the dynamic search plugin is focused and travel to a different website. There are two obvious sub-cases:

Sub-case A: When you travel to a website with a different auto-discoverable search plugin, the dynamic search plugin entry will simply change to reflect the new discovery. The problem here is of the previously mentioned behavior where the "static" version of the search plugin will become active once it is added permanently. If users wish to use the dynamic entry for long periods of time, they will find this behavior grating. Perhaps there could be a preference in the Options dialog as to whether the dynamic search menu item will remain focused after you add the item or not, if a good default behavior cannot be determined for this case (I have doubts as to whether all that many people will really use the dynamic plugin entry for long periods. This would require user testing.)

Sub-case B: When you travel to a site without a discoverable search plugin, a different search plugin will have to be made active, or the search toolbar should attain a disabled appearance until one is. If a different search plugin becomes active, there would be the question of which one should be. Most users would likely want it to be the one at the top of their search plugins list, as that plugin is optimized for access both through the search plugins dropdown and by pegging the Ctrl+Up shortcut key when in the search toolbar, and therefore a user's likely default. However, they may, alternately, want the last search plugin they were using before they activated the dynamic search plugin to be returned to, especially if they only use the dynamic search plugin entry for short periods of time. Then comes the question of whether this search plugin has been permanently focused, or whether the dynamic search plugin entry will be re-activated when the users go on to visit another site with a discoverable search plugin. Users would likely find this "jumpy" behavior confusing, and so whatever "backup" plugin is activated should likely remain so.

Reproducible: Always
Version: unspecified → Trunk
Emh. I must say I'm not sure I've understood you suggestion.

What do you want is to add a way to use a search engine on a site without install it permanently?

If so, I think this is a duplicate of Bug 417717. See in particular Bug 417717 Comment #8. If so, mark this bug as duplicate of that one.
Ryan, dupe of bug 482229 now?
Whiteboard: DUPEME?
Version: Trunk → 3.0 Branch

Bug 360907 seems closer to what this is about.

Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.