Last modified: 2012-09-12 23:42:46 UTC
Error: TypeError: $.parseHTML is not a function Quelldatei: https://bits.wikimedia.org/commons.wikimedia.org/load.php?debug=false&lang=de&modules=ext.centralNotice.bannerController%7Cjquery.client%2Ccookie%2CmwExtension%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.notify%2Cutil%7Cmediawiki.page.startup&skin=vector&version=20120908T024559Z&* Zeile: 30 ------------ $.parseHTML is undefined ------------ Source file: ------------ https://bits.wikimedia.org/static-1.20wmf11/resources/mediawiki.page/mediawiki.page.watch.ajax.js ------------ Code snippet: ------------ api[action]( title, // Success function ( watchResponse ) { var $li, otherAction; otherAction = action === 'watch' ? 'unwatch' : 'watch'; $li = $link.closest( 'li' ); /*ERR: ------------------>*/ mw.notify( $.parseHTML( watchResponse.message ), { tag: 'watch-self' } ); // Set link to opposite updateWatchLink( $link, otherAction ); // Bug 12395 - update the watch checkbox on edit pages when the // page is watched or unwatched via the tab. if ( watchResponse.watched !== undefined ) { $( '#wpWatchthis' ).prop( 'checked', true ); } else { $( '#wpWatchthis' ).removeProp( 'checked' ); } },
Forgot to say: It's on Wikimedia Commons, e.g. http://commons.wikimedia.org/w/index.php?title=User_talk:Havang%28nl%29&action=history&debug=true&uselang=en using the latest Firefox It also happens with other languages or if debug mode is disabled.
Reproduced on Ubuntu with Chrome, so this is not Windows XP/Firefox specific.
According to http://blog.jquery.com/2012/06/22/jquery-1-8-beta-1-see-whats-coming-and-going/ this method was introduced in jQuery 1.8. On Tuesday we reverted to 1.7.2, so now we get this error...
$.parseHTML started being used in Gerrit change #19199 which means this affects 1.20wmf11 but not 1.20wmf10 (currently not wikipedias). Raising importance and priority, CCing Dantman and Reedy.
*** Bug 40106 has been marked as a duplicate of this bug. ***
As far as I can see, the notification system is plainly broken right now. Neither of the following code works: jsMsg('test') mw.util.jsMessage('test')
Couldn't we just temporarily replace all occurences of $.parseHTML() with $() for now, just to make it mostly work, until jQuery 1.8 issues are properly fixed? There seem to be only two in core right now. Or maybe backport the method to jQuery 1.7? (I didn't check if it depends on any other new features.)
The mw.notification code should already have the reintrodction of 1.8 as a dependency.
Yes, but as complained about before, someone reverted jQuery to 1.7.2 because of a speed regression without testing anything.
Marking as dupe instead of depending on bug 39972. There is nothing to be done here, just go back to jQuery 1.8.1. See bug 39972 for tracking the speed regressions. There were only 2 speed issues. Overal jQuery 1.8 introduces many speed improvements and refactorings of Sizzle and the Animation engines. But 2 edge cases were slown down for us: * Narayam's :text live binding (bug 39969, fixed) * mediawiki.action.view.rightClickEdit (bug 39959, fixed) *** This bug has been marked as a duplicate of bug 39972 ***
Krinkle, I'm reopening this one and assigning to you. We've reverted 1.20wmf11 from en.wikipedia.org, and we may revert all wikis to 1.20wmf10 tomorrow if we can't figure out a speedy resolution to this. Please fix this so that the watchlist code is compatible with jQuery 1.7. Thanks.
We're running on the old code now which has old module versions (for jq 1.7) with old jquery. All fine. In master we've got the latest module versions which are all developed on jq 1.8 and may or may not work with 1.7 (we know from at least a few that they break on 1.7). Currently breaking because we reverted to 1.7.2 all of a sudden without running tests (in that the revert would've been marked -2 by Jenkins had we had TestSwarm integration ready). The two speed issues that were reported on 1.7 have both already been solved and are awaiting merge (I spent time on that last week already). If for some unreported reason jq 1.7 needs to be kept longer, no problem. But at this point I believe it is more productive to merge those 2 changes asap, and then revert back forward to 1.8 and be done with it. The alternative is basically the same: There is no easy/static way to spot things that break between 1.7/1.8 other than observation, which we then patch as we go, and that's exactly what I've been doing for the last week. So basically we went through this already and now we can go back up to 1.8.
Things are not ok. Commons is still broken, and going back to wmf10 is going to be difficult because I'm pretty sure we have some wmf11 work that is needed for the Swift migration.
Right, wmf10+ (incl. master right now) is broken because jquery was reverted, so affects commons as well. Either way, merge the 3 commits and we're done.
Which 3 commits are the blockers?
(In reply to comment #15) > Which 3 commits are the blockers? (Cited from comment #10) > * Narayam's :text live binding (bug 39969, fixed) > * mediawiki.action.view.rightClickEdit (bug 39959, fixed) > (Cited from bug 39969 comment #8) > Fixed in I86cef90be993cef2470fe9a4892bbe55fcce191e. (Cited from bug 39959 comment #7) > Fixed in I2fefb5376d0de40f4997a3a1763eee23fcd3e7fa jQuery update is I32ae312308f6d4167e95e06a09973fb1ecd7bb02.
Just to butt in; my team has some patches that are dependent on this release (and that require us to modify some pages in the MediaWiki namespace if we don't want the edit window to look terrible). If someone could let know when we have a confirmed deployment day/time (assuming it isn't posted here) I would be most grateful :).
The fixes listed in comment 16 have been approved and backported into wmf10 and wmf11. They are live now, and the watchlist star is now working for me. (In reply to comment #17) > Just to butt in; my team has some patches that are dependent on this release > (and that require us to modify some pages in the MediaWiki namespace if we > don't want the edit window to look terrible). If someone could let know when we > have a confirmed deployment day/time (assuming it isn't posted here) I would be > most grateful :). If nothing else pops up, the wmf11 and wmf12 deployments will proceed as scheduled.
