Last modified: 2013-05-15 22:08:02 UTC
(problem appears on hewiki and arwiki, but not on enwiki or mw) after upgrade to 1.22wmf3, jquery 1.8.3, a strange problem appears. the issue materialize when using $.ajax() call to extract the raw content of a page, using "action=raw". after upgrade to 1.8.3, jquery returns with error. depending on the page being read, it's typically "unexpected token". my conclusion is that jquery decides that page content is XML, and tries to parse it, causing an "unexpected token" exception. a workaround is to pass "dataType" explicitly to ajax call. both "text" or "html" solve the problem. here is a code snippet that used to work on hewiki, but causes exception now. adding "dataType:'text' " cures it. 'עמוד ראשי' is hewiki name of main page. in reality, this is not the page i am trying to read, but it's a good and stable example. 8<------------------------------------------ $.ajax({ url: mw.util.wikiScript(), data: {title: 'עמוד ראשי', action: 'raw'}, success: function(){alert('success')}, error: function(){alert('error')} } ); 8<----------------------------------------- as mentioned, adding "dataType: 'text'" solves the problem. this does not happen here or on enwiki, but it does on hewiki and arwiki. not sure it has anything to do with rtl vs. ltr - my sample set is just too small. for completeness, here is the workaround: 8<------------------------------------------ $.ajax({ url: mw.util.wikiScript(), data: {title: 'עמוד ראשי', action: 'raw'}, dataType: 'text', success: function(){alert('success')}, error: function(){alert('error')} } ); 8<-----------------------------------------
This sounds like the correct behavior; since raw text may well have {s, [s, or <s in them it can easily trip heuristics for "oh this is JSON" or "oh this is HTML", so you need to explicitly tell jQuery that you want the raw text and not an interpreted version.
it may be "correct" in principle (though i do not think so: if the ajax library wants to guess json it can be my guest, but it should trap exceptions and fall back to text if it guessed wrong), but even if this really *was* "The Right Thing To Do"(tm), the fact is that it did not do so in the past, so stuff that used to work stopped working. as far as i know, a change that causes stuff that used to work to stop working is the very definition of "regression". peace.
s/the ajax library/jquery ajax code/
Sounds like a bug in jQuery, then. Adding upstream keyword; bug should be filed with jQuery.
jQuery was not updated in 1.22wmf3. MediaWiki's copy of jQuery was last upgraded to 1.8.3, in november 2012 (!) and deployed shortly after. If this only started breaking now, 7 months later, it is caused by something other than jQuery. Perhaps MediaWiki started outputting headers on action=raw that cause it to do this? Or perhaps browser behaviour has changed in recent releases? Recommending further research before reporting upstream (they'll ask the same questions).
Pasting the first sample into JS console on he.wp alerts 'success' for me on Opera 12.15 on Windows XP.
i tested this with chrome, ff and ie 10 - all triggered the "error". tried to test with opera (12.15) but i must have done something wrong, because neither "success" nor "error" triggered. don't know enough about debugging in opera to proceed. as to when did this break: i cannot swear it worked on 1.22wmf2, but this technique (i.e., calling $.ajax() with action=raw to obtain wikicode of a page) is used on hewiki for several central scripts used for editing. i will be extremely surprised to hear they all are broken since November 2012 and nobody noticed until now. i'll ask around to see if others can remember when did they see those script actually working. peace.
Pardon my ignorance, but I still fail to understand steps to reproduce. Could somebody share them here?
to reproduce: ============= 0) use ff+firebug, chrome, or IE 9 or 10 1) go to hewiki: http://he.wikipedia.org 2) press f12 and select "Console" (windoze or linux: not sure about mac), or otherwise open "javascript console" 3) paste the first piece of code between the two "cut here" lines in 1st comment ( 8<--- ) 4) run the code in the console (it usually means pressing <Enter>, but some browsers might have a "run code in console" button) 5) notice the "error" alert. 6) paste the 2nd piece of code (almost identical, except the "dataType: 'text', " part) 7) run again and note "success". The last bit of "reproduction" requires a leap of faith: you have to believe me that in previous versions the 1st piece of code was actually successful. peace.
Thanks to Eran roze, the mystery is solved. There is no problem and no regression: the issue came from other script calling $.ajaxSetup(). Apparently, the ajaxSetup changes are global, so slight change in the load order of scripts can cause one script to crap on another all of a sudden (both scripts are old - until now the bug was hidden, prolly because of load order). i am closing this is "invalid", and will remove all uses of $.ajaxSetup() from hewiki. the irony here is that it was i who introduce the ajaxSetup() call. i guess some recent change caused some shifts in script load order, and this pretty old bug was triggered. apologies y'all for the noise, peace.
