Last modified: 2012-10-05 18:29:00 UTC
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.
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
Thanks, simonell. Another piece of data: I saw that message earlier today, when I tried to revert vandalism and someone beat me to it.
Created attachment 3425 [details] 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.
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?
I can't reproduce with attached edit summary. Is this fixed?
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.
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,
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.
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. ***
Created attachment 4702 [details] 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.
Are you sending the wpAutoSummary hash?
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.
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
*** Bug 8340 has been marked as a duplicate of this bug. ***