Page MenuHomePhabricator

Encoding problem with mw.util.getParamValue() and $.param
Closed, ResolvedPublic

Description

If we try to use

mw.util.getParamValue( 'TEST', 'example.com?' + $.param({ 'TEST': 'a b+c' }) )

the result will be "a+b+c", which is wrong and breaks some scripts. Compare with

decodeURIComponent(encodeURIComponent('a b+c'))

which results in "a b+c", as expected.

Is it possible to fix mw.util.getParamValue so that we can get the original parameter value?


Version: unspecified
Severity: normal

Details

Reference
bz30441

Event Timeline

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

For an example of an script which was affected by this issue, and a possible workaround, see:
https://secure.wikimedia.org/wikipedia/pt/w/index.php?title=MediaWiki:Gadget-fastbuttons.js&oldid=26543813&diff=26548085&uselang=en

The problem seems related to/caused by this
http://bugs.jquery.com/ticket/3400

(In reply to comment #1)

The problem seems related to/caused by this
http://bugs.jquery.com/ticket/3400

Specifically, this line:
https://github.com/jquery/jquery/blob/master/src/ajax.js#L794

so, would it be possible to remove the .replace( r20, "+" ); from $.param(), or will we need to just avoid using this jQuery function (or recreating it on each WMF wiki when needed)?

CCing Michael Dale since he may know if this problem also happens with the mw.Uri suggested on bug 27730 comment 5.

This should be fixable simply by throwing a .replace('+', '%20') into getParamValue() in mediawiki.util.js before the decodeURIComponent.

Per spec, encodeURIComponent/decodeURIComponent work with the %20 form -- which is what's always used in URI path components -- so if you want to handle '+'s (traditionally used in query string form encoding) you have to do that as an additional step.

https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/encodeURIComponent

http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-262.pdf

Fixed on trunk in r95332. Probably needs merge back to 1.18, 1.17.