Couldn't the application as a whole also be subject to "undo" "redo" at a higher level than "back" and "forward?" or text-edits? While clearly users should not get the expectation that they can retreive information already sent, a higher level undo would let them step forwards and backwards through many actions, allowing them additioanl freedom in exploration and information confidence. In increasing complexity: Edits, visible preference changes Complex Edits (including message/bookmark add/delete/changes) Navigation (equivalent to back and forward) Navigation group changes (adding/removing tabs, changing tab groups) Window manipulation (moves, resizes, closes, reopens, makes up for some "history" tool shortcomings) Adobe's history tool captures much of this level of detail and is considered a valuable improvement on do/undo. potential security risks: closing windows form reset (discussed in http://bugzilla.mozilla.org/show_bug.cgi?id=100988)
Is this a tracking bug (judging by its long dependence tree)? I think "undo" and "redo" are poor word usage. The words generally apply to document manipulation. For UI interactions, terms such as "reverse," "(re)open recent tabs," and "reset" should be used. I am unesay with the term "application-wide" which to me implies that all action reversals will be handled by one UI element (namely the undo menu item) and the same shortcut keys. This implications, however, is obviously not what you want. How about: "[Meta] Allow users to reverse (undo) all user actions, e.g. window resizing, form editing, etc." for summary? > Edits, visible preference changes Unusual. Feature bloat. Preferences changes should always be reversable. If they are not, then there's a bug and you should target it with an specific bug report. > Complex Edits (including message/bookmark add/delete/changes) Agree. You can already do multiple undo/redo in message composer and form elements. (btw, form filling is usually a non linear process, so undo/redo histories should be kept in individual form elements.) > Navigation (equivalent to back and forward) So we don't run out of shortcuts that quickly, please don't assign two shortcuts for the same thing. > Navigation group changes (adding/removing tabs, changing tab groups) > Window manipulation (moves, resizes, closes, reopens, makes up for > some "history" tool shortcomings) Unusual. Feature bloat. Please back this up by identifying the "needs" for this. I want to add "able to unsend messages," but blah...
Depends on: 39165
I was proposing keeping with one UI element, the conceptual "undo/redo" (and associated accelerators) which would in each instance have a clearer name to describe the undo/redo action. My thinking was one set of deltas throughout the application which could be followed with one pair of commands. > Window manipulation (moves, resizes, closes, reopens, makes up for > some "history" tool shortcomings) At least closes and opens should be in the history tree. > I want to add "able to unsend messages," but blah... Actually that was one of the primary goals of my last company's software.. didn't quite happen though :)
See Bug 70278 comment #4 about why this should not be implemented for window/toolbar/tab changes. Navigation "undo" already exists through the back/forward buttons. Bug 53422 is about implementing Undo for bookmarks. The only thing left in your list is undo for prefs. Is that right? Recommend changing component to prefs, or WONTFIX
1 month with no response: ->WONTFIX If you disagree, please reopen and clarify your request.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.