Last modified: 2013-07-16 19:33:00 UTC
Back in January, Mediawiki was handling BOMs in [[:hi:Mediawiki:Gadget-Twinkle.js]] fine. However, in July, they were causing parse errors which looked like the following: Exception thrown by ext.gadget.Twinkle: JavaScript parse error: Parse error: Illegal token in file 'MediaWiki:Gadget-Twinkle.js' on line 1 I've since removed the BOMs and the errors (at least those due to the BOMs) dissapeared. Diff: [1] Note that there was no change made to the javascript file in between. Permalink to the version in question: [2] This kinda seems like regression to me. 1: http://hi.wikipedia.org/w/index.php?title=%E0%A4%AE%E0%A5%80%E0%A4%A1%E0%A4%BF%E0%A4%AF%E0%A4%BE%E0%A4%B5%E0%A4%BF%E0%A4%95%E0%A4%BF:Gadget-Twinkle.js&diff=2175350&oldid=1938833 2: http://hi.wikipedia.org/w/index.php?title=%E0%A4%AE%E0%A5%80%E0%A4%A1%E0%A4%BF%E0%A4%AF%E0%A4%BE%E0%A4%B5%E0%A4%BF%E0%A4%95%E0%A4%BF:Gadget-Twinkle.js&oldid=1938833
Hi, could you please elaborate why there is a problem in MediaWiki code, and why this is not a problem in the code of the Twinkle gadget? Thanks!
(In reply to comment #1) > Hi, could you please elaborate why there is a problem in MediaWiki code, and > why this is not a problem in the code of the Twinkle gadget? Thanks! The same code was functional in january, and in july it was broken. The error comes from the mediawiki(RL?) parser. So back in January, MW was either removing the BOMs from the code during minification, or it had no problem accepting BOMs in js files. The gadget was also working fine. Now, the parser causes the said error to show up. (Note that the error is from the mediawiki parser, not the gadget itself). I don't see how the problem can be in the gadget since the same code was working fine since october 2012 to alteast january 2013.
I've helped Sid-G to diagnose the problem on IRC. The exception "JavaScript parse error: Parse error: Illegal token in file 'MediaWiki:Gadget-Twinkle.js' on line 3757" is not thrown by the browser when parsing the file. That exception is *injected* into the code output by the Resource Loader (so changing component accordingly). See at the end of this file: http://bits.wikimedia.org/hi.wikipedia.org/load.php?debug=true&lang=hi&modules=ext.gadget.Twinkle&only=scripts&skin=vector&version=20130715T110222Z You can see the following: /* MediaWiki:Gadget-Twinkle.js */ throw new Error("JavaScript parse error: Parse error: Illegal token in file 'MediaWiki:Gadget-Twinkle.js' on line 3757"); So my suspect is that there's some tool or PHP code that parses each JavaScript file looking for syntax errors and detects an error on that file, injecting that exception instead of the actual code. I've tried myself to copy the code of [[:hi:Mediawiki:Gadget-Twinkle.js]] to my personal /skinname.js file for testing and the browser didn't throw any parse error, just a runtime error because of a missing dependency. My conclusion is that the tool that is parsing those JavaScript files is more strict than browsers, and may need tweaking or handling this special case. I think the problem is not really the BOM characters, but another issue. The line 3757 is after this: Twinkle.config.commonSets = { csdCriteria: { शीह: "विशिष्ट कारण ({{शीह}})", I suspect the problem is that the key name of the "csdCriteria" object has non-ascii characters on it, and that's the issue with the tool that is parsing the file. Maybe surrounding those key names between quotes would fix it. Example: Twinkle.config.commonSets = { csdCriteria: { "शीह": "विशिष्ट कारण ({{शीह}})", As I said, executing that code on the browser causes no parse errors (Firefox 22.0). I'm not sure if ecma 262 standard allows this.
(In reply to comment #3) > I've helped Sid-G to diagnose the problem on IRC. > Uh, that's the problem that cropped up later, but yes, the error code injection thingy is probably applicable for both. > I think the problem is not really the BOM characters, but another issue. Before you helped me out today, I asked out at #mediawiki for help with the same file. Back then, the problem was due to BOMs. The same console message and error. And removal of BOMs changed it from line 1 (which contained a BOM) to line 3757 (which contains the said non-ASCII object key name). PS:Just to clarify, this bug is about the BOM handling only. I'll confirm if putting quotes fixes the issue mentioned in comment 2 and then file a separate bug for object key names if needed.
(In reply to comment #4) > PS:Just to clarify, this bug is about the BOM handling only. I'll confirm if > putting quotes fixes the issue mentioned in comment 2 and then file a > separate > bug for object key names if needed. Uh, I meant comment 3. Sorry.
$wgResourceLoaderValidateJS was (re)set to true, see Gerrit change #47519
When all (modern) browser accept BOMs, but JSmin+ does not, the bug can be reopened (with a better subject) and maybe someone writes a patch and let mediawiki remove it. Found https://drupal.org/node/538274 where another open source projet has (in year 2009) problems with BOMs.
