Last modified: 2012-12-31 17:16:51 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 T33918, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 31918 - Expose action parameters in JavaScript (ViewAction diff, SpecialContributions target etc.) regardless of GET, POST or url encoding
Expose action parameters in JavaScript (ViewAction diff, SpecialContribution...
Status: NEW
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-24 13:15 UTC by Fomafix
Modified: 2012-12-31 17:16 UTC (History)
5 users (show)

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


Attachments

Description Fomafix 2011-10-24 13:15:29 UTC
MediaWiki supports ISO 8859-1 and UTF-8 URL encoding:

ISO 8859-1:
 http://de.wikipedia.org/w/index.php?title=%D6sterreich&action=history

UTF-8:
 http://de.wikipedia.org/w/index.php?title=%C3%96sterreich&action=history

On ISO 8859-1 URL encoding
 mw.util.getParamValue('title')
stops on decodeURIComponent('%D6sterreich') with
 URIError: malformed URI sequence

Possible solutions:
* mw.util.getParamValue() tries to decode as ISO 8859-1 when UTF-8 decoding fails.
* MediaWiki answers with 301 Moved Permanently and Location in UTF-8 encoding.
Comment 1 Brion Vibber 2011-10-24 14:49:38 UTC
There are several possible fallback decodings depending on the configured site language; replicating that in the JS code would be some annoying extra effort.

Redirecting on a GET request would not be untoward, though we could also see it on some POST requests, where that's less reliable... in general though it's a bit flaky to be manually trying to read things out of the query string that JS sees, as various things might not be there *at all* -- if they come in via rewrite rules, PATH_INFO (eg /wiki/Foo) or POST data.


Your example URL is a good example of one that could easily be switched to using a different URL style that would not have a 'title' query string parameter at all; if $wgActionPaths is set up for history you might have eg http://de.wikipedia.org/history/%C3%96sterreich.

If you're *on* that page, you should be getting the title via mw.config.get('wgTitle') and should make no assumptions about query string parameters.

If you're somewhere else and trying to decode some foreign URL that's been provided to you, then it's probably a bit tricky to try to make any claims about it.
Comment 2 Fomafix 2011-10-24 15:14:22 UTC
Of course mw.util.getParamValue('title') can be substituted by mw.config.get('wgTitle') or mw.config.get('wgPageName').

On
 http://de.wikipedia.org/w/index.php?title=Spezial%3ABeitr%E4ge&contribs=user&target=%D6sterreicher
there is no suitable substitute for mw.util.getParamValue('target').
Comment 3 Brion Vibber 2011-10-24 15:19:52 UTC
I don't think mw.util.getParamValue('target') will help you at http://de.wikipedia.org/w/index.php?title=Spezial%3ABeitr%E4ge/%D6sterreicher or http://de.wikipedia.org/wiki/Spezial%3ABeitr%E4ge/%D6sterreicher however.

Possibly indicates that special pages should be exporting their parameters in a cleaner way.
Comment 4 Fomafix 2011-10-24 18:46:52 UTC
Yes, at the moment there are a lots of hacks to extract the parameters from the URL like extractLemma() in https://de.wikipedia.org/wiki/Benutzer:PDD/helperFunctions.js. mw.util.getParamValue() does not solve the problems and has the same problem with ISO 8859-1 encoding.

Maybe it is possible allocate a JavaScript object with the normalized URL parameters for each (special) page.
Comment 5 Dereckson 2012-06-13 08:39:33 UTC
Adding bug #37378 in see also.
Comment 6 Helder 2012-07-01 01:32:59 UTC
(In reply to comment #4)
> Yes, at the moment there are a lots of hacks to extract the parameters from the
> URL like extractLemma() in
> https://de.wikipedia.org/wiki/Benutzer:PDD/helperFunctions.js.
> mw.util.getParamValue() does not solve the problems and has the same problem
> with ISO 8859-1 encoding.
> 
> Maybe it is possible allocate a JavaScript object with the normalized URL
> parameters for each (special) page.

+1. I've seen similar problems on Portuguese Wikipedia.
Comment 7 Helder 2012-07-01 01:36:06 UTC
(In reply to comment #0)
> On ISO 8859-1 URL encoding
>  mw.util.getParamValue('title')
> stops on decodeURIComponent('%D6sterreich') with
>  URIError: malformed URI sequence

BTW: Any chance of this being related to bug 25846?
Comment 8 Fomafix 2012-07-01 12:43:19 UTC
I see three possibilities to solve the problem

* Implement in JavaScript the same decoder like in PHP. So mw.util.getParamValue() tries to decode as ISO 8859-1 when UTF-8 decoding
fails.
* MediaWiki answers with 301 Moved Permanently and Location in UTF-8 encoding. So the URL gets normalized.
* The parameters gets normalized in PHP and transfered to JavaScript via wiki global variable. mw.util.getParamValue() use the normalized parameters from this variable instead of the URL.
Comment 9 Krinkle 2012-07-22 07:15:17 UTC
(In reply to comment #8)
> I see three possibilities to solve the problem
> 
> * Implement in JavaScript the same decoder like in PHP. So
> mw.util.getParamValue() tries to decode as ISO 8859-1 when UTF-8 decoding
> fails.

There are more encodings, and this can depends on the configuration of the server as well.

> * MediaWiki answers with 301 Moved Permanently and Location in UTF-8 encoding.
> So the URL gets normalized.

Not desired or possible in certain cases.

> * The parameters gets normalized in PHP and transfered to JavaScript via wiki
> global variable. mw.util.getParamValue() use the normalized parameters from
> this variable instead of the URL.

Unnecessary bloat.

And all these 3 solutions share the same problem: They encourage usage of query created and targeted for one script – outside that script (namely a gadget or something). Which is bad, because these are not documented or considered stable. Query parameter names and meaning may change at any time, and must only be used for communication between the script's output and input to itself.

Solution 4.: Relevant values are exported to javascript in a canonical way by the script. For example MediaWiki itself always exports wgTitle, wgNamespaceNumber etc. And special pages export wgCanonicalSpecialPageName. Other scripts can export their own information (e.g. SpecialContributions could export `spContributionsTarget: ..` or `spContributions: { target: .. }`.).
Comment 10 Fomafix 2012-07-22 13:02:04 UTC
Solution 4 is good. This means that mw.util.getParamValue() should never used to get parameters from the URL. All parameters must be parsed on server side. When all parameters are available for JavaScript then this bug can closed with WONTFIX.

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


Navigation
Links