Last modified: 2012-09-12 23:42:46 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 40103 - clicking the watch list star throws an error and no feedback is shown (star does not stop rotating)
clicking the watch list star throws an error and no feedback is shown (star d...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
1.20.x
All All
: Highest major (vote)
: ---
Assigned To: Krinkle
:
: 40106 (view as bug list)
Depends on:
Blocks: 39841
  Show dependency treegraph
 
Reported: 2012-09-08 13:29 UTC by Rainer Rillke @commons.wikimedia
Modified: 2012-09-12 23:42 UTC (History)
14 users (show)

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


Attachments

Description Rainer Rillke @commons.wikimedia 2012-09-08 13:29:06 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' );
}
},
Comment 1 Rainer Rillke @commons.wikimedia 2012-09-08 13:31:34 UTC
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.
Comment 2 Alex Monk 2012-09-08 13:32:56 UTC
Reproduced on Ubuntu with Chrome, so this is not Windows XP/Firefox specific.
Comment 3 Alex Monk 2012-09-08 13:35:39 UTC
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...
Comment 4 Alex Monk 2012-09-08 14:13:26 UTC
$.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.
Comment 5 Bartosz Dziewoński 2012-09-08 16:20:41 UTC
*** Bug 40106 has been marked as a duplicate of this bug. ***
Comment 6 Helder 2012-09-08 21:17:42 UTC
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')
Comment 7 Bartosz Dziewoński 2012-09-08 21:19:56 UTC
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.)
Comment 8 Daniel Friesen 2012-09-08 22:09:34 UTC
The mw.notification code should already have the reintrodction of 1.8 as a dependency.
Comment 9 Krinkle 2012-09-10 22:13:47 UTC
Yes, but as complained about before, someone reverted jQuery to 1.7.2 because of a speed regression without testing anything.
Comment 10 Krinkle 2012-09-10 22:19:11 UTC
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 ***
Comment 11 Rob Lanphier 2012-09-11 01:38:53 UTC
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.
Comment 12 Krinkle 2012-09-11 02:17:37 UTC
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.
Comment 13 Rob Lanphier (RobLa) 2012-09-11 16:09:25 UTC
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.
Comment 14 Krinkle 2012-09-11 17:34:58 UTC
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.
Comment 15 Rob Lanphier 2012-09-11 20:33:43 UTC
Which 3 commits are the blockers?
Comment 16 Krinkle 2012-09-12 10:02:00 UTC
(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.
Comment 17 Oliver Keyes 2012-09-12 10:58:33 UTC
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 :).
Comment 18 Roan Kattouw 2012-09-12 23:42:46 UTC
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.

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


Navigation
Links