Last modified: 2008-03-25 05:22:18 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 13436 - Image caption is interpreted as a parameter (e.g. when it ends with "px")
Image caption is interpreted as a parameter (e.g. when it ends with "px")
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
All All
: Normal minor with 1 vote (vote)
: ---
Assigned To: X!
: patch, patch-need-review
Depends on:
  Show dependency treegraph
Reported: 2008-03-19 18:47 UTC by Mormegil
Modified: 2008-03-25 05:22 UTC (History)
2 users (show)

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

Simple patch (731 bytes, patch)
2008-03-19 21:40 UTC, X!
Better patch (732 bytes, patch)
2008-03-20 00:35 UTC, X!

Description Mormegil 2008-03-19 18:47:18 UTC
Try writing “[[Image:Example.png|thumb|1000px|Some caption ending with px]]”.

You will receive a default-sized thumbnail without a caption, because the title ending with “px” is interpreted as a width parameter, even though it is invalid (the text in place of the expected number is interpreted as 0, overriding the previous valid 1000px parameter, and rendering at default width), and even though the width has already been specified.

The same is true for captions starting with “upright”, or (for djvu files only) with “page”, because those are the magic words containing “$1” placeholders. Note that while this might not be a big problem in English (who ends a title with “px” or starts a title with a lowercase letter?), it can be a bigger issue for some other languages with different magic words (it happened to me on w:cs: today when trying to write a normal image caption).

The problem is that MagicWord::matchVariableStartToEnd eats anything (.*? – see MagicWord::initRegex), no matter only a number is expected, and the parser does no checks on the extracted value, either. The simplest solution could be to test $value after the “isset( $paramMap[$magicName] )” condition against some basic constraints (at least a simple “&& !preg_match( '/[^0-9.]/', $value )” might do; what parameters are possible there, anyway?).
Comment 1 X! 2008-03-19 21:40:33 UTC
Created attachment 4730 [details]
Simple patch

Patch, simple addition
Comment 2 Mormegil 2008-03-19 22:28:42 UTC
(In reply to comment #1)
> Patch, simple addition

Well, that is _almost_ exactly what I wrote, isn’t it? And your patch omits the decimal dot I wrote, which is used with upright (upright=1.2). (Anyway, I am not completely sure this is the best solution, I considered this a bit hacky.)

+ adding patch keyword
Comment 3 X! 2008-03-20 00:35:56 UTC
Created attachment 4732 [details]
Better patch

Addition of a dot to the regex. Now works with more options
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-03-25 00:36:51 UTC
This will break dubious but currently-tolerated constructs like "1000 px" (unless I missed a trim() somewhere, which is probable).  More pedantically, it will also break constructs like "upright=1.35E2" and "+750px".  That's probably okay: this is going to have to be a heuristic and therefore messy, but it's worth pointing that out.  Overall, though, it might be simpler to just use is_numeric instead of rolling your own regex.  Did you test the patch?
Comment 5 X! 2008-03-25 00:39:22 UTC
Yes. Fully tested.
Comment 6 Aryeh Gregor (not reading bugmail, please e-mail directly) 2008-03-25 00:46:55 UTC
Committed a version using is_numeric in r32391.
Comment 7 Tim Starling 2008-03-25 05:21:04 UTC
The patch was incorrect, see my fix in r32394.

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