Last modified: 2012-08-28 21:17:20 UTC
error occurring in page serving in Commons (secure login) as it just displays javascript file When viewing pages one gets the error Error: https://commons.wikimedia.org/w/index.php?title=Special:BannerController&cache=/cn.js&303-4 at line 112: malformed URI sequence
[[Special:BannerController]] just serves up the same JS. That doesn't seem right. Do you still see the malformed URI sequence problems? If so, which browser/OS?
I haven't been able to reproduce this. Could you supply the following information: * The URL on Commons where you are getting the error * The language your account is set to * The browser/OS you are using Are you seeing this error consistently on every page of Commons or just certain ones?
This happens in Firefox with strangly encoded urls. I can reproduce this with http://en.wikipedia.org/w/index.php?title=%E6&action=historysubmit&diff=465013717&oldid=465013581 in Firefox 3.6.8.
Hmm, I am seeing "Error:Script error." tonight, though I am doing different maintenance tonight. I see it on &action=delete pages, and I believe that last night it expanded it fuller to when you have bits set uselang=qqx English FF8.0, and same in Chrome Cannot do more to track down this evening. :-/
Michael M.: %E6 is incomplete multibyte character encoding. Where did you get that URL from? It should not exist. billinghurst: action=delete and uselang=qqx both work fine for me. Can you give me a full URL?
(In reply to comment #5) > Michael M.: %E6 is incomplete multibyte character encoding. Where did you get > that URL from? It should not exist. I think it's not an incomplete Unicode character but a character encoded with ISO 8859-1 which is used by some old browsers (https://bugzilla.mozilla.org/show_bug.cgi?id=580381#c2 suggests that even Firefox 3.6.6 is one of the culprits). So such URLs are posted to the Village Pump / ... where they still work except the fact that decodeURIComponent throws an error.
As https://bugzilla.mozilla.org/show_bug.cgi?id=580381#c3 says: Yes, but all that means is that you can't use decodeURIComponent to decode that... because it's using the wrong character encoding. You may be able to get away with window.unescape, but in general there's pretty much no support for working with arbitrary encodings (which is what you want here) built into the language. You'd have to use a library that does that. Any ideas?
Yeah, I'm not really sure there's any way to solve this, as the JavaScript doesn't have any way to know what kind of encoding was used. If anyone has any ideas, let me know.
we need a library to decode arbitrary encodings... resolving LATER until someone writes one.
Isn't it just possible to use mw.util.getParamValue ? This will throw an error too if there are bad unicode characters, but if you only call it for parameters with correctly encoded values it will work as expected.
(In reply to comment #10) > Isn't it just possible to use mw.util.getParamValue ? This will throw an error > too if there are bad unicode characters, but if you only call it for parameters > with correctly encoded values it will work as expected. The point is that the URL has bad Unicode characters. Perhaps mw.util.getParamValue could be used in the end, but it would have to be changed to not throw an error. If it found something that wasn't Unicode, it would have to try another encoding.
The only URL parameters I can find in the source are banner and country. This problem only occurs since the whole URL is parsed, including strangely encoded parameters. mw.util.getParamValue just parses the parameters that are actually needed. If the CentralNotice doesn't care about the title parameter it wouldn't matter whether it is encoded in UTF8 or something else.
@Mark A. Hershberger I no longer have/get the error, though I am not seeing a special notice at all; so if things are still all being delivered the same at your end, maybe it was something in my common.js that was conflicting, though I have only had minor variations there.
Reported again and fixed with a try-catch, so closing this as duplicate. Since those browsers that use encodings other than UTF-8 become more and more rarely, I don't think there is a need to try several encodings until the right one is found. *** This bug has been marked as a duplicate of bug 38805 ***
