Closed Bug 402153 Opened 17 years ago Closed 17 years ago

no way to remove a web-based protocol handler from the list

Categories

(Firefox :: Settings UI, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: dmosedale, Assigned: florian)

References

(Depends on 1 open bug)

Details

(Whiteboard: [proto])

It's been pointed out that after a web-based protocol handler has been registered, there's no way to get rid of it. Nominating for blocking-firefox3? in order to get a wanted-firefox3+ flag.
Flags: blocking-firefox3?
Whiteboard: [proto]
Flags: blocking-firefox3? → wanted-firefox3+
Keywords: uiwanted
Renominating to block, as per discussion with beltzner. He suggested a separate in the pref menu item between actions and apps, and one of the actions could be "remove" which would pop up another dialog. At the very least, we could simply support "shift delete" on that menu item.
Flags: blocking-firefox3?
Assignee: nobody → florian
not a hard blocker, but really want.
Flags: blocking-firefox3? → blocking-firefox3-
Whiteboard: [proto] → [proto][needs ui-decision, patch]
Depends on: 402252
Top of my head thoughts: if we were looking for minimal UI, then in addition to "shift delete" we could add a context menu with a "Remove" option. To make that a bit more discoverable we could inform users about it in a tooltip (or we could even put a "Remove" button in the tooltip).
I'm trying to fix this in bug 402252 and I already have a UI designed with beltzner. I dropped the "shift delete" idea from here because getting keyboard events when a menupopup is opened is a real pain. Thanks for your thoughts though!
Keywords: uiwanted
Whiteboard: [proto][needs ui-decision, patch] → [proto]
Depends on: 413954
This was fixed in bug 402252.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
(In reply to comment #5) > This was fixed in bug 402252. I think this is not fixed yet, at least for web-based protocol handlers for web feeds. If I try to remove one of the three standard handlers (Bloglines/Yahoo/Google), it will reappear after restarting the browser. Same happens when I add one manually as described here: http://developer.mozilla.org/en/docs/Adding_feed_readers_to_Firefox Removing seems to work, but the handler reappears after the next browser start. Tested on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008030804 Minefield/3.0b5pre. Should I file a new bug on this?
(In reply to comment #6) > Should I file a new bug on this? > Yes please. This is only for web-based content handlers, not web-based protocol handlers. The removeContentHandler method in WebContentConverter.js seems to not save anything.
(In reply to comment #7) > The removeContentHandler method in WebContentConverter.js seems to not save > anything. Filed as bug 421816.
Depends on: 421816
You need to log in before you can comment on or make changes to this bug.