Screenshot
See associated screenshot; if you go to the "old" view of Page Curation, it is, for some unknown reason, totally borked. Reported by multiple users.
Version: master
Severity: major
Attached:
Ironholds | |
Aug 9 2013, 10:54 PM |
F19: project.png | |
Nov 22 2014, 2:02 AM |
Screenshot
See associated screenshot; if you go to the "old" view of Page Curation, it is, for some unknown reason, totally borked. Reported by multiple users.
Version: master
Severity: major
Attached:
Status | Subtype | Assigned | Task | ||
---|---|---|---|---|---|
Resolved | None | T54683 "Old" is broken: Error: mw.Title: Could not parse title ".digamma" | |||
Resolved | None | T53308 mw.Title cannot parse titles starting with a period. |
Cannot confirm with Firefox 22.0 on F19 on http://en.wikipedia.org/wiki/Special:NewPagesFeed though the "loading" animation next to the "Refresh list" button does not stop.
Exact URLs and browser info to reproduce welcome (in general), and/or links to forum threads.
Forum threads?
The exact URl is Special:NewPagesFeed; there's no real way to modify that URL. Firefox 22/Windows 7, Iceweasel 17/latest stable Debian release. I'll ask other users for their info.
I confirm the error. There is an error with javascript that renders mw.Title item.
Chrome 28.0, Fedora 19
Confirming the JS error on http://en.wikipedia.org/wiki/Special:NewPagesFeed :
Error: Error: mw.Title: Could not parse title ".digamma"
Source File: http://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.centralNotice.bannerController%7Cext.uls.displaysettings%2Ci18n%2Cime%2Cinit%2Cinputsettings%2Cinterface%2Clanguagenames%2Clanguagesettings%2Cpreferences%2Cwebfonts%7Cext.uls.webfonts.repository%7Cext.vector.footerCleanup%7Cext.wikimediaShopLink.core%7Cjquery.client%2Ccookie%2CdelayedBind%2Ci18n%2Cime%2CjStorage%2Cjson%2CmwExtension%2Ctipsy%2Culs%2Cwebfonts%7Cjquery.uls.data%2Cgrid%7Cmediawiki.Title%2CUri%2Capi%2Ccldr%2CjqueryMsg%2Clanguage%2Cnotify%2Cuser%2Cutil%7Cmediawiki.api.parse%7Cmediawiki.language.data%2Cinit%7Cmediawiki.legacy.ajax%2Cwikibits%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.startup%7Cskins.vector.js%7Cwikibase.client.init&skin=vector&version=20130810T072154Z&*
Line: 320
(In reply to comment #2)
Forum threads?
Whatever URL(s) "Reported by multiple users." resolves to.
The exact URl is Special:NewPagesFeed; there's no real way to modify that
URL.
An URL would be http://test.wikipedia.org/wiki/Special:NewPagesFeed , "Special:NewPagesFeed" is only a pagename on some wiki with its configuration.
I prefer to not check https://noc.wikimedia.org/conf/InitialiseSettings.php.txt everytime to find out where an extension might be deployed (or not).
Are we sure this is the same bug? It wasn't previously breaking on full-stop including pages.
(In reply to comment #7)
Are we sure this is the same bug? It wasn't previously breaking on full-stop
including pages.
This seems rather clear:
(In reply to comment #5)
Error: Error: mw.Title: Could not parse title ".digamma"
Sure, but again, we've had that bug live and present for months and it has never caused those effects before. I'm not particularly technical, but I'd suggest there are two possible scenarios here:
*The mw.Title parse failure is the source of the weird failure to display old pages - something that has never happened before, even with other failures in the same system to parse full stops;
*The two bugs are unrelated and occurring at the same time; the old page is loaded, generating the mw.Title parse error message, and then drops out of existence due to a second issue - something that would make sense since in testing the failure of the "old" view I've noticed that it's not failing to load the content: it loads as a FOUC and then vanishes from view.
Reopening; sorry, but side-effects of an existing bug do not simply reappear, independent of the initial bug, N months later, without any tweaks in the interim.
Not sure why Nischay is an assignee, he is no longer at WMF. Andre, could you check the default assignee list? Adding Benny who should be able to help with this.
Fabrice, this is a pretty critical new bug which we'll have to get sorted out ASAP.
The underlying bug is in core. mw.Title is a mess right now that in some cases is more strict and sometimes less strict than the Title.php equivalent.
I'm currently working on rewriting that core module.
Meanwhile, I think this NewPageFeed bug is caused by something no longer catching the exception when constructing a mw.Title object from arbitrary input (like page names). Or perhaps it never caught it to begin with.
Either way, though I don't like this pattern, in JS right now mw.Title throws on invalid titles, just like Title.php returns null instead of a Title instance from Title::newFromText if the input is invalid.
So where in PHP you need:
$t = Title::newFromText();
if ( $t !== null ) {
} else {
}
in JS you need:
try {
$t = new mw.Title();
} catch (e) {
}
(In reply to comment #12 by Erik)
Not sure why Nischay is an assignee, he is no longer at WMF. Andre, could you
check the default assignee list?
Default assignee had been nobody@ already; Nischay was set manually.
(In reply to comment #13 by Krinkle)
The underlying bug is in core.
I assume it's bug 51308, adding dependency.
Change 82575 had a related patch set uploaded by Bsitu:
Get rid of some javascript mw.title related code