Looks fine on https://eventmetrics-dev.wmflabs.org

Generating random combinations of blocks including:
+ Username, IP and IP ranges, autoblocks
+ System blocks (e.g. $wgProxyList, $wgDnsBlacklistUrls, $wgApplyIpBlocksToXff, Tor)
+ Global blocks
+ Blocks set from cookies
and testing different actions anonymously and while logged in (e.g. editing, account creation, sending email).

Testing IP and Autoblock cookies locally, looking at:
+ Does the cookie get set at the right time?
+ Do the cookies get cleared at the right time?
+ Is the block applied correctly from the cookie?

Sorry, wrong task.

Are we fixing the mobile message in this bug?

I don't see the link when I am an anonymous user or a non-admin user. I do when I am logged in as an admin.

For a redirect that has been created either as a result of a page move or someone adding "#REDIRECT [[other_page]]".

• T223667 - XTools - @MusikAnimal
• T219328 - Event Metrics - @MaxSem

Had their own tickets. Did not go into QA.

I was not able to reproduce this before. I cannot confirm it has been fixed now.

The PDF from the github issue - https://tools.wmflabs.org/wsexport-test/book.php?lang=fr&format=pdf-a5&page=Manuel_des_principes_de_musique_(F%C3%A9tis) - returns:

Wikisource servers returned an error: PHP fatal error:
entire web request took longer than 60 seconds and timed out

Which is consistent with the error format from the description.

I have managed to launch SVGTranslate on:
+ docker-compose version 1.21.0
+ docker version 18.09.6
On Debian Stretch and Buster.

In T221783#5242645, @dom_walden wrote:

I can no longer provoke the "An error occurred when fetching the preview..." popup when clicking download mid-translation, on either Firefox or Safari.

I can no longer provoke the "An error occurred when fetching the preview..." popup when clicking download mid-translation, on either Firefox or Safari.

We can now download when no translation language is chosen and when there are no unsaved translations.

In T207439#5237606, @MusikAnimal wrote:

Note for QA: In this iteration, I only changed the textareas auto-resize to a max of 12 lines. No other logic beyond that; the auto-resizing does not stop if it exceeds the viewport.

Smoke testing on https://en.wikipedia.beta.wmflabs.org, including:

• Blocking and unblocking via web and API.
• Editing via API while partial blocked.
• Moving title via API.
• Looking at blocked user's (deleted) contrib.
• Tested file upload while partially blocked from File.

An anonymous IP block appears to block a logged in user from Special:CreateAccount. Not from any other action (that I have seen so far).

@MaxSem I am seeing a few new errors on wsexport-test. Are they related to this work?

While sitewide blocked I do not see any "Thank" links on the revision history of any page nor on Special:Log. I can thank revisions on my own User_talk, unless I am explicitly blocked.

I tested the interaction timeline on test.wikipedia for some of my own test accounts and IP addresses (incl. IPv6). It returned the correct revisions (compared to the revision history on the wiki).

Attempting to unblock an auto block (the IP that was autoblocked, not the username that was blocked):

Error from line 365 of /var/www/html/T206163/includes/Block.php: Call to a member function getType() on string
#0 /var/www/html/T206163/includes/Block.php(1143): Block::chooseMostSpecificBlock(Block)
#1 /var/www/html/T206163/includes/specials/SpecialUnblock.php(183): Block::newFromTarget(string)
#2 /var/www/html/T206163/includes/specials/SpecialUnblock.php(166): SpecialUnblock::processUnblock(array, RequestContext)
#3 /var/www/html/T206163/includes/htmlform/HTMLForm.php(675): SpecialUnblock::processUIUnblock(array, OOUIHTMLForm)
#4 /var/www/html/T206163/includes/htmlform/HTMLForm.php(567): HTMLForm->trySubmit()
#5 /var/www/html/T206163/includes/htmlform/HTMLForm.php(582): HTMLForm->tryAuthorizedSubmit()
#6 /var/www/html/T206163/includes/specials/SpecialUnblock.php(68): HTMLForm->show()
#7 /var/www/html/T206163/includes/specialpage/SpecialPage.php(570): SpecialUnblock->execute(NULL)
#8 /var/www/html/T206163/includes/specialpage/SpecialPageFactory.php(575): SpecialPage->run(NULL)
#9 /var/www/html/T206163/includes/MediaWiki.php(288): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
#10 /var/www/html/T206163/includes/MediaWiki.php(865): MediaWiki->performRequest()
#11 /var/www/html/T206163/includes/MediaWiki.php(515): MediaWiki->main()
#12 /var/www/html/T206163/index.php(42): MediaWiki->run()

My guess:
newFromTarget() gets the list of blocks it passes to chooseMostSpecificBlock() from newListFromTarget(), but the latter does not return a list (as far as I can see).

@Tchanders If there is an anonymous IP block and I am logged in on that IP, when I go to Special:CreateAccount I get a fatal error:

Error from line 1379 of /var/www/html/T206163/includes/user/User.php: Call to a member function getBlockForCookie() on null

In T224032#5216247, @Tchanders wrote:

@dom_walden I agree - filed as T224468

In T224294#5215710, @Mooeypoo wrote:

So since the fix touches only the tool's UX, and the file is rendered correctly, I think that this is probably fine, like you're saying.

Switched my keyboard mapping to Hebrew (il) and checked that it behaves appropriately (as far as my limited understanding of RTL goes[1]) for things like Hebrew mixed with numbers, times, parentheses, punctuation, whitespace and Hebrew mixed with English.

In T189929#5210517, @MusikAnimal wrote:

My guess is you checked before update.php was ran. It appears to be loading properly now.

In T224032#5207879, @Tchanders wrote:

Without JavaScript, this behaves similarly to making a partial block against editing a page: the admin can check the user talk checkbox, but it won't have an effect.

I guess the form has quite a few checkbox options that are ignored for certain combinations of parameters, which is made obvious for users with JS but not without. They can at least follow the Help link at the top of the page.

How will this behave without JavaScript?

In T216245#5206222, @dbarratt wrote:

@dom_walden is T196575 a duplicate of this task or a different issue?

@MusikAnimal Going to https://en.wikipedia.beta.wmflabs.org/wiki/Special:NewPagesFeed the feed doesn't load and I get "ReferenceError: recreated is not defined".

I did some load testing of wsexport-test, using ab to simulate concurrent requests (20, 30, 40, 50 concurrent requests at a time).

@dbarratt When the "Time" input is empty, if I click on it and select hour "14" it puts "13:26" (or whatever minute it is) into the input box. Perhaps it is converting to UTC, I think. But then, when I click "14" again it actually puts "14:26" into the input box.

I cannot reproduce this. It looks very similar to what was fixed in T216283, as "Stapes" is not inside a <tspan>.

A little difficult to test. There is not much I can do.

@Niharika @joeroe @Insertcleverphrasehere Just to check I have understood the problem and that you are happy with our solution:

Retesting on Firefox 60, Chromium 73, Edge and Safari 12. On https://en.wikipedia.beta.wmflabs.org.

I have checked that articles get marked as unreviewed when tagging with one of "Speedy deletion", "Proposed deletion" or "Articles for deletion".

All the code changes appear to be replacing "$user->isBlocked()" with "$user->getBlock()", which should behave the same.

I tested that the Translation/ULS dropdown and error popups appear over all other elements on the page (including the SVG image) on:

• Mojave; Safari 12
• High Sierra; Safari 11.1.2
• Sierra; Safari 10.1.2
• El Capitan; Safari 9.1.3
• Win7 IE11

In T222330#5163234, @Samwilson wrote:

Everything seems to be functioning correctly. The only QA here is to see if anything's broken (beyond normal).

My reproduction steps may have confused things.

In T216283#5108155, @Niharika wrote:

@dom_walden Good catch! @MaxSem Do you know if we deliberate limit the number of inputs based on number of tspan elements in the default translation and if it's possible to change it based on the number of tspans in the currently selected From translation?

In T216209#5170895, @MusikAnimal wrote:

As for T216209#5140591, if those are still happening, I think they might be unrelated and deserving of separate tickets.

@Niharika Already reviewed pages which are marked for deletion now become unreviewed. I'm guessing that is good?

I have seen this for a couple of ebook exports:
https://tools.wmflabs.org/wsexport/tool/book.php?lang=fr&format=pdf-a5&page=Les_Merveilles_de_la_science
https://tools.wmflabs.org/wsexport/tool/book.php?lang=fr&format=pdf-a5&page=Dictionnaire_infernal/6e_%C3%A9d.,_1863

In T213045#5154724, @Niharika wrote:

@dom_walden Dropping this in the QA column for you in case there's any further QA work you want to do here. :) Thank you!

The BlockManager gets the block appropriate for the user or IP, including setting from cookies, XFF headers, etc.

Are Blocks stored correctly in DB?

If I try to load visual editor on a page from which I am blocked, I get:

Error loading data from server: HTTP 500. Would you like to retry?

I have not see this error in the last few weeks.

Looking at the error and access logs on wsexport prod, I found a way to reproduce on production by navigating to: https://tools.wmflabs.org/wsexport-test/book.php?lang=ru&page=%D0%90%D0%BB%D0%B5%D0%BA%D1%81%D0%B0%D0%BD%D0%B4%D1%80_%D0%A1%D0%B5%D1%80%D0%B3%D0%B5%D0%B5%D0%B2%D0%B8%D1%87_%D0%9F%D1%83%D1%88%D0%BA%D0%B8%D0%BD&format=epub-3&fonts=freeserif

Going to https://tools.wmflabs.org/wsexport-test/book.php?refresh=true&lang= shows the form only once and there is no error in /data/project/wsexport-test/error.log.

I can no longer reproduce the bug in the description, https://tools.wmflabs.org/svgtranslate-test/File:USCG_Sentinel_class_cutter_poster.svg returns the appropriate translations.

@MaxSem I think the repro steps for this bug (or one way of reproducing this at least) is to navigate to https://tools.wmflabs.org/wsexport-test/book.php?refresh=true&lang=

Change appears very basic, relying on an existing SQL query.

@Tchanders I cherry-picked the two changesets in T206163#5110429 and T206163#5110430 on my local environment, and I have noticed that anonymous only blocks seem to get applied to users who are logged in. Not sure why.

A few more observations/potential bugs:

1. Sometimes, if I have an unsaved translation, after logging in I cannot upload the translation to Commons (even after reloading the page or switching translation languages back and forth). I have seen this happen on FF60, FF66, Chromium 57.
2. After successfully uploading a translation to Commons, I sometimes cannot upload a modified translation of the same language. I have seen this on FF60, FF66 and Chromium 57.

I have found can only get around the above two problems reliably by doing a hard refresh on the browser.

3. If I switch to a translation which already exists in the SVG, without modifying it I can upload to Commons.

=== Requirements

• If a user navigates away (or their tab crashes etc) from the translate tab in the middle of adding translations, their translations for the image should be temporarily preserved (15 minutes is good enough). In case they had multiple in-progress translations, preserve translations for all of those.

I noticed on en.wikivoyage this use of colour in a legend.

I looked at https://codesearch.wmflabs.org/deployed/?q=isBlocked%5C(%5C)&i=nope&files=&repos=, which contains a subset of what @Reedy mentions.

In passing, during T209004, I have found a couple of uses which might need to be changed:

• https://gerrit.wikimedia.org/g/mediawiki/core/+/4a20209c8e3f34c2582d05202cc07c20d0a628c1/includes/auth/CheckBlocksSecondaryAuthenticationProvider.php#61
• https://gerrit.wikimedia.org/g/mediawiki/core/+/24778af34dac5fc937d617cce2b275176d9f7183/includes/mail/EmailNotification.php#227
• https://gerrit.wikimedia.org/g/mediawiki/extensions/Echo/+/5796d46565fd36740eee657a3686d757a8dde009/includes/Notifier.php#44
• Several places in Extension:OAuth

One line CSS change.

I checked that filters were applied correctly for a combination of conditions (sitewide/partial, temporary, IP/Range/User).

I have not seen this happen on staging so far this morning.

In T220954#5121410, @MusikAnimal wrote:

I don't know how to check :/ Is https://commons.wikimedia.org/wiki/File:Chemnitz_Verkehr.svg an example? SVG Translate sees "simple" as one of the source languages. I did notice there's no dropdown on the File page to change the language from English to Simple English, as you would see with other multilingual SVGs, e.g. https://commons.wikimedia.org/wiki/File:Scheme_ant_worker_anatomy-en.svg

I have not seen this error anymore on staging or production.

When entering or removing text, I find a 1-2 second delay before the state of "Upload to commons" is updated. This gives me a window in which I can upload a duplicate image, giving the same error as T216209#5107613.

When logged out, there is a link "Log in to enable uploading". This takes a user to /svgtranslate-test/login.

Checked the image in the description and a couple of others I have seen this problem with previously (here, here and here).

I was not able to reproduce this on staging or production, using the SVGs in the description.

I was not able to reproduce this on staging or production, using the svg in the description. I also compared the SVG downloaded from svgtranslate with the one from Commons. The <tspan> style attribute is being preserved correctly.

On staging, I did not notice any dramatic differences in rendering of text between svgtranslate and Commons, or anything that looked obviously wrong (like the image in the description).

Looking at the revision history of the reports in https://en.wikipedia.org/wiki/User:Community_Tech_bot, I see all the reports have been updated in the last 7 days. I guess that means the cron is working.