162592 - Application-wide Undo/Redo throughout Mozilla

Status: RESOLVED WONTFIX

(SeaMonkey :: General, enhancement)

Description

[Will Budreau]

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)

Comment 1

[Will Budreau]

Related: bug 39165

Comment 2

[Daniel Wang]

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...

Comment 3

[Will Budreau]

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 :)

Comment 4

[timeless]

no

Comment 5

[Chris Lyon]

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

Comment 6

[Chris Lyon]

1 month with no response: ->WONTFIX

If you disagree, please reopen and clarify your request.