Page MenuHomePhabricator

Position of wpEditToken input tag in edit form
Closed, ResolvedPublic

Description

Author: charlottethewebb

Description:
When using slower connections, my edits sometimes fail because I have already clicked the "save" button before the page has finished loading.

Part of the problem is that the ever-growing list of insertTags() links for special characters found at http://en.wikipedia.org/wiki/MediaWiki:Edittools, also located within the edit <form> takes toofuckinglong to load.

(I am not aware of any way to disable the entire mw-editTools section other than using "display:none" in CSS, which does hide it but doesn't make the page load any faster. On a related note, an option in Special:Preferences to completely omit this would be great too)

The following lines appear about 55 Kb later, AT THE END of the <form>:

<input type='hidden' value="[redacted]+\" name="wpEditToken" />
<input name="wpAutoSummary" type="hidden" value="[redacted]" /></form>

Could we please move these items upward?

I think the ideal place would be within the <div class="editbuttons"> and directly before <input id="wpSave" ... />, as editing is apparently guaranteed to fail if wpSave is clicked with no defined wpEditToken value!

CW


Version: 1.12.x
Severity: normal

Details

Reference
bz13130

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:07 PM
bzimport set Reference to bz13130.
bzimport added a subscriber: Unknown Object (MLST).

Reverted in r31228.

The token is placed below the text box in part to ensure that everything is transmitted together successfully. This commit moved it up above the text box, where we would lose that protection.

Fix location of the summary and edit token hidden inputs

I think this patch should be good for both parties.

It fixes two or three things.

The wpEditToken is now located after the save buttons, but before any of the edittools or extra page information.

This location should be optimum as it ensures that the input is located after all the vital inputs are displayed, but before all the extra form cruft which only serves visual purpose and has no relevance to the submit data.

Additionally a change to the location of wpIgnoreBlankSummary and wpAutoSummary is made.
Previously these were located at the bottom of the form alongside the edit token. As with the comment about the edit token being missed, it's possible for these to be missed if everything has not loaded yet.
The patch moves these two inputs to a location right after the summary field to make sure they are loaded together.
The wpIgnoreBlankSummary is especially important as users who have the "Prompt me when entering a blank edit summary" preference enabled will need to load for the entire form to load twice if they entered a blank summary.

Attached:

I'm not sure, but if wpIgnoreBlankSummary is there to be used by a javascript code that alerts the users when they leave the summary field blank, and if this javascript code is run "onLoad", the user has to load the full page anyways.

wpIgnoreBlankSummary is used by the server, not JavaScript.

When a user with that preference enters a summary which is blank (verified by the wpAutoSummary hidden field, so it's data is needed). The page does not instantly save, instead the edit form shows itself again with a notice up top, and the wpIgnoreBlankSummary is added inside the page with a value of 1 to prevent that message from coming up again. So basically a user presses the save button twice when they have that option enabled if they want to save a blank edit summary.

I forgot to note it when I made the attachment. But I also fixed a little inconsistency. Previously a HTML string was used to create wpIgnoreBlankSummary and wfHidden(); was used to create wpAutoSummary. They both now use wfHidden();

charlottethewebb wrote:

(In reply to comment #2)

Reverted in r31228.

The token is placed below the text box in part to ensure that everything is
transmitted together successfully. This commit moved it up above the text box,
where we would lose that protection.

Perhaps there was some misunderstanding then.

I suggested putting the token inside <div class='editButtons'> or elsewhere in the vicinity of the wpSave button which is (a) safely below the <textarea> and (b) useless when wpEditToken is not (yet) present.

I agree that putting the token above the <textarea> is an obvious bad idea.

CW

Applied with slight modification in r31365 (hidden cats now in there too). Looks good so far!