Closed Bug 36998 Opened 24 years ago Closed 24 years ago

Implement Revert to Last Saved version.

Categories

(Core :: DOM: Editor, defect, P3)

defect

Tracking

()

VERIFIED FIXED

People

(Reporter: rubydoo123, Assigned: cmanske)

Details

The View menu should contain either a refresh or reload option as in 4.x
Target Milestone: --- → M16
I think refresh should be unneccessary. A reload feature is a good idea, and
even though we have it in 4.x, I'm wondering if it should be an item in the 
file menu like "Revert to saved version". That's what I've seen in other 
editors.
cc'ing others for comments about other platforms.
Status: NEW → ASSIGNED
Revert sounds familiar and useful to me, both from emacs (unix) and from lots of
image editors (windows -- Unix image editors don't generally offer this). 
Reload or Refresh don't sound like things I'd ever expect to do in an editor,
and I probably would never use them because I wouldn't be sure what they'd do.
I would push this off past M20; I think we can ship without reload or refresh.  I 
agree with Akkana: revert is much more useful than these and I'd be leary of 
commands named "reload" or "refresh" in an editor...  (Sorry beppe!)  If there is 
a bug or something that causes us to need to give users these commands we should 
fix that bug instead of further cluttering our menus.
that's interesting, in 4.7 under view there is a refresh command -- so, how 
could you be leary of that? -- sorry Kathy -- All I'm suggesting is that we 
continue to provide the same level of functionality as in 4.x. More importantly, 
I want the ability to edit the file as HTML source and ensure the Composer view 
of the file gets updated (i.e. refreshed) with the new changes. That of course 
would be resolved if an Edit HTML Source option is provided, hten yes -- the 
revert option would be an enhancement request, until then -- this is a 
regression in functionality.
It sounds like what you are asking for is some level of external editor support. 
To do this, we'd have to deal with the case where both the local, unsaved copy 
has changed, and the disk file was touched by another editor.
We are digressing from the central issue. In 4.x, "refresh" was there to 
relayout from the memory copy. It was needed because display and the data
had more disconnect than they do now. I think it is totally unnecessary.
As for "Reload", Akkana, Kathy and I prefer a "Revert from last saved" feature, 
which usually a File menu item. The point is we don't think "Reload" makes 
as much sense in the editing context. I think we should have the feature and 
should decide now since we would have to have the menu item string soon.
The issue Simon brings up is separate and we do have to support detection of
changes by other editors, and the case he mentions where changes are made in
two places and user has to reconcile them. I need to add the strings for that
simple message dialog, even if we don't wire it up until after M16.
That would be "Revert to last saved", or just "Revert", I think. I agree with the 
rest. It should be easy to implement.
Added bug 37089 for the issue Simon described on 4/25
Changing summary for this to the "revert" feature.
Summary: Need to add Refresh or Reload to menu → Need "Revert to last saved" feature.
Re the issue Simon raised: once we get autosave working (and assuming that we
trust the focus infrastructure), it's no problem: if autosave on every blur and
revert (if file changed since autosave) on every focus, we can play nice with an
external editor (on the same machine, anyway; for more complicated cases, like a
file on an NFS file system being edited by someone on another computer, we could
periodically check the last-modified date and make sure it's consistent with our
last write, and throw up a warning if we see it change out from under us.  Emacs
does this).

Not to say we need to do any of this before release, only that the problems have
fairly simple solutions.
Summary: Need "Revert to last saved" feature. → Need to add Refresh or Reload to menu
I'd hate to save on every blur, and restore on every focus. People will go crazy 
at all the disk-rattling that would cause, especially for long, complex docs. I 
want to control when things are saved, thank you.
Simon--if you want control over when saves happen or don't, then don't turn on 
the auto-save pref. :-)  I know I won't.

Akkana--we may want to add some smarts like you suggest for auto-save but it 
depends.  If I auto-save every 2 minutes I probably don't want to auto-save on 
blur events too.  ???
No, you're misunderstanding.  I'd never suggest that autosave/revert should
*always* happen on blur/focus events.  I'm saying that when we're in 2-window
source/wysiwyg editing mode (the user has specifically asked us to bring up a
source editor in addition to the wysiwyg editor we're showing), then we go into
autosave/revert mode to keep the two windows synchronized.

Normal autosave should be on a character/modification count, or, that's too hard
to implement, a timer.
Please stop discussing the autosave and onfocus/onblur issues here!
They belong in bug 37089!
I checked in the menu item. Changed summary to include "Revert".
Summary: Need to add Refresh or Reload to menu → Need to add Revert to Last Saved to File menu
Menu is in. Just need to add the warning message and reload the url.
Will do today.
Summary: Need to add Revert to Last Saved to File menu → Implement Revert to Last Saved version.
checked in 
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verified in 6/29 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.