Last modified: 2013-06-18 13:29:07 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 T15627, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 13627 - Special:MovePage's "Reason" field should be a one-line input, not a textarea
Special:MovePage's "Reason" field should be a one-line input, not a textarea
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Interface (Other open bugs)
1.22.0
All All
: Normal major (vote)
: ---
Assigned To: Bartosz Dziewoński
: design, easy
: 17130 26935 32121 39215 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-06 16:27 UTC by Mike.lifeguard
Modified: 2013-06-18 13:29 UTC (History)
19 users (show)

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


Attachments

Description Mike.lifeguard 2008-04-06 16:27:34 UTC
Please make it a single line like all the other reason fields. Having a text box of multiple lines is confusing and fugly :(
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-04-06 18:10:26 UTC
Or else we should make other reason boxes multiline?  A larger box is needed to hold a full summary, otherwise you have to scroll.  On Special:Movepage we have lots of screen real estate, so we can afford to have a nicely-sized reason box.  We only arguably need small reason boxes when we have a huge text area right above it, and even then I'm not sure we do.  (Certainly not if we allow longer edit summaries than we do now.)
Comment 2 Mike.lifeguard 2008-10-06 03:03:22 UTC
(In reply to comment #1)
> Or else we should make other reason boxes multiline?  A larger box is needed to
> hold a full summary, otherwise you have to scroll.  On Special:Movepage we have
> lots of screen real estate, so we can afford to have a nicely-sized reason box.
>  We only arguably need small reason boxes when we have a huge text area right
> above it, and even then I'm not sure we do.  (Certainly not if we allow longer
> edit summaries than we do now.)
> 

Apparently there is talk of allowing longer edit summaries etc, so perhaps everything will become multiline. Someone should decide what is going to happen here, and then make everything match up one way or the other.
Comment 3 Mike.lifeguard 2008-12-18 04:20:47 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > Or else we should make other reason boxes multiline?  A larger box is needed to
> > hold a full summary, otherwise you have to scroll.  On Special:Movepage we have
> > lots of screen real estate, so we can afford to have a nicely-sized reason box.
> >  We only arguably need small reason boxes when we have a huge text area right
> > above it, and even then I'm not sure we do.  (Certainly not if we allow longer
> > edit summaries than we do now.)
> > 
> 
> Apparently there is talk of allowing longer edit summaries etc, so perhaps
> everything will become multiline. Someone should decide what is going to happen
> here, and then make everything match up one way or the other.
> 

Even if that does happen (and I guess nothing has happened on that front since that comment), then we should probably have a one-line field, but longer. I've seen no problems with one-line fields on the deletion form, edit summary, block reason etc etc
Comment 4 Brion Vibber 2008-12-19 22:46:20 UTC
The comment/reason field on Special:Movepage was turned into a textarea in r10436 (August 2005) "to reduce confusion between destination title and reason input boxes".

I'm not sure the pressures have particularly changed here, so I'm not inclined to just change it back. :)
Comment 5 Daedalus969 2008-12-19 22:51:20 UTC
It's fine the way it is, making it smaller will only increase confusion.
Comment 6 Gurch 2009-01-07 20:47:59 UTC
This was fixed as a side effect of r45517, which addressed bug 16921.
Comment 7 Brion Vibber 2009-01-08 18:53:38 UTC
r45517 was reverted in r45571, as it doesn't properly address bug 16921 and causes a usability regression here.
Comment 8 Mike.lifeguard 2009-01-08 19:10:41 UTC
(In reply to comment #7)
> r45517 was reverted in r45571, as it doesn't properly address bug 16921 and
> causes a usability regression here.
> 

Isn't there some other way to have this be one line while making things clearer for the end-user to avoid mishaps? Perhaps the spacing between the destination and log entry boxes could be increased, or maybe next to one another on the same line would be preferable. I don't think having it as a multiline input is necessarily the only or even the best way of doing this.
Comment 9 Mike.lifeguard 2009-01-23 17:23:26 UTC
*** Bug 17130 has been marked as a duplicate of this bug. ***
Comment 10 Mike.lifeguard 2009-01-23 17:24:47 UTC
(In reply to comment #9)
> *** Bug 17130 has been marked as a duplicate of this bug. ***
> 

Ermm, bug 17130 comment 3 has a patch, which I thought would be moved. Someone who knows how should perhaps do so.
Comment 11 Brion Vibber 2009-01-26 20:58:05 UTC
No need for a patch if it just replicates the change in SVN linked above.
Comment 12 Happy-melon 2011-01-30 16:08:33 UTC
*** Bug 26935 has been marked as a duplicate of this bug. ***
Comment 13 folengo 2011-02-05 13:50:56 UTC
I think this is a major bug. Cutting a user's text without warning that the text is going to be cut if the text is "too" long, is a major bug in my view. I don't see this as mere "enhancement". 

Can you imagine the same happened with this very "Additional comment" box on bugzilla ?

At least here you would be able to add a second comment below to replace the cut text. But is it reasonable to tell people to move the wiki page back and move it again with a shorter text when they experience such difficulty ?
Comment 14 Bawolff (Brian Wolff) 2011-02-07 03:07:38 UTC
We have JS for the edit summary box to limit it to 255 bytes (taking utf8 into consideration). It shouldn't be that hard to adapt it to the textarea on move. I'll try and look into doing that sometime in the nearish future (but if someone wants to beat me to it, by all means).

As for the "textareas are ugly, I only want a one line input" part of this bug, I think that is a wontfix.
Comment 15 DieBuche 2011-05-03 12:42:55 UTC
Another problem with textarea is, that Enter to submit doesn't work.
Comment 16 Bawolff (Brian Wolff) 2011-05-10 05:20:27 UTC
Note, Jan Paul Posma fixed the reason gets cut off issue in r86846.
Comment 17 Alexandre Emsenhuber [IAlex] 2011-11-01 15:12:31 UTC
*** Bug 32121 has been marked as a duplicate of this bug. ***
Comment 18 Alexandre Emsenhuber [IAlex] 2012-08-10 09:28:30 UTC
*** Bug 39215 has been marked as a duplicate of this bug. ***
Comment 19 とある白い猫 2012-08-13 12:15:42 UTC
I like one-line (move) summary as that can auto complete which saves time when I am moving multiple files for similar reasons.

Why not allow user settings to determine if summary box is going to be a single or multi-line textbox. Also having a dropdown+optional comment would work better as  it would allow linking to the policy more effortlessly.
Comment 20 Bawolff (Brian Wolff) 2012-08-13 12:19:19 UTC
>Why not allow user settings to determine if summary box is going to be a single
>or multi-line textbox.

Because of our unrelenting hate of user preferences ;)

----

Note, its possible using user js to change the box to a single line box, fairly easily.
Comment 21 とある白い猫 2012-08-14 15:35:48 UTC
Sure I can java script hack my way on all of life's problems for everything else there is mastercard. Right? It could also be a simple set of check boxes allowing user to customize input fields.

Currently as previously mentioned... The page-file move box/edit summary box/delete box/block box/protection box are different. Only one is multi-lined other are single-lined. This irks me greatly. I however do not want to force people who want to use multi-lined text boxes to use single lined.

The reasons of moving a page or file is routine. Far more routine than anything else. You almost always use the same rationale so WHY is it that it is multi-lined?

For filemove at least on commons and English wikipedia, drop down bot quoting the rationale would be helpful. Drop down box input can be determined locally just like how license list can be adjusted.
Comment 22 Bawolff (Brian Wolff) 2012-08-14 16:18:14 UTC
>Sure I can java script hack my way on all of life's problems for everything
>else there is mastercard. Right?

Exactly! I think this should be MW's new slogan.

-----

I do agree with comment 8 that the spacing between the reason box and the destination box should be increased (even if the reason box is kept multi-line).
Comment 23 とある白い猫 2012-08-16 01:52:14 UTC
Seriously? Why do you want to force users to use interface they are not happy with. I might as well suggest people wanting his multi-lined to use a java script hack. It is bad enough for users to get used to the MediaWiki markup now you want them to learn how to use java script to modify interface.
Comment 24 Bawolff (Brian Wolff) 2012-08-16 12:11:52 UTC
(In reply to comment #23)
> Seriously? Why do you want to force users to use interface they are not happy
> with. I might as well suggest people wanting his multi-lined to use a java
> script hack. It is bad enough for users to get used to the MediaWiki markup now
> you want them to learn how to use java script to modify interface.

I was being a bit sarcastic in comment 22. I don't want people to modify the interface with javascript. I want the interface to be reasonable and usable to all people. For the same reason I don't want user preferences to trigger subtle changes in the interface (Otherwise we would have 10 billion prefs, and usability should not be a preference, etc).

I also do not want to force people to use an interface they are not happy with. However at the same time it is unclear if the change suggested (making it a single line for everyone) would make more or less people unhappy. Thus I feel such a change should be done cautiously.

Similarly, I am not neccesarily opposed to making the box one line, adding a drop down for an auto-reason, and having some extra whitespace between the reason fields and the move target field. I think such an approach may possibly make everyone happy. Or perhaps it won't. I suppose we should make mock-ups and talk to the users and so on.
Comment 25 とある白い猫 2012-08-17 23:09:18 UTC
Alright here is the issue from my perspective. All summary boxes (move, delete, block, edit, whatever) to me should always be single-lined since it will be displayed as a single line anyways.

Mind that this is merely my preference and no one should be forced to use my preference so I acknowledge that some people may want it multi-lined. If we force a single-line summary field on them they will of course complain. Additional stuff such as drop down boxes would probably be warmly welcomed since move actions are typically routine.

The default used to be single lined as far as I know. It was changed without asking users (which alone is fine since some people wanted it this way).

I would support mock-ups and perhaps enable it on some wiki like test.wikipedia for users to actually see.
Comment 26 Nemo 2012-11-24 10:37:45 UTC
(In reply to comment #15)
> Another problem with textarea is, that Enter to submit doesn't work.

(In reply to comment #19)
> I like one-line (move) summary as that can auto complete which saves time when
> I am moving multiple files for similar reasons.

I agree with both, Special:Move is currently very counterintuitive and user-unfriendly because of this. Switching to Normal/Major.
Comment 27 MZMcBride 2012-11-24 22:54:26 UTC
I'm marking this bug as easy because it is an easy bug for any developer to work on. It needs a very simple changeset in Gerrit to move forward. The broader question is whether this bug should be marked resolved/wontfix.

(CC'ing a few people who may be interested in the topic. It's basically a question of usability, consistency, and user expectation.)
Comment 28 Bawolff (Brian Wolff) 2012-11-26 17:58:06 UTC
(In reply to comment #27)
> I'm marking this bug as easy because it is an easy bug for any developer to
> work on. It needs a very simple changeset in Gerrit to move forward. The
> broader question is whether this bug should be marked resolved/wontfix.
> 
> (CC'ing a few people who may be interested in the topic. It's basically a
> question of usability, consistency, and user expectation.)

I disagree that bugs like this should be marked "easy". Easy is supposed to denote a good task for a newbie. While you're correct that making the change is easy, the broader question of should this be Fixed or WONTFIXED is not an easy question, and probably not something a newbie would be prepared to deal with as a first contribution to MediaWiki.
Comment 29 Isarra 2013-03-23 20:31:37 UTC
This should definitely be fixed. 

Two lines of textarea is harder to use than one line of input, not just because it's smaller in practice on many screens, but also because it prevent users from hitting enter when they're done to submit like they would on other summary and reason inputs, because textareas take enter as a linebreak - which makes no sense here because log entries don't allow linebreaks.

While there are concerns about one line inputs being a constraint on how much of a reason a user can give, the character limit is 200 characters (for database reasons apparently) anyway - sufficiently low that even if someone does hit the limit it is relatively trivial to scroll through it - and generally reasons are a lot shorter than that. If a reason to move something truly does require that many characters or more, chances are there is a bigger issue behind the move itself and folks really should be using a link to a policy or talkpage discussion or some such instead of putting it all in the summary, not in the least so that people can respond to the lengthy matter if need be.
Comment 30 とある白い猫 2013-03-29 13:02:10 UTC
I share Isarra's sentiment. I think it summarizes the entire issue very well.
Comment 31 Daniel Friesen 2013-04-02 16:53:03 UTC
I've always been interested in the thought that with some level of extra effort. contentEditable could actually be used to build a custom input that could be one line but nicely word wrapped. And as a bonus it would be possible to make things like the "/* Section */" we give special styles outside have styles inside the input form.
Comment 32 Bartosz Dziewoński 2013-05-03 15:58:46 UTC
Daniel, feel free to have a go at implementing that. For the time being I'm going to submit a patch to make the input single-line again and add some space between the new title field and the summary, per comment 22 (since apparently everybody else is afraid to touch this bug with a stick).
Comment 33 Bartosz Dziewoński 2013-05-03 16:18:04 UTC
Actually, I'm pretty sure that the original reason for this is invalid now that the new name field is split in two parts – the namespace and the title, so I'm just going to revert r45571 back.
Comment 34 Gerrit Notification Bot 2013-05-03 16:35:14 UTC
Related URL: https://gerrit.wikimedia.org/r/62163 (Gerrit Change I5ab2092c32682e7a8a1494bf58553971568fa6cf)
Comment 35 Mark Holmquist 2013-05-08 04:08:12 UTC
Merged, fixed, thanks to Bartosz.

Rock on!

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


Navigation
Links