Page MenuHomePhabricator

The "Prompt me when entering a blank edit summary" wrongly triggers for undo edits
Open, LowPublic

Description

Author: cchittleborough

Description:
On 2 or 3 occasions in the last few days, when trying to save an edit I have
gotten the message "You have not provided an edit summary. If you click Save
again, your edit will be saved without one." even though the edit summary
contained text.

OTOH, I have saved dozens of edits without getting this message. I haven't
noticed any pattern in which Saves go wrong. (*@#&+! Heisenbugs.)

This problem is extremely minor; I'm only reporting it in case it's part of a
more significant problem.

Details

Reference
bz8912

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:35 PM
bzimport set Reference to bz8912.
bzimport added a subscriber: Unknown Object (MLST).
bzimport created this task.Feb 7 2007, 12:24 PM

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.
  1. Alter the edit summary. At this stage, the code from Common.js has set the 'wpAutoSummary' field to "".
  1. 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.
  1. 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)

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

aaron added a comment.Jan 2 2009, 10:59 AM

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

jayvdb added a comment.Jun 1 2011, 6:26 AM

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

TTO added a subscriber: TTO.Jul 5 2015, 1:02 PM

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 .

TTO added a comment.Nov 26 2015, 8:46 AM

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.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 26 2015, 8:46 AM
TTO renamed this task from blank edit summary message is displayed when an auto summary is put in to Blank edit summary message is displayed when trying to save an "undo" with the default summary.Nov 26 2015, 8:47 AM
TTO removed a project: TestMe.
TTO set Security to None.
TTO removed a subscriber: wikibugs-l-list.
Catrope removed a subscriber: Catrope.Jan 13 2016, 9:26 PM
Meno25 removed a subscriber: Meno25.Feb 22 2016, 6:23 PM
TheDJ added a subscriber: TheDJ.EditedJun 22 2017, 1:49 PM

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 ?

TTO added a comment.Jun 22 2017, 1:53 PM

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.

MGChecker updated the task description. (Show Details)
TerraCodes added a comment.EditedDec 20 2018, 9:09 PM

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

Krinkle renamed this task from Blank edit summary message is displayed when trying to save an "undo" with the default summary to The "Prompt me when entering a blank edit summary" wrongly triggers for undo edits.Feb 9 2019, 8:50 PM
Krinkle added a subscriber: Krinkle.

Still reproducible on latest master.


DannyS712 added a subscriber: DannyS712.

Claiming to change message per T10912#4838990

Restricted Application added a project: User-DannyS712. · View Herald TranscriptAug 19 2019, 7:47 AM

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?

Krinkle removed a subscriber: Krinkle.Sat, Sep 28, 3:29 AM

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

TheDJ removed a subscriber: TheDJ.Mon, Sep 30, 3:07 PM