Page MenuHomePhabricator

Pre-load block reason
Closed, ResolvedPublic

Description

When changing a block, the block reason used to pre-load into the "reason" box on [[Special:Block]]. This seems to have been changed – now the reason box remains blank when you wish to change a block. (e.g. [http://en.wikipedia.org/wiki/Special:Block/95.76.70.248]) Could this be changed back?


Version: 1.18.x
Severity: enhancement

Details

Reference
bz31405

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 21 2014, 11:48 PM
bzimport set Reference to bz31405.
bzimport added a subscriber: Unknown Object (MLST).

http://en.wikipedia.org/w/index.php?diff=next&oldid=454279133

Normally, when deleting a CSD-tagged page the reason in the tag is automatically preloaded when one goes to delete the page. Doesn't seem to be happening today.

aaron added a comment.Oct 7 2011, 6:16 AM

Hmm. I'm not sure what way is actually better.

Xeno added a comment.Oct 7 2011, 12:51 PM

It is better if the previous reason is preloaded.

It is easier to delete a preloaded reason than to copy-and-paste it from before.

Please restore to past state.

happy.melon.wiki wrote:

I very much doubt these are the same phenomenon: the new SpecialBlock interface uses HTMLForm while the delete interface is still horrible hardcoded crappery in Article::confirmDelete().

happy.melon.wiki wrote:

(In reply to comment #1)

http://en.wikipedia.org/w/index.php?diff=next&oldid=454279133
Normally, when deleting a CSD-tagged page the reason in the tag is
automatically preloaded when one goes to delete the page. Doesn't seem to be
happening today.

Plus this is done by some JS trickery on enwiki, not anything in the default software. And it seems to be fixed now.

Created attachment 9211
Patch to properly handle the form default value for HTMLSelectAndOtherField

The problem with Special:Block is that HTMLSelectAndOtherField's loadDataFromRequest method doesn't parse the form's default value into the 'select' and 'text field' components, instead returning just the 'combined' value. And its getInputHTML method ignores the 'combined' value in favor of the 'select' and 'text field' components.

An easy fix is to just put "other" for the 'select' component and the default as the 'text field' component. Or we can go one better and actually split it apart, as in the attached patch.

Attached:

tagging bugs for Marcus to look at

Reopening as this does not appear to be fixed on trunk (as of r100035).

happy.melon.wiki wrote:

Patch applied in r100049.