Closed Bug 320570 Opened 19 years ago Closed 18 years ago

need short term solution to allow user to remove a search plugin

Categories

(Firefox :: Search, defect)

1.5.0.x Branch
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: beltzner, Assigned: mconnor)

Details

(Keywords: uiwanted)

Until bug 232272 is resolved (likely to be Firefox 2) a short term solution is required to help users remove unwanted search plugins. We're seeing a lot more people adding search plugins and then asking to remove them, probably due to the increased promotion of that function for the Firefox 1.5 release. 

The solution should be lightweight, require minimal l10n work (or none if we can manage that) and be easy to document so that we can create a page on addons.mozilla.org that tells people how to do it.

Some suggestions: 

1) add a delete item to context menu on the search plugin drop down

  - pros: easy, consistent with other remove metaphors in UI
  - cons: context menus on drop-downs == danger! danger! in XUL

2) support use of the delete/backspace key when a search plugin is highlighted in the drop down list

  - pros: easy, no l10n
  - cons: not very discoverable

3) add a "Remove Engines..." that shows a dialog which lists the plugins,
    allows a user to pick one and click "remove"

    .------------------------------------------------.
    | Select a search engine to remove               |
    | .--------------------------------.             |
    | | [F] Foo Search                 | [ Remove ]  |
    | | [B] Bar Search                 |             |
    | |                                |             |
    | |                                |             |
    | '--------------------------------'             |
    |                                        [ OK ]  |
    '------------------------------------------------'

  - pros: best UE and discoverability
  - cons: we'd need l10n on this starting RFN

(In all cases we need to consider the question of what happens when someone tries to remove the Google or Yahoo! search plugins, and then wants to get them back.)

Shaver points out that we should probably start doing l10n on this piece right away, as it's low cost if we end up not using it and we don't want it to become the barrier once we close on a solution. Axel, could we get you to work on the following re-usable entities?
    * "Delete %s?"
    * "Remove %s?"
    * "Remove"
    * "Delete" <-- I'll bet this one is already done
    * "Remove Engines ..."
    * "Select a search engine to remove"
Nominating for 1.5.0.1
Assignee: nobody → mconnor
Flags: blocking1.8.0.1?
Don't forget there is already an extension for this.
SearchPluginHacks - https://addons.mozilla.org/extensions/moreinfo.php?id=1563
We should get a commitment of QA to test 40 locales on three platforms for
1.5.0.1 first.
I don't have a plan for all this branch work yet, so I have a hard time telling
what we can do, but just getting strings may not work. We haven't successfully 
done a out-of-source localization attempt, too, and quite a bit of the 1.5.0.1
cycle is holidays.
I'm not too optimistic that we can control the impact here.
I think that if we really need to do this we should consider promoting an extension rather than doing it directly in our source tree.
(In reply to comment #4)
> I think that if we really need to do this we should consider promoting an
> extension rather than doing it directly in our source tree.

Extension uplift is fine, but the issue is that we make it easy like pie to install a search plugin, and hard like rocks to remove it afterwards. Release day saw enough interest in additional search plugins to totally hose mozdev, and the subsequent interest in *removing* those plugins wasn't far behind.

The goal here is to create a way to do this in our standard UI; the lack of this function is a bug, IMO.
Sure it's a bug, but that doesn't mean we have to fix it in 1.5.0.1 at a significant cost in terms of QA/l10n (we have never in the past required new l10n strings on a stability branch, and the tagging pain for build-release teams will be significant). Pushing a "remove your searchplugins" extension (even to the point of installing it automatically) seems an easier way to add new functionality here.
(In reply to comment #0)
> 1) add a delete item to context menu on the search plugin drop down
> 
>   - pros: easy, consistent with other remove metaphors in UI
>   - cons: context menus on drop-downs == danger! danger! in XUL
> 
The problem we had with the bookmarks menu is because we don't explicitly call close, but I'd probably just use the searchplugin hacks method of manually closing the popups.

Unless we used a "Delete <foo>" menuitem, we can just reuse the delete entities in browser.dtd at http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/chrome/browser/browser.dtd#158 and make this l10n-safe.

Benjamin, this fits into the reliability aspect of the 1.5.0.x branch.  Its true that we haven't done this before, but that's not an excuse for taking the easy path.  To go the extension route, either we need to change the extension, or get another 36 locales added to the extension.  Either way, its just dumping the work into a different pile, without benefit to the user.  And since we know that a large majority of users don't install extensions (nor should they, to fix this type of bug) we're still not doing the right thing.
Status: NEW → ASSIGNED
(In reply to comment #7)
> Unless we used a "Delete <foo>" menuitem, we can just reuse the delete entities
> in browser.dtd at
> http://lxr.mozilla.org/mozilla/source/browser/locales/en-US/chrome/browser/browser.dtd#158
> and make this l10n-safe.

Not. Whichever that "Delete" entity is, it may need a different grammar in the 
context of search engine plugins. Just because strings match in en-US doesn't
mean anything.
This has nothing to do with the "easy path", it has to do with the path that we promised and the opportunity-cost of this change in terms of release management: string-frozen is not a small matter when we have to branch re-tag a bunch of locales.

This is not "stability": it's a feature that we should have identified earlier and we didn't, and now it should be too late: promoting an extension is a decent way around this lack of foresight: forcing the release team to branch and tag all the locales (and forcing localizers who aren't done localizing firefox to work on multiple branches) is a cost that I don't think we can afford.
(In reply to comment #8)
> Not. Whichever that "Delete" entity is, it may need a different grammar in the 
> context of search engine plugins. Just because strings match in en-US doesn't
> mean anything.

That's the Delete item from the Edit menu/main browser context menu.  Given that it has no specific context assigned to it I would sincerely hope that the translation doesn't have a specific string that can't be reused generically, especially since the Places implementation in Fx2 will make use of those strings for non-textarea purposes.

That said, a quick search on the value of deleteCmd.label in the 1.8 l10n lxr shows that the browser.dtd translation and the editMenuOverlay.dtd (which is a generic overlay that is intended to be global and nonspecific) use the same string consistently across locales.  Given both of those matching, I feel quite safe in assuming that the string is generic and nonspecific enough to reuse.  If you could solicit feedback from the l10n community, however, since there's a chance a couple of locales may have incorrectly translated this in such a way as to be non-generic, I would be very appreciative.
(In reply to comment #9)
> This has nothing to do with the "easy path", it has to do with the path that we
> promised and the opportunity-cost of this change in terms of release
> management: string-frozen is not a small matter when we have to branch re-tag a
> bunch of locales.

You're listing reasons why this is hard, while saying its not about the easy path.  I'm not underestimating the potential scope of a change like this, I'm simply saying that it may indeed be worth a week of concerted effort from our build team/QA/otheres if that means we serve our users better for the next six months or so.

> This is not "stability": it's a feature that we should have identified earlier
> and we didn't, and now it should be too late: promoting an extension is a
> decent way around this lack of foresight: forcing the release team to branch
> and tag all the locales (and forcing localizers who aren't done localizing
> firefox to work on multiple branches) is a cost that I don't think we can
> afford.

Why should it be too late, if not because its a lot of work?  Is lacking a basic and necessary feature in a core feature acceptable?  In 1.0.x this wasn't as impactful because users commonly did clean installs, but now that we're storing search plugins in the profile the equation is different.  We screwed up in not considering that at the time, and now I think we need to pay the price, assuming that we need to impact l10n.  That, of course, is still an assumption I'm hoping isn't true.  If we can safely reuse the (should-be-generic) delete entity then its just an added bit of code and not the nuclear option.
for some reason, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051216 Fedora/1.5-3 Firefox/1.5 does not allow me to use the afore-mentioned extension so i'd like to see this in the default branch... just my 2 cents, although they're probably wort less than that!
I hope Beltzner meant to nominate this UI change for 1.8.1 (i.e. Firefox 2). Out of scope for 1.8.0.x
Flags: blocking1.8.1?
Flags: blocking1.8.0.1?
Flags: blocking1.8.0.1-
Flags: blocking-firefox2+
unless we're going to take a run at 1.5.0.x drivers, this will be handled by the new search UI that's coming in Firefox 2.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Flags: blocking-firefox2+
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.