@kzimmerman - Since Analytics was unable to provide any information for us, we did the work ourselves (per T166269#3346965). I think this ticket is a great example of Analytics' difficulty with providing Product with basic ball-park data to help with decision-making and community discussions due to Analytics' self-imposed requirements for perfect data (which is almost never possible in the context of Wikipedia). We need some sort of process where we can get Analysts to give us ball-park data quickly, rather than waiting months for reports that never materialize. This is one of the main reasons why PMs are asking for dashboards.

I think this might be a duplicate of T221190 though.

@ppelberg - No, this is a separate bug from T167078 (although that was a good guess). VE specifically told me that I was blocked after trying to save my edit (rather than saying "Error: Edit not saved"), and I wasn't trying to add anything from the spam blacklist.

@ppelberg, @Ryasmeen - This needs tests.

@alexhollender - Personally, I never go directly to Special:Logs. It's almost always from a user or page specific link (with preset query parameters). It's not a terrible idea though. Putting Wikipedia:ArticlesForDeletion in the sidebar seems a bit strange, though. What would be more useful, IMO, would be having Special:MovePage in the sidebar, as otherwise it is quite difficult to move a page manually on mobile: you have to manually go to Special:MovePage, and remember the exact title of the page you wanted to move, which is often tricky if you're moving the page due to a misspelling or bad title. There should be a way to reach Special:MovePage directly from the article context (and have the title pre-filled as it is on desktop).

@jmatazzoni - I added some new documentation at https://www.mediawiki.org/wiki/API:Userinfo. I still need to write up an email for Leighanna and Trust and Safety.

I dug through the old code and looks like it was using jQuery UI Selectable. Just adding that here for my own reference.

Perhaps @MMiller_WMF or @RHo could answer your questions.

Thanks Ed! Looks like if the query string includes "vehidebetadialog", the dialog will be suppressed.

@Esanders - Is it technically possible for Getting Started to suppress the introductory editing dialog that VE presents?

I'm with @thiemowmde. I originally filed the URL shortener bug and have been following its progress for 7 years. At no time did I or anyone else ask for special reserved URLs that are easy to remember (AFAIK), and no one's really made a good argument about why they're needed. I say launch it as is and let people start using it.

Do we really need to reserve 729,000 URLs for special use? Reserving 1-letter URLs makes sense, and maybe 2-letter, but 3-letter seems overly cautious, IMO.

@jmatazzoni - Perhaps it's related to the fact that I copied and pasted the category name into the interface rather than typing it.

Note that current versions of Vega (since 4.3.0) need ES6 support, so we would either need to transpile Vega with Babel (slightly increasing the JS footprint) or keep Vega locked at an older version. Some back of the envelope calculations:
Minified transpiled Vega core: 442 KB
Minified d3: 222KB
Total extra JS load (minimum): 664 KB
Obviously, we couldn't load that for every page as it would more than double our JS load per page, and we probably wouldn't even want to top load it on pages that needed it. It seems most realistic that we would end-load it on pages that need it and show a spinner in place of the graph until then (as suggested above).

I like it!

@chasemp - You may want to include Marcella's ticket at the same time (T215961) since it's similar (Engineering Manager needing access for triaging, etc.)

Sorry for the last minute interruption! Danny has requested that we freeze any further Flow deployments pending the outcome of the Talk page consultation process.

@Urbanecm - Considering the uncertain future of StructuredDiscussions, I really hope that more wikis aren't going to convert their Help desks to it as there's a good chance this will cause headaches in the future.

It looks like the CSS explicitly suppresses any indication that the title is a link :(

@jmatazzoni - No, it definitely happened on my first attempt to add a category.

@Samwilson - Do you want to disable these tests in the meantime? They seem to be causing trouble: https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/TemplateWizard/+/499879/

If it seems like this will cause too many expensive queries, we can live without it.

@Nickps, @Neil_P._Quinn_WMF - Can either of you confirm that this bug still exists? The scrolling code for mobile editing has been significantly refactored.

@aezell - There's a whole slew of related (but more specific) tasks in Phabricator. Not sure how these should best be organized...

Overachievers! ;)

Wow, that's super complicated. Have y'all considered just using a PNG pokey like the Echo overlay?

I understand the main issue here is my connectivity, but I'm wondering if there's some way we could work around the connectivity problems. When I'm on a shitty connection, which is pretty often, especially when I travel to other countries, I can pretty much forget about uploading anything to Commons, which is unfortunate. It looks like T205619 is probably the same issue.

@Aklapper - I don't know if this helps, but I tried running PingPlotter while I was doing the upload and monitored connectivity to text-lb.eqiad.wikimedia.org. For the first 5 minutes I'm just running the monitor, then I start trying to upload (which is where you can see the latency shoot up), then the upload gives up after a couple minutes and the chart goes back to normal:

@Cyberpower678 - did you get a chance to update the DeadlinkChecker library that IABot is using? The most recent version (1.7.3) should have fewer false positives for soft 404s.

This doesn't need to be complicated. Just change all local links to point to the source wiki instead (as Pete suggests above). Anything else is unnecessary overkill.

Here's a graph Ed generated of number of saveSuccess events in iOS. Looks like there was a noticeable drop around Feb 20th, which might be related to this bug. David Lynch hypothesizes that the bug mainly affects iPhones with smaller screens.

Filed separately as T218352.

Rummana was able to reproduce, but says that my bug is a different bug than this one. I'll file separately.

@RhinosF1 - Thanks, pinching works to get around the problem!

Screenshot of bug on my iPhone. Can't scroll up from this position.

@RhinosF1 - I think you linked to the wrong bug. Did you mean T218062 or T218069, maybe?

@matmarex - This bug prevents me from being able to save an edit while on my phone (unless I either switch to VE or don't put an edit summary). English Wikipedia has already been updated to 1.33.0-wmf.21 and I cleared my browser cache on my phone, but it's still broken. Either the JS/CSS is still cached on the server side or that patch didn't fix the problem.

Same bug happens on regular iPhone.

I adjusted the DeadlinkChecker code here: https://github.com/wikimedia/DeadlinkChecker/commit/8762b9b78730fb7a2b4bedcfcf89b8b4b2572094
Cyberpower will need to update the DeadlinkChecker library on his end.

I checked the first 10 URLs found by English Wikipedia search that contained "404.htm":

Six are alive and only four are actually dead. It looks like if we tighten up the rule to look for "/404.htm" instead of "404.htm", we'll get a lot fewer false positives (only 2 in this case instead of 6).

The rule is actually more strict than that. The URL has to contain "404.htm". This is a hard one since we would be eliminating some rare false positives, but then missing a potentially large set of legit positives. I think Cyberpower's suggestion to whitelist them in IABot seems like the best approach for now (unless we hear more reports of this problem).

This seems to be stalled. Pinging @zeljkofilipin in case he has any ideas.

I hope!

And of course I can't reproduce the problem here in U.S. Even uploading huge files that take multiple minutes to upload work fine. I wonder if it's related to reliability of the internet connection.

What about deleted/revdeleted contributions, though?

Support and Safety recommended against providing deleted/revdeleted contributions. They can still be requested, but they have to be requested manually and handled on a case-by-case basis.

@MoritzMuehlenhoff - Now that the Thumbor hosts are upgraded to Debian Stretch, and Cargo has been made available in Stretch, are there any remaining blockers to upgrading librsvg to ≥2.42.3? Do we need to create a task for upgrading Stretch to ≥9.4, or is that relatively trivial?

@ssastry - Do you know of any changes in the HTML rendering on Commons around November 25th that might be related to this?