Last modified: 2014-11-17 10:35:55 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T18921, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 16921 - Comments may be cut off on page moves and page protections
Comments may be cut off on page moves and page protections
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
All All
: Low normal with 3 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch
: 17091 (view as bug list)
Depends on:
Blocks: 4714 28694
  Show dependency treegraph
 
Reported: 2009-01-07 18:10 UTC by Church of emacs
Modified: 2014-11-17 10:35 UTC (History)
10 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Temporary fix (3.55 KB, patch)
2011-04-24 17:30 UTC, Jan Paul Posma
Details

Description Church of emacs 2009-01-07 18:10:48 UTC
If you protect a page or move a page, you often want to give detailed reasons for that, and unfortunately if your comment is too long, it is cut off and not fully saved in the history[1]. Editing a page solve this problem through a maxlength="200" in the input-tag. There does not seem to be a limit in the forms of page moves and page protections.

[1] see these examples: 
http://de.wikipedia.org/w/index.php?title=Benutzer%3AChurch_of_emacs%2FTestseite&diff=55039106&oldid=54976709&uselang=en
http://de.wikipedia.org/w/index.php?title=Benutzer%3AChurch_of_emacs%2FTestseite3&diff=55039224&oldid=55039106&uselang=en
Comment 1 Raimond Spekking 2009-01-07 20:37:17 UTC
added  maxlength=200 for page moves per r45517.

Please note the the protection form has a maxlength of 255 already.
Comment 2 Church of emacs 2009-01-07 21:29:29 UTC
> Please note the the protection form has a maxlength of 255 already.

This is correct, however not only the edit comment itself is stored in the rev_comment (which has the actual 255-byte-limit), but also the automated part of the comment ("Protected "[[<pagename>]]": ") and the selectable comment (for example "Counter-productive edit warring: "). So, in total you have (in this example, with the specified pagename and selectable comment):
Protected "[[Main Page]]": Counter-productive edit warring: 

That's already 60 bytes, so you have only 195 bytes left - much less than the 255 byte limit the user sees!
I don't think a fix his easy here: On one side, you don't know in advance which selectable comment will be picked (so you can't calculate the actual maximum in advance), on the other hand I don't think that there's going to be a change in the data type/255-byte-limit of rev_comment. But even where there's no easy fix, the least that should be done is to warn the user about this bug.
Comment 3 Brion Vibber 2009-01-08 18:52:53 UTC
Reverted in r45571 -- this changed the field from a textarea to a single-line text input field, when it was a larger field deliberately, thus causing a usability regression.

Additionally we would like to *accept* longer comments, not cut them off more aggressively.
Comment 4 Gurch 2009-01-08 20:00:42 UTC
(In reply to comment #3)
> Additionally we would like to *accept* longer comments, not cut them off more
> aggressively.

I would say that setting a maximum length on the field is less aggressive than appearing to accept long comments and then cutting them off when they're actually saved. :)

Accepting longer comments would be nice, of course. Should a separate bug be filed for that? Or does it come under bug 4714 (which currently only mentions edit summaries)?
Comment 5 Church of emacs 2009-01-08 22:46:55 UTC
If bug 4714 (which is basically about rev_comment and not only about the edit summary) would be fixed, this bug could be closed as well. It should be noted however, that this may be not the case for quite a while (the bug is already open since almost two years) and until then, this bug is still relevant. After all, it's a real bug, while 4714 is just a feature request.

I think that not allowing a too long comment in advance (when the user is aware about this fact and is able to make it short) is better than cutting a long comment off *after* the user moved the page.
Comment 6 Raimond Spekking 2009-01-20 08:46:34 UTC
*** Bug 17091 has been marked as a duplicate of this bug. ***
Comment 7 Purodha Blissenbach 2009-01-20 09:55:41 UTC
This becomes even worse, inho, with the selectable custom-made comments
that are installation/localization dependant.
It is also bad in the context of blocks, where you often want to refer
to an edit (i.e. an URL of a diff) which is put behind the custom
comment. The most significant part, oldid=xxxxx, is truncatd most
likely. :-(

A too restrictive solution was, to subtract punctuation and the
longest message size from the count of available characters, and
output it as the lenght restriction of the (additional) comment field
to the browser, in the hope that it honors the parameter.
Since that can be pretty easily implemented, it might be a solution
to cope with until a better solution was developped.

Better was to warn the user of the possible truncation (like one
can be warned when an edit comment was omitted on a normal page edit,
if one chooses so in ones preferences), letting him know of the allowance,
the number of characters truncated, set the input field size, and if
he alters his message, recycle until all fits, or an unaltered message
comes a 2nd time.

Best was, to allow longer comments per increased data base field length.
Comment 8 Tisza Gergő 2009-02-17 00:36:48 UTC
Another problem with maxlength is that it counts characters while the database filed has a byte limit. Non-ASCII characters can take up two or more bytes.

Maybe a simple js script could count the length on change or submit events and warn the user if neccessary?
Comment 9 Alex Z. 2009-05-13 19:10:40 UTC
One issue with the protection log entries (and possibly others) is that while the protection settings and expirations are concatenated with the reason for the revision table, they aren't for the logging table. The reason and protection settings are stored in different fields.
Comment 10 Aryeh Gregor (not reading bugmail, please e-mail directly) 2009-12-15 00:12:31 UTC
Maxlength re-added in r60054 if $wgHtml5 == true, since HTML5 allows maxlength on textareas.  It works in Chrome 4, but not Firefox 3.5 or Opera 9.22, so leaving this open for now.
Comment 11 Jan Paul Posma 2011-04-24 17:30:30 UTC
Created attachment 8453 [details]
Temporary fix

This temporarily circumvents some problems by using the same javascript code used for the edit summary to prevent problems with unicode, and reduces the max length for protection reasons to 180 bytes instead of 255 characters.
Comment 12 Jan Paul Posma 2011-04-24 17:34:05 UTC
For really fixing this bug we need to increase the maximum edit summary length in the database: bug 4714. Then we can arbitrarily set the client side limit to something more sane than 180 bytes.
Comment 13 Roan Kattouw 2011-04-25 11:40:08 UTC
(In reply to comment #11)
> Created attachment 8453 [details]
> Temporary fix
> 
> This temporarily circumvents some problems by using the same javascript code
> used for the edit summary to prevent problems with unicode, and reduces the max
> length for protection reasons to 180 bytes instead of 255 characters.
Committed in r86846.
Comment 14 p858snake 2011-04-30 00:09:23 UTC
*Bulk BZ Change: +Patch to open bugs with patches attached that are missing the keyword*

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links