Last modified: 2014-07-03 16:41:23 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T69420, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 67420 - Users experiencing "Script not responding" errors on 1.24wmf11 wikis – EventLogging triggering itself with deprecation warnings
Users experiencing "Script not responding" errors on 1.24wmf11 wikis – EventL...
Status: RESOLVED FIXED
Product: Wikimedia
Classification: Unclassified
General/Unknown (Other open bugs)
wmf-deployment
All All
: Highest major (vote)
: ---
Assigned To: James Forrester
:
: 67404 67478 (view as bug list)
Depends on:
Blocks: wmf-deployment
  Show dependency treegraph
 
Reported: 2014-07-02 16:06 UTC by Steinsplitter
Modified: 2014-07-03 16:41 UTC (History)
19 users (show)

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


Attachments

Description Steinsplitter 2014-07-02 16:06:41 UTC
Multiple reports about problem with scripts serverd by bits.wikimedia.org.

Bits is very slow & a lot of scripts errors.

See https://commons.wikimedia.org/wiki/Commons:Forum#Anmeldung.3F
Comment 1 Andre Klapper 2014-07-02 17:05:04 UTC
Can't reproduce with Firefox 30 or Chrome 35. 
Are these all Monobook skin users?
Comment 2 Andre Klapper 2014-07-02 17:13:50 UTC
traceroute might also be welcome.
Comment 3 Steinsplitter 2014-07-02 23:00:52 UTC
I don't have a problem so i can't trackeroute, but a user has reported:
Kabel Deutschland, (traceroute wikimedia.org via muntiple dynip.superkabel.de to ip4.tinet.net)
Comment 4 Kunal Mehta (Legoktm) 2014-07-03 03:47:10 UTC
I experienced this issue just now as well on meta. FF30, using Vector.

My urls looked like https://bits.wikimedia.org/meta.wikimedia.org/load.php?debug=false&lang=en&modules=mediawiki.inspect%7Cschema.DeprecatedUsage&skin=vector&version=20140701T181452Z&*:2 and https://bits.wikimedia.org/meta.wikimedia.org/load.php?debug=false&lang=en&modules=jquery%2Cmediawiki%2CSpinner%7Cjquery.triggerQueueCallback%2CloadingSpinner%2CmwEmbedUtil%7Cmw.MwEmbedSupport&only=scripts&skin=vector&version=20140701T181452Z:6

After hitting continue about 5 times (my browser locked up in between) I hit "Stop script" and gave up.

I haven't run into anything like this in browsing enwp or mw.o, but those are both in MonoBook.

Traceroute is running...
Comment 5 Kunal Mehta (Legoktm) 2014-07-03 05:28:27 UTC
$ traceroute bits.wikimedia.org
traceroute to bits-lb.eqiad.wikimedia.org (208.80.154.234), 64 hops max, 52 byte packets
 1  192.168.1.1 (192.168.1.1)  0.882 ms  0.681 ms  0.664 ms
 2  adsl-99-19-51-254.dsl.pltn13.sbcglobal.net (99.19.51.254)  10.564 ms
    12.83.88.205 (12.83.88.205)  10.675 ms  11.433 ms
 3  12.122.114.29 (12.122.114.29)  11.906 ms  15.319 ms  11.902 ms
 4  192.205.37.58 (192.205.37.58)  40.980 ms  79.860 ms  40.158 ms
 5  ae-7.r20.snjsca04.us.bb.gin.ntt.net (129.250.5.52)  42.310 ms *  38.981 ms
 6  ae-4.r21.asbnva02.us.bb.gin.ntt.net (129.250.4.102)  108.718 ms  109.822 ms  108.737 ms
 7  ae-2.r04.asbnva02.us.bb.gin.ntt.net (129.250.4.207)  113.969 ms  108.205 ms  111.447 ms
 8  * * *
 9  * * *

And * * * up to #64.
Comment 6 Kunal Mehta (Legoktm) 2014-07-03 06:50:37 UTC
I ran into this on mediawiki.org, using the MonoBook skin. Bug 67404 says it happens on Modern. I didn't mention it earlier, but I'm using OSX.

This is only occurring on non-Wikipedias, leading me to guess it's something that was deployed in 1.24wmf11.
Comment 8 Kunal Mehta (Legoktm) 2014-07-03 07:04:18 UTC
*** Bug 67404 has been marked as a duplicate of this bug. ***
Comment 9 rschen7754.wiki 2014-07-03 07:11:50 UTC
On OS X too, FF 30, and having the same issues. Not on any Wikipedias.
Comment 10 Greg Grossmeier 2014-07-03 08:01:21 UTC
Reedy: This is potentially a blocker for Wikipedias deploy today. I'll let you decide on course of action since I'll be out.
Comment 11 Andre Klapper 2014-07-03 11:25:15 UTC
I also experienced this exactly once now on Commons on a File: page, Firefox 30 on Fedora 20, Vector skin, being logged in.
Comment 12 Florian 2014-07-03 11:38:51 UTC
Had this several times in last days on mw.org, but only on FF 17 behind a company proxy, so i thought it wasn't a problem with MediaWiki/Wikimedia. Unhappily i can't do a traceroute here :/
Comment 13 Bartosz Dziewoński 2014-07-03 12:09:22 UTC
Similar issues in the past: https://bugzilla.wikimedia.org/buglist.cgi?quicksearch=ALL%20%22Unresponsive%20script%22
Comment 14 Bartosz Dziewoński 2014-07-03 12:26:19 UTC
With no solid evidence to back this up, I have a hunch that the
immediate cause is cde08292 "Add json2.js polyfill (v2014-02-04; with
module skip function)" and the underlying cause is the newly
introduced skip function support in ResourceLoader.

Circumstantial evidence:
* This happens on various very different wikis (Wikidata, Commons,
  Wikisource), which hints towards something in core or very widely
  deployed extension, and I see no interesting changes in extensions
  at first glance on [[mw:MediaWiki_1.24/wmf11]].
* There have been very few other JavaScript changes in core wmf11
  (apart from that, only three changes: 96c65cf8 fa2d7e8c d57d9edd).
* That change modifies the 'mediawiki.inspect' module to use the new
  functionality, and mediawiki.inspect appears in the problematic URL
  from comment 4.

It would be very helpful if someone who can reproduce this on local
installation could try reverting cde08292 and checking if that fixes
the issue. (I am unable to reproduce even on WMF wikis :( )
Comment 15 Gerrit Notification Bot 2014-07-03 14:51:50 UTC
Change 143880 had a related patch set uploaded by Krinkle:
Revert addition of json2.js

https://gerrit.wikimedia.org/r/143880
Comment 16 Krinkle 2014-07-03 15:00:58 UTC
JSON2 is only loaded in old browses. And just in case the feature test wasn't passing, I confirmed just now in Chrome 35 and Firefox 29 and 30 that when "loading" the json module, JSON.stringify and JSON.parse are not redefined and nothing is fetched or executed from that module.
Comment 17 Krinkle 2014-07-03 15:03:06 UTC
Also to clarify, the usage in mw.inspect also had no impact because it's the reference to $.toJSON is a direct pointer to JSON.stringify. Nothing changed in this regard for modern  browsers from what I can tell.
Comment 18 Bartosz Dziewoński 2014-07-03 15:15:11 UTC
(Re the revert patch that was already proposed, if we want to revert at all, it should be sufficient to remove the (two) uses in core to resolve the immediate issue, if that in fact resolves this at all.)
Comment 20 Gerrit Notification Bot 2014-07-03 16:00:39 UTC
Change 143894 had a related patch set uploaded by Jforrester:
Use 'json' module instead of deprecated 'jquery.json'

https://gerrit.wikimedia.org/r/143894
Comment 21 James Forrester 2014-07-03 16:03:02 UTC
*** Bug 67478 has been marked as a duplicate of this bug. ***
Comment 22 Gerrit Notification Bot 2014-07-03 16:07:45 UTC
Change 143894 merged by jenkins-bot:
Use 'json' module instead of deprecated 'jquery.json'

https://gerrit.wikimedia.org/r/143894
Comment 23 Gerrit Notification Bot 2014-07-03 16:10:04 UTC
Change 143896 had a related patch set uploaded by Jforrester:
Update EventLogging to pull in 1e9adcfc5

https://gerrit.wikimedia.org/r/143896
Comment 24 Gerrit Notification Bot 2014-07-03 16:14:26 UTC
Change 143880 abandoned by Bartosz Dziewoński:
Revert addition of json2.js

Reason:
Turns out I was mostly wrong. While doing this would probably fix the issue, I just accidentally happened to pinpoint the right commit (I had one chance in four after all). See comment 19 on the bug.

https://gerrit.wikimedia.org/r/143880
Comment 25 Brad Jorsch 2014-07-03 16:16:27 UTC
(In reply to Lupo from comment #19)
> Depreceation loop? See
> 
> https://commons.wikimedia.org/w/index.php?title=Commons:
> Forum&diff=128061457&oldid=128054357

Yes, that does seem to be the case. I filed bug 67481 to request safeguards be added to the deprecation logger so this doesn't happen again next time.
Comment 26 Rainer Rillke @commons.wikimedia 2014-07-03 16:19:51 UTC
(In reply to Andre Klapper from comment #1)
> Can't reproduce with Firefox 30 or Chrome 35.

Your random number generator simply didn't produce a number < 0.01

Apart from bug 67481, what is WMF's strategy to avoid a bug like this [not reproducible by design, affected a large number of users though] in future?
Comment 27 Gerrit Notification Bot 2014-07-03 16:33:42 UTC
Change 143896 merged by MaxSem:
Update EventLogging to pull in 1e9adcfc5

https://gerrit.wikimedia.org/r/143896
Comment 28 James Forrester 2014-07-03 16:41:23 UTC
This should now be fixed. Sorry for the disruption. Will recommend that an incident report is written up.

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


Navigation
Links