The parser output of edits produced via the 'new section' interface varies on
both the edit body and the edit summary (since it determines the new section's
name). So there isn't an early point in the edit process where we can start
computing the edit output. We have to wait for the user to be completely
done, by which point edit-stashing provides no advantage.
Change-Id: Ida461e08189b75c5a508628d11dc929a6138814a
token: token,
title: mw.config.get( 'wgPageName' ),
section: data.wpSection,
token: token,
title: mw.config.get( 'wgPageName' ),
section: data.wpSection,
- sectiontitle: data.wpSection === 'new' ? data.wpSummary : '',
text: data.wpTextbox1,
contentmodel: data.model,
contentformat: data.format,
text: data.wpTextbox1,
contentmodel: data.model,
contentformat: data.format,
- $form.on( 'change', function () {
+ function onEditChanged() {
+ // If a stash request is already in flight, abort it, since its
+ // payload has just been invalidated by this change.
if ( pending ) {
pending.abort();
}
api.getToken( 'edit' ).then( stashEdit );
if ( pending ) {
pending.abort();
}
api.getToken( 'edit' ).then( stashEdit );
+ }
+
+ // We don't attempt to stash new section edits because in such cases
+ // the parser output varies on the edit summary (since it determines
+ // the new section's name).
+ if ( $form.find( 'input[name=wpSection]' ).val() === 'new' ) {
+ return;
+ }
+
+ $form.find( '#wpTextbox1' ).on( 'change', onEditChanged );
} );
}( mediaWiki, jQuery ) );
} );
}( mediaWiki, jQuery ) );