In T223315#5188396, @Aklapper wrote:

@RhinosF1: You seem to have posted a few comments from the other task, but no answer to my question?

In T222533#5167080, @kostajh wrote:

Also, the "too many pages to display" message is no longer accurate and shouldn't be displayed.

@kostajh - Does this need a sub task or is it being handled via this task

In T223315#5186548, @Aklapper wrote:

(Removing team tags as it is up to teams what they plan to work on.)

Copied exactly from parent task

@RhinosF1: Unfortunately this report lacks some information. What do you expect to see? What do you see currently? Which specific criteria to apply which allow judging whether this task is done and successfully resolved at some point? Unspecific "make everything faster somehow" tasks are not helpful. :)

! In T222533#5168793, @MMiller_WMF wrote:

@RhinosF1 -- would you say that the larger issue is that the watchlist takes a long time to clear, or that the user doesn't have any warning that it will take a long time? The latter is obviously faster and easier to fix than the former.

! In T222533#5182114, @JTannerWMF wrote:

We will fix the message on this, however the speed is not within scope of this team. We believe the Core Platform Team would be responsible for the speed. We will use this Phab task for the message and Core Platform Team can use another for the speed.

See the above posts from the parent task that is being used to add a message alerting users temporarily while Core Platform Team improve the performance of clearing through an improved system

@JTannerWMF - Does the set up of the task I've done seem okay to you?

In T222533#5182114, @JTannerWMF wrote:

We will fix the message on this, however the speed is not within scope of this team. We believe the Core Platform Team would be responsible for the speed. We will use this Phab task for the message and Core Platform Team can use another for the speed.

Thanks @mmodell

In T222533#5168793, @MMiller_WMF wrote:

@RhinosF1 -- would you say that the larger issue is that the watchlist takes a long time to clear, or that the user doesn't have any warning that it will take a long time? The latter is obviously faster and easier to fix than the former.

I wouldn't mind just a note saying 'due to the way this feature works, changes to your watchlist may not show immediately as they are pushed through the job queue. You can see the status of the queue by visiting..... or whatever wording is best.
As long as people don't just keep trying for no reason like I did.
Obviously, if clearing being slow can be fixed then that rules out needing a message but I think a message should be put up at least in the meantime while that is fixed.

In T222533#5167419, @RhinosF1 wrote:

Per #wikimedia-tech IRC meetup

Per #wikimedia-tech IRC meetup tagging @CCicalese_WMF as they're showing as the senior product manager from Core Platform Team

In T222533#5167080, @kostajh wrote:

Yeah, the UX for this isn't great. What happens is that if you try to clear your watchlist (either editing raw watchlist and clearing the text, or by pressing the clear button), and the number of items is greater than $wgUpdateRowsPerQuery, the job queue is used for clearing the watchlist. That means you'll have no insight into the progress of the operation, nor really know what's going on. Usually the job queue works pretty quickly (a few seconds) but if it's backed up, it can take hours.

A message indicating this would be nice or some sort of warning on Special: Watchlist

Also, the "too many pages to display" message is no longer accurate and shouldn't be displayed.

That makes sense as currently It looks like that's preventing it clearing to just anyone

Input from a product manager or designer on the desired UX in these situations would be helpful.

@Aklapper Interestingly, my watchlist is now showing as empty.

Update: Edit raw watchlist and blanking that also fails with same error

In T218511#5151034, @RhinosF1 wrote:

In T218511#5150982, @IKhitron wrote:

Red alert.
Group 1 deployed, and it's much worse now. A lot of edits from previous days suddenly returned to be unbold.

Tagging train deployments if that's made it worse. Posted an alert in #wikimedia-operations

In T218511#5150982, @IKhitron wrote:

Red alert.
Group 1 deployed, and it's much worse now. A lot of edits from previous days suddenly returned to be unbold.

@mmodell @20after4: I note there's a phab deployment tommorow that you're doing. Will it be in that?

In T217789#5127467, @Adithyak1997 wrote:

@RhinosF1 Will it require any change in coding or just an installation of required packages?

In T44085#5104184, @Lea_Lacroix_WMDE wrote:

For now, the service is enabled on Meta only, because of the rate limit. However, linking from you wiki to the Meta page is possible and can already be done by the community (probably the interface admins)

@Ladsgroup - Any plan to deploy on all wikis? Maybe a link in the sidebar - Shorten URL / Shorten this URL.

In T209749#5101631, @Tgr wrote:

There's no way to check someone's password without having them enter it, so if you want to turn this into a more generic account security check (which would presumably cover password policies + 2FA as there's not much else we can check - a check for not loading unsafe Javascript would be nice but probably not feasible) that'd probably have to be some kind of private log where the user can add an entry by reauthenticating.

In T209749#5101423, @Xaosflux wrote:

If this becomes a 'This accounts meets the minimum standards for Account security' checker, then perhaps it should also have an expanded output if run on 'self' - declaring what components you are missing so you know what you need to remediate?

I think a message that says 'This accounts meets the minimum standards for Account security' is sufficient with it maybe revealing which points failed to highly trusted users or maybe just staff.

I know it's early but Can I suggest talks are livestreamed out?

I've seen on other sites so it might be an issue with chrome

In T219429#5091478, @RhinosF1 wrote:

In T219429#5091467, @Bawolff wrote:

Note, @RhinosF1 is also complaining about this issue in #mediawiki irc about the site https://thelostjewel.com/index.php?title=Special:Log&dir=prev&type=newusers&user=&page=&wpdate=&tagfilter=

Possibly they didn't fully run the updater.php, so maybe brokeness is ok, But I'd personally at least like ref integrity issues not result in the current user's ip being shown, as that seems dangerous from a PII leak perspective.

I don't run the site, I was just helping the user that does but upgrade from 1.27.0 to 1.32.0 when disastrous using an auto-update tool on Namecheap Hosting.

Took a while for update.php to be ran on the db after installing CheckUser as Site Operator didn't have command prompt access.

In T219429#5091467, @Bawolff wrote:

Note, @RhinosF1 is also complaining about this issue in #mediawiki irc about the site https://thelostjewel.com/index.php?title=Special:Log&dir=prev&type=newusers&user=&page=&wpdate=&tagfilter=

Possibly they didn't fully run the updater.php, so maybe brokeness is ok, But I'd personally at least like ref integrity issues not result in the current user's ip being shown, as that seems dangerous from a PII leak perspective.

In T220241#5090486, @Aklapper wrote:

Heh. Then I can only ask you to please be more patient here. :)

I will take that advice seen as I don't really understand the technical side of the project yet.

It's not fixed for me. Reopening.

For me https://phabricator.wikimedia.org/calendar/ shows

This is now fixed. Has anything changed recently?

In T220241#5090464, @Aklapper wrote:

@RhinosF1: https://www.mediawiki.org/wiki/How_to_report_a_bug applies as usual. Whether it's an upstream issue is irrelevant; someone will find out anyway.

Thanks for the Clarification, I'm assuming it's best to just report and let you lot figure it out.

To translate the conversation above to the real world: Something with your car does not work correctly. You bring it to a repair place as the task is to repair your car. A repair person claims the task by telling you they will investigate when they find time, without further comment. A few hours later you go there again and ask what's going on. Very likely they do not know yet and will tell you anyway once they have found time investigating and fix it.

You've not met me, I'd be looking for a garage that can do it as soon as possible and like to take control. I would be asking after a while if there's no timeline or idea of what's going on.

@Aklapper, I was asking as when originally reporting on IRC I was advised to report here even though we were unsure whether this was Phabricator's issue or WikiMedia's installation of it.

In T220241#5090196, @Aklapper wrote:

In T220241#5090165, @RhinosF1 wrote:

What's going on?

A software bug.

Very descriptive, Ive worked that out

Can you advise on workarounds?

Use https://phabricator.wikimedia.org/calendar/query/all/ or such.

Thank you

@mmodell, What's going on? Can you advise on workarounds?

My Device info:
Device: iPhone 8 (MQ6H2B/A or A1905)
OS Version: iOS 12.2
Chrome Version:73.0.3683.68

@Marostegui - No problem

In T220080#5087526, @Marostegui wrote:

Thanks very much!

Added with https://meta.wikimedia.org/w/index.php?title=Tech/News/2019/15&diff=18991805&oldid=18990102

Just noticed the toolforge logo is missing, this has resolved it for now.@Jdlrobson, @GTirloni - Any thoughts on next steps?</s>

@matmarex - Thanks for the info

@matmarex - Any updates?

That should be better

I think all error messages need to be revisited - Theyre not very descriptive. (See T216496)

@Jdlrobson - Nope, looks fixed then

My browser info:
iPhone 8 (Model MQ6H2B/A)
OS: iOS 12.1.4 (16D57)
Browser:Chrome for iOS 73.0.3683.68

Issue last seen 14/03/2019 at 18:15ish UTC if it helps

@Aklapper - Ive taken it out.

@Jdlrobson - Bug is NOT reproducible on either link you've given.

Was a user issue, should have been common.js instead of commons.js

@Jarry1250 - Fixed it for me, closing.
I've assigned it to you as well.

AlexBoldt - Please read the task I said was merged into this as I can still reproduce that behaviour that has videos of the issue but It may link more to @kaldari 's issue which confuses me as to why it was merged here.

In T211490#5030072, @AxelBoldt wrote:

@RhinosF1 - It's not quite clear to me what you are seeing with persistence and zooming. Is it the exact bug described here, i.e.: the wiki text inside the editing area cannot be scrolled further up just after you've started an edit session and the virtual keyboard has appeared?

Or are you seeing something akin to what @kaldari has described above, namely: you can't scroll up to reveal the Save button when trying to submit your article edits?

The latter issue is not what this bug is about.

In T211490#5027853, @RhinosF1 wrote:

In T211490#5027841, @RhinosF1 wrote:

@Jdlrobson - Seems to be fixed 99% of the time but with persistance I can zoom in/out enough I get:

Browser info:
iPhone 8 (Model MQ6H2B/A)
OS: iOS 12.1.4 (16D57)
Logged in: Y
URL of page: https://en.m.wikipedia.org/w/index.php?title=User:RhinosF1/sandbox&mobileaction=toggle_view_mobile#/editor/0
diff: https://en.m.wikipedia.org/wiki/Special:MobileDiff/887924872
Browser: Google Chrome (73.0.3683.68)

@Legoktm - Thanks, will do!!

To clarify its a soft redirect

In T211490#5027841, @RhinosF1 wrote:

@Jdlrobson - Seems to be fixed 99% of the time but with persistance I can zoom in/out enough I get:

Browser info:
iPhone 8 (Model MQ6H2B/A)
OS: iOS 12.1.4 (16D57)
Logged in: Y
URL of page: https://en.m.wikipedia.org/w/index.php?title=User:RhinosF1/sandbox&mobileaction=toggle_view_mobile#/editor/0
diff: https://en.m.wikipedia.org/wiki/Special:MobileDiff/887924872
Browser: Google Chrome (73.0.3683.68)

@Jdlrobson - Seems to be fixed 99% of the time but with persistance I can zoom in/out enough I get:

In T211490#5025103, @kaldari wrote:

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

Note that this happens any time I try to enter an edit summary.

Kaldari - T217259
See the mentioned in section

Kaldari - See T21759 and other merged tasks.

@matmarex - When is it due to go live?

In T217789#5006737, @JackPotte wrote:

The error 500 is due to the absence of Python package on the new Toolforge server:
"ImportError: No module named MySQLdb"

But the Python CGI performances make me think that it's not worth rewriting these tools in Python 3. We'd better migrate them to an asynchronous technology, like we did for https://xtools.wmflabs.org/adminscore. And I don't have the time to do it. FYI, the source code is here: https://github.com/JackPotte/snottywong

In T217789#5005976, @RhinosF1 wrote:

I'm not sure how it would work @Aklapper, I was advised on IRC to post here.

I've notified Snottywong at https://en.wikipedia.org/w/index.php?title=User_talk:Scottywong&diff=886500650&oldid=886420107&diffmode=source as I can't find their phab account.