(In reply to Bryan Davis from comment #0)

Default CC: bdavis@wikimedia.org

Done

Both done.

For oo.Factory.create, my version of Chrome tells me "Not optimized: Bad value context for arguments value" which seems to be a consequence of doing args = Array.prototype.slice.call( arguments, 1 ); . I don't really see a way around that, unless there's some way of making the arguments list a real array that V8 is able to optimize.

EventEmitter.emit also seems to be because of arguments. I checked, though, and there's very little "self" time spent in EventEmitter.emit and Factory.create: 25ms and 53ms respectively for Obama. But I'll see what that drops to after optimizing them.

Reedy: Thanks that fixed it.

You need to clone our vendor repo, or run composer

• This bug has been marked as a duplicate of bug 72777 ***

https://lists.wikimedia.org/pipermail/wikitech-l/2014-October/079232.html

(In reply to Marc A. Pelletier from comment #1)

Sounds sane; the actual cost of adding a timestamp should be essentially
nil, and I can think of a couple use cases when patrolling for spam links
that make it easier than trawling the RC.

That said, the column would be nearly useless without an index and I know
there's a cost for /that/, so someone more versed in performance will need
to chime in.

Sounds sane; the actual cost of adding a timestamp should be essentially nil, and I can think of a couple use cases when patrolling for spam links that make it easier than trawling the RC.

Change 168761 had a related patch set uploaded by Umherirrender:
Use html helpformat for paraminfo

Note that ApiSandbox never had *parsed* wikitext. Before recent changes it was trying to pretty-print the plain text that was handed to it. Unfortunately the pretty-printing isn't handling the wikitext in a sensible way.

Written, and run on the cluster.

Change 173088 abandoned by Legoktm:
Add scripts to cleanup LocalPageMoveJob breakage

Change 173088 had a related patch set uploaded by Legoktm:
Add scripts to cleanup LocalPageMoveJob breakage

Context might help resolve this bug... at the moment, the barrier to entry is pretty steep!

Script is written, but I'm waiting for my internet connection to stop flaking on me before running it...probably tonight.

People are getting annoyed waiting for this...

Adding this as a (soft) blocker of bug 53131 since it will lead to problems for people without CURL.

Change 172113 merged by jenkins-bot:
Be consistent in "modules-to-load" declaration

Change 172006 merged by jenkins-bot:
Ensure notifications overlay code runs

Change 172006 had a related patch set uploaded by Phuedx:
Ensure notifications overlay code runs

The mwext-browsertests-* jobs were meant to be triggered on patchset proposals. Apparently this tests has been failing for quite a while and I am really tempted to remove it entirely.

Prioritization and scheduling of this bug is tracked on Trello card https://trello.com/c/lEVOChJe

Change 172113 had a related patch set uploaded by Florianschmidtwelzow:
Fix Notices and Warnings in SkinMinerva (through OutputPage)

Change 172545 merged by jenkins-bot:
Add irc to the allowed URL schemas

Change 172663 merged by jenkins-bot:
(bug 73197) allow admins to give patroller right on Hebrew Wiktionary

Change 172545 had a related patch set uploaded by Thiemo Mättig (WMDE):
Add irc to the allowed URL schemas

Change 172663 had a related patch set uploaded by Matanya:
(bug 73197) allow admins to give patroller right on Hebrew Wiktionary

Ah no please create one.

Is there a depending bug report for adding 'irc' to the configuration? Without a configuration change users won't be able to use the new code.

https://he.wiktionary.org/wiki/%D7%95%D7%99%D7%A7%D7%99%D7%9E%D7%99%D7%9C%D7%95%D7%9F:%D7%9E%D7%96%D7%A0%D7%95%D7%9F#.D7.94.D7.A4.D7.A2.D7.9C.D7.AA_.D7.9E.D7.A2.D7.A8.D7.9B.D7.AA_.D7.91.D7.A7.D7.A8.D7.AA_.D7.94.D7.A9.D7.99.D7.A0.D7.95.D7.99.D7.99.D7.9D

Change 172112 had a related patch set uploaded by Matanya:
(bug 73197) enable Patrolled edits on Hebrew Wiktionary

Change 170906 had a related patch set uploaded by Thiemo Mättig (WMDE):
Refactor UrlSchemeValidators and allow more schemes

Change 170906 merged by jenkins-bot:
Refactor UrlSchemeValidators and allow more schemes

Change 172112 merged by jenkins-bot:
(bug 73197) enable Patrolled edits on Hebrew Wiktionary

Sounds fixed

Change 171149 merged by Dbrant:
Make error messages in account creation slightly more prominent.

Created attachment 17007
after clicking exclamation point

The error text should show without click being necessary.

Change 171149 had a related patch set uploaded by Deskana:
Make "userexists" message in account creation slightly more prominent.

Seems that you need to complete the dialog before page title suggestions appear, so just press Enter really quickly after typing.

Change 170819 had a related patch set uploaded by EBernhardson:
Clear DeferredUpdates state via setUp()

Change 170819 merged by jenkins-bot:
Clear DeferredUpdates state via setUp()

Same for me, I also cannot reproduce this. Perhaps a broken user script that is interfering...

Change 173747 merged by jenkins-bot:
Don't try to get newtimestamp from edit if no change was made

I can't repro.

Best guess is that state is being held inside the DeferredUpdates class between tests. For now the thanks test runs DeferredUpdates::clearPendingUpdates() via its setUp method and everything works. I wonder if MediaWikiTestCase::setUp() should be clearing DeferredUpdates instead?

Change 173747 had a related patch set uploaded by Alex Monk:
Don't try to get newtimestamp from edit if no change was made

I don't see anything in those history pages though. My quick guess is some cache wasn't invalidated when the page was saved.

Change 172580 merged by jenkins-bot:
Add "featured portal" badge (Q17580674)

Change has been deployed, the CSS for the icon will follow with the next Wikidata deploy (should be next week).

(In reply to Andre Klapper from comment #1)

(In reply to richshup from comment #0)

1. I verified that wikigender.org is no longer blacklisted, in the Wikimedia

blacklist (or whatever the correct name is).

Where could I check/verify this if I wanted?

(In reply to richshup from comment #0)

1. I verified that wikigender.org is no longer blacklisted, in the Wikimedia

blacklist (or whatever the correct name is).

Thanks Marius!

Cannot reproduce with Firefox 33 on Fedora 20 - no problems logging in on https://gu.wikipedia.org . Cannot see anything suspicious on https://wikitech.wikimedia.org/w/index.php?title=Server_Admin_Log either.

Related CSS changes: https://github.com/wmde/Wikidata.org/pull/17 and https://github.com/wmde/WikimediaBadges/pull/15

Change 172580 had a related patch set uploaded by Hoo man:
Add "featured portal" badge (Q17580674)

Eh, those forms do work on Wikipedia etc. but they don't do on the translatewiki.net repository. I should have checked both.

wgGrammarForms for cs is quite different from other languages. It uses "sg"s and "pl"s. It looks like these have been already added (gerrit 61779) although "sg"s and "pl"s have been used. So can this be marked as resolved?

Support for multiple continuation has been added here:
https://bugzilla.wikimedia.org/show_bug.cgi?id=55193

Can't reproduce it myself now... maybe it was a bad time of the server :)
Closing the ticket, if it would be possible to reproduce, I will reopen it with details.

I cannot reproduce the report. Searching for "Wikimedia" using the "Ticket#" box (QuickSearch) does take a considerable amount of time but brings up >2000 search results. I'm also using Chrome.

Could you open "Developer Tools > Network" (see https://developers.google.com/chrome-developer-tools/ ) if any file takes a long time to load?

As far as I can see, only interwiki uses this.
This bug is not causing errors, but langlinks & templates are not being preloaded, so interwiki is operating much slower than it would in compat.

Change 173499 merged by jenkins-bot:
Preloading tests

Can you describe where you enter the search term? In the "Ticket#" box on top of the page or via the regular search form (Tickets > Search)? If the latter, do you enter it next to "Full text:"?

In the "ticket #" box on the top, if nothing is wrong with my memory, it worked as a search field before, too.

I'm seeing the following behavior on Chrome 38, Windows 7:

The VE version on mediawiki shows slightly different behavior, for instance on https://www.mediawiki.org/w/index.php?title=Markup_spec&veaction=edit&vesection=3