Wikimedia Bugzilla is closed!

(In reply to comment #0)
> The Drafts are not useful for each user. A user who only make typography edits
> does not need drafts and the autosavewait. When he can deactivated the drafts
> he has no useless function. So make drafts optional via Special:Preferences (a
> new tab). Thanks.
> 

If you don't need it don't use it - what's the benefit of turning it off?

Open your monobook.css and add

#wpDraftSave{
display:none;
}

and presto the draft button is gone. Really there is no reason to disable it in any other way, if you never use the button there is no noticeable difference.

(In reply to comment #1)
> (In reply to comment #0)
> > The Drafts are not useful for each user. A user who only make typography edits
> > does not need drafts and the autosavewait. When he can deactivated the drafts
> > he has no useless function. So make drafts optional via Special:Preferences (a
> > new tab). Thanks.
> > 
> If you don't need it don't use it - what's the benefit of turning it off?
The autosavewait-function is the problem. This function is still enabled and produce drafts. When turning off the drafts there is not any autosave.

I reopened the bug as the problem is not fixed. Hiding the functionality is a joke, isn't it? It can't be your truth to waste resources is such a useless way.
I rather propose to deativate it by default.

(In reply to comment #4)
> I reopened the bug as the problem is not fixed. Hiding the functionality is a
> joke, isn't it? It can't be your truth to waste resources is such a useless
> way.
> I rather propose to deativate it by default.
> 

Completely agreed. CSS is an incredibly shitty way of disabling things like this. There should be some sort of checkbox in Special:Preferences.

(In reply to comment #1)
> If you don't need it don't use it - what's the benefit of turning it off?

The bandwidth wasted by the autosave feature...

(In reply to comment #2)
> Open your monobook.css and add
> ...
> and presto the draft button is gone.

...which this doesn't address...

(In reply to comment #5)
> There should be some sort of checkbox in Special:Preferences.

Yes. It would be sufficient for this to disable only the autosaving part of the extension (without this, I'll probably start blocking JavaScript on edit pages). But ideally it would disable both parts.

I would certainly appreciate having my typographical edits not be lost if my browser crashed, just as much as I would appreciate not losing any other edit. Redoing stuff is annoying!

I can see no reason to allow disabling drafts outright. Its UI is minimal, and the benefit of being able to recover data far outweighs the hypothetical benefit of hiding a button. Making the autosave frequency configurable could be done, but honestly I don't see a big use case for it.

If you leave the page open without editing, no data gets transferred. Automatic saves after a change are in the background and should not interfere with the UI. Being text, it should generally be pretty fast. If you're on a very slow connection with a very large article open, perhaps it might be slightly annoying... but it's still not likely to cause much trouble I can think of -- it'll generally be doing its business while you're typing, not while you're fiddling with some other page.

Can you provide an example case where the automatic save is disruptive, and some details of *how* it's disruptive?

What are some strategies that could tackle that, such as changing the autosave rate or transferring smaller amounts of data?

(In reply to comment #7)
> I can see no reason to allow disabling drafts outright.

Eh? We have an option to disable the AJAX search suggestions, too. :P

Ultimately it's the user's choice regarding these types of things. Maybe they're used to three buttons for simplicity's sake. Or maybe they're paranoid about pasting sensitive into the wrong area and having it be saved in the database. Or maybe they just want to demand more user preferences so that someone will finally fix them properly. :P 

Regardless, I see no reason _not_ to have a disable option.

(In reply to comment #8)
> Eh? We have an option to disable the AJAX search suggestions, too. :P

AJAX search suggestions override the browser's "recent searches" feature, so they actually have an appreciable downside.  This does not.  The bandwidth of sending a small amount of text every 120 seconds is negligible for practically anyone.  If it's not negligible for you, you probably can't edit most Wikipedia articles anyway without at least disabling JS.

There is absolutely no example given by anyone so far of how their Wikipedia-editing experience is concretely affected in a negative fashion by having drafts enabled.  Until someone comes up with that, I'll support WONTFIX.  Preferences should not be added without good reasons: every preference does have a cost in complexity to the user, and in maintenance (extra code paths to check).

I support the idea about paranoid users, because I have some in my company. They just are afraid of every new button. If they don't see benefits of using this extension it's their problem not ours. You really should add toggle (really easy to do) to enable disable Drafts. You could even move auto-save interval to pereferences too.

We are going to make some aspects of this extension configurable, however this will be done in coordination with a general improvement of the flexibility and general architecture of the preferences special page which should happen soon if not later.

[Removing RESOLVED LATER as discussed in
http://lists.wikimedia.org/pipermail/wikitech-l/2012-November/064240.html .
Reopening and setting priority to "Lowest".
For future reference, please use either RESOLVED WONTFIX (for issues that will
not be fixed), or simply set lowest priority. Thanks a lot!]

This was fixed quite a while back: https://www.mediawiki.org/wiki/Special:Code/MediaWiki/114879