simonell wrote:

I think the pattern you didn't recognize yet is, that the message is only
displayed if you have an autosummary in the summary field. F.e. clicking "undo"
in the diff view can reproduce this bug.

Well, I searched for this bug, but didn't one. So, I'll change the summary of
this bug naming the issue of auto summary

cchittleborough wrote:

Thanks, simonell.

Another piece of data: I saw that message earlier today, when I tried to revert
vandalism and someone beat me to it.

cchittleborough wrote:

Example of erroneous no-edit-summary error

This is an example of getting the "You have not provided an edit summary" when
the edit summary field is non-empty.

Browser: Firefox 2.0.0.3.
Procedure: "Save Page as" in "complete" mode, with name
"NoEditSummary-bug-case".

This is the resulting "NoEditSummary-bug-case.htm" file. I can upload the files

from the "NoEditSummary-bug-case_files" directory if necessary.

Attached:

cchittleborough wrote:

Background for comment #3: I tried to revert an edit
(http://en.wikipedia.org/w/index.php?title=The_Order_%28group%29&curid=239571&diff=121364654&oldid=121245422)
using the Undo button. I typed the following edit summary:
rv to [[User:Augustus Rookwood]]. Encyclopedias should use "have not", "first"
and "and" instead of "haven't", "1st" and "&" respectively
I used Show Preview, then clicked Save Page, only to get the "You have not
provided an edit summary" message.

I then did another Preview plus another Save, and got the same message.

I tried replacing the "&" in my edit summary with "&", did a Preview,
changed the edit summary back to "&" and appended a "." to it, did another
Preview and did a Save. That Save succeeded.

Huh?

davidcraig5 wrote:

I can't reproduce with attached edit summary. Is this fixed?

cchittleborough wrote:

Problem continues to happen intermittently, perhaps less often in the last several weeks. As far as I can remember, all recent occurrences have been following an "Undo" in which I altered the automatically-generated edit summary. It's very heisenbuggy.

cchittleborough wrote:

Just had it happen for the first time in at least two weeks.

Edit was http://en.wikipedia.org/w/index.php?title=Amir_Taheri&diff=139437884&oldid=139377880

Edit summary text was:

[[WP:UNDO|Undid]] revision 139377880 by [[Special:Contributions/75.25.16.245|75.25.16.245]] ([[User talk:75.25.16.245|talk]]) who restored [[WP:BLP]] violations & removed useful non-controversial info

Heisenbugs! We hates them! We hates them forever!

...fortunately this is about as unimportant as a bug can get,

cchittleborough wrote:

After looking at the relevant PHP code (/trunk/phase3/includes/EditPage.php) and
Javascript (MediaWiki:Common.js; search for "//fix edit summary prompt for undo"), I can now reliably reproduce this little bastard.

1. Click on an Undo link.

2. Alter the edit summary. At this stage, the code from Common.js has set the 'wpAutoSummary' field to "".

3. Activate "Show Preview". Function showEditForm will execute $autosumm = $this->autoSumm ? $this->autoSumm : md5( $this->summary ); $wgOut->addHtml( wfHidden( 'wpAutoSummary', $autosumm ) ); so the preview page will have wpAutoSummary set to the MD5 value for the summary as altered in step 2.

4. Activate "Save Page" without changing the edit summary. Function attemptSave will execute if( md5( $this->summary ) == $this->autoSumm ) { $this->missingSummary = true; wfProfileOut( $fname ); return( true ); } and since the MD5 values are for the same string value, it will set missingSummary, which will cause function showEditForm to add the Mediawiki:Missingsummary text to its output.

(In reply to comment #8)

3. Activate "Show Preview". Function showEditForm will execute $autosumm = $this->autoSumm ? $this->autoSumm : md5( $this->summary ); $wgOut->addHtml( wfHidden( 'wpAutoSummary', $autosumm ) ); so the preview page will have wpAutoSummary set to the MD5 value for the summary as altered in step 2.

Why is this code executed? Preview forms shouldn't regenerate the edit summary hash.

cchittleborough wrote:

Warning: All my statements here involve some guesswork. I could easily be wrong. Also, I'm going to over-explain things, for my own benefit.

showEditForm contains no return statements and the assignment

$autosumm = $this->autoSumm ? $this->autoSumm : md5( $this->summary );

is at the top level of showEditForm (ie., not inside any control structure), so showEditForm always executes that assignment (barring exceptions).

The Commons.js code installs an Onload handler like this:

addOnloadHook(function () {
  if (document.location.search.indexOf("undo=") != -1
      && document.getElementsByName('wpAutoSummary')[0])
  {
    document.getElementsByName('wpAutoSummary')[0].value='';
  }
})

When the browser first loads the edit form during an undo, this code will set the 'wpAutoSummary' field to "".

My theory is that when you activate "Show Preview", showEditForm will be invoked, will find $this->autoSumm == "", and will then set $autosumm to the hash of the *current* edit summary and put that value in the HTML it generates. Which, as Roan points out, is Not The Right Thing.

Notice that this only happens if you preview an Undo. I suspect most people don't do that. I generally only do it when I want to check wikilinks in the edit summary.

(In reply to comment #10)

The Commons.js code installs an Onload handler like this:

addOnloadHook(function () {
  if (document.location.search.indexOf("undo=") != -1
      && document.getElementsByName('wpAutoSummary')[0])
  {
    document.getElementsByName('wpAutoSummary')[0].value='';
  }
})

When the browser first loads the edit form during an undo, this code will set
the 'wpAutoSummary' field to "".

Why does this happen? showEditForm() should just check whether the edit summary is empty, or in case of a section edit, equal to "/* Section header */". The JavaScript trickery shouldn't be necessary.

• Bug 12061 has been marked as a duplicate of this bug. ***

• Bug 12492 has been marked as a duplicate of this bug. ***

pink-ink wrote:

ruby script for testing

I tried to update a wiki page on our company's wiki automatically by using a ruby script (please see attached webaccess_mediawiki.rb).

Everything went fine until I ran into the problem, which is described above. In line #56 I save the form of the edit page.

Although I have filled out wpSummary with "Test\n", the resulting page is showing something with "preview" in it's title and has the line "You have not provided an edit summary. If you click save again, your edit will be saved without one." in it's body.

The test page has only one word of text and didn't have a summary filled out when I first saved it, perhaps this gives a hint.

Attached:

Are you sending the wpAutoSummary hash?

pink-ink wrote:

Good hint.
Months ago I had found out how to edit the page by script:

One problem was, that the edit form didn't contain any wpAutoSummary field (using the ruby gem 'mechanize').
So I didn't send the wpAutoSummary hash and saving didn't work.

Then I tried to use the only unnamed and empty field in the edit form as if it was the wpAutoSummary field.
That did the trick!

As a conclusion for me, getting a preview page again and again after trying to save a page does not help much in finding out that the wpAutoSummary hash is the problem.
I would wish, there would be an error message or something more specific leading to the fault.

samueljhenderson wrote:

Today on en.wiktionary, I am getting the no-edit-summary warning even when creating a new page (where the summary should be generated automatically from the text of the page). It's extremely annoying, and slows me down considerably ... I hope this is in fact a bug, and was not intended as a feature. :-)

I received this error when creating "Category:Open academic practice and Excellence in Research for Australia" on en.wikiversity

EN.WP.ST47 wrote:

*** Bug 8340 has been marked as a duplicate of this bug. ***

Wasn't this fixed years ago? I have this preference enabled on enwiki and I haven't seen a false positive for a very long time.

In T10912#1427321, @TTO wrote:

Wasn't this fixed years ago? I have this preference enabled on enwiki and I haven't seen a false positive for a very long time.

Maybe it is only working correctly because of https://en.wikipedia.org/wiki/MediaWiki:Common.js/edit.js ?

But if that is the case, I would expect more noise about this. de.wp Common.js has something else related to summaries, but it probably is unrelated to this bug. es.wp has the same JS code in https://es.wikipedia.org/wiki/MediaWiki:Common.js .

In T10912#1427343, @jayvdb wrote:

Maybe it is only working correctly because of https://en.wikipedia.org/wiki/MediaWiki:Common.js/edit.js ?

You're right. This seems to only affect the "undo" feature.

I was looking into that piece of JS that's being quoted a couple of times here. It seems that this problem still exists.

The problem is. When you have an autogenerated/prefilled summary, and you select save, then the system will interpret this as "missingsummary" because it is the same as the 'original' summary. And if you have "forceeditsummary" option enabled, then you will be prompted for not having set a summary.

Apparently in the past, this was annoying to some English Wikipedia users, who figured that an "undo summary" should be enough to avoid a missing summary-prompt. For that reason they added a change using JS, which changes the hash of the summary that tracks if the user has changed the edit summary, so that in the case of undo, this would always register as "changed". Initially, this was done using a wpAutoSummary of empty string, later with the value '1' (an invalid hash).

So basically this has had a 'fix' on English Wikipedia since 2007 (which was a broken fix as mentioned in this ticket around june 2007 and then fixed). This fix was accidentally removed from a large group of the user base in 2015 (which does not seem to have led to significant complaints btw).

Question remains:
1: was the original point valid, that it makes no sense to complain about missing edit summaries, when there is an autogenerated one as for undo.
2: If valid, should we fix this in core, or just keep the JS change ?

an "undo summary" should be enough to avoid a missing summary-prompt

Given that is already how MediaWiki behaves with automatic summaries like "Created the page with..." and "Redirected the page to...", it is natural that it should work that way for the automatic undo summary as well.

I do not think that the undo summary should be treated as sufficient to bypass the "write an edit summary" prompt, as a revert generally deserves a higher level of justification than a creation.

If this isn't going to be changed/fixed in core MW, then the preference label should be changed from "Prompt me when entering a blank edit summary" to something like "Prompt me when entering a blank edit summary (excluding undo)".

Still reproducible on latest master.

Change 530807 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] Make tog-forceeditsummary message accurate.

https://gerrit.wikimedia.org/r/530807

Changing message to Prompt me when entering a blank edit summary (or the default undo summary) instead

Noting for the record that, at least at first glance, it should be easy to accept the default undo summary. In EditPage.php:

if ( $this->hasPresetSummary ) {
	$this->autoSumm = md5( '' );
}

could just become

if ( $this->hasPresetSummary || $this->undidRev ) {
	$this->autoSumm = md5( '' );
}

@Anomie I don't know if you saw my response on the patch - do you think you could take another look?

I saw your response. I had nothing additional to say, the text you have there still seems inaccurate to me.

Change 530807 merged by jenkins-bot:
[mediawiki/core@master] Make tog-forceeditsummary message accurate.

https://gerrit.wikimedia.org/r/530807