Thought it best to ask :D some bug reports still remain an issue after that amount of time, others end up solved in another way outside the context of a given phabricator task

Also occurs on https://commons.wikimedia.org/w/index.php?title=File:UMK_2024_stage.jpg&useskin=minerva.

Fair enough :) duplicate move-log bug split to T395168: Duplicate log-events sometimes created for page moves.

@Reedy is this still an issue with WebAuthn? Spot-checking a few patches from https://gerrit.wikimedia.org/r/q/project:mediawiki/extensions/WebAuthn, quibble-vendor-mysql-php74-[no]selenium tests now appear to be being run for new patches, but I may be missing something here :)

True, but (from what I can see) I don't think there is a histmerge bug here — the two log events seem to be expected behaviour as a result of T118132. I guess I was thinking that this ticket would be reframed to be about the move-logs bug only, but no objections to splitting out the move bug to another task :)

In T395112#10852645, @Count_Count wrote:

Looks like there are no more instances of fully duplicate entries though, more general quarry query: https://quarry.wmcloud.org/query/93916

Regarding the history-merging log entries, I believe that's because of T118132: Merging pages should add a log entry to the destination page; and (if I understand correctly) the reason it's in English is because the patch that contains the German translation (https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1148205/1/languages/i18n/de.json#3674) hasn't been rolled out to WMF wikis yet (but should be on course to be deployed with next week's deployment train).

Turns out that the patch here seems to have also fixed T210816: [1.33.0-wmf.6 - regression] RC/Watchlist - red outline for "oo-ui-inputWidget-input" at the same time :D

@Etonkovidova Huh, seems like it might have been resolved since my previous comment! I can reproduce the issue on a newly-created patch demo wiki running REL1_44, but - following the steps in the task description - I am also unable to reproduce the bug on testwiki running 1.45.0-wmf.2.

Ah wait, it looks like this failure is already known about (xref T388531#10849157). Will leave it to the teams involved whether this should be merged/subtasked/etc.

+User-notice: IMO this feature is worth a Tech/News announcement if/when it's implemented; feel free to remove the tag if you disagree :)

Tagging owning team & serviceops (as the team handling the k8s cron job migrations).

In T341555#10834838, @Clement_Goubert wrote:

In T341555#10832816, @A_smart_kitten wrote:

Thank you for the detailed response @Clement_Goubert!

As far as duplicates go, as long as the name of the task isn't changed, and it is not closed, a single task with the title MediaWikiCronJobFailed is created by component, and future firings jobs in the same component are added to the task description.

Thanks for the note -- on this occasion, I only realised this after having already changed one of the tasks' titles to be more informative! (xref T392441#10762663)
It'd be slightly nicer from a quality-of-life perspective if the software behind @phaultfinder was smart enough to know/keep track of the tasks that it's filed; but hey, I guess we have to deal with what we've got :)

I've changed alerting to include the CronJob name in the task title for most alerts.

[...]

(As a side note, should these cron-job-failure tasks be tagged with Wikimedia-production-error?)

They probably should be, it would increase the chances for the unstewarded ones of someone with logstash access seeing them and adding information, and I think it also makes sense in general.

Thanks for the confirmation! :)
Would it be possible to configure the software behind @phaultfinder to automatically add the Wikimedia-production-error tag to these types of tasks (at least, in components that don't have an active steward), so that it doesn't rely on a human noticing the task & doing so themselves?

That's now done for every unstewarded task alert.

I can no longer reproduce this issue - I believe it has been resolved. Thank you @hashar for the patches! :)

Adding Wikimedia-production-error per the above request for Logstash logs

Looking at it more, potentially a duplicate of T390629: Wikimedia\Assert\UnreachableException: Trying to fetch node data without loading!?

Huh, checking on iOS Safari right now, I experience the following:

(Tagging for visibility, as I assume any pre-release policy might apply to MW+extensions+skins(?))

In T394681#10836252, @Michael wrote:

[…]
But it also makes a lot of sense to me to not accept a broken update of i18n files into the code base of core and extensions. That is how I interpret this task here to add banana-checker tests to gate-and-submit-l10n.

cc @Xqt

@CtrlZvi Thanks for submitting a patch! Just to confirm, has this issue now been resolved for you?

Thanks for the note, and no problem! Rerouting this issue to MediaWiki-skins-Pivot :)

Thanks for the confirmation! I'll see if I can try to reproduce the issue when I get a chance (hopefully in the next week or so). Feel free to ping me on this task for an update if it's been some time since this comment & I haven't said anything more.
(Of course, anyone else is welcome to attempt to reproduce this before me if they wish to do so :))

@S0ring, to confirm if I'm understanding you correctly, is the issue here that — there's a template with the following contents:

In T394588#10832463, @Aklapper wrote:

That's a decision of your web browser how to render space not used by / outside of the web page.

Thank you for the detailed response @Clement_Goubert!

Thanks @hashar! Testing it myself, the popup does still seem to appear when it shouldn't do, though (albeit with a bit more of a delay).

Thanks for the bug report! I'm merging this into T292764 as I believe that this issue is currently being tracked there :)

(boldly resetting the estimated story points field, as it seems like this might need re-estimation prior to being worked on again)

In T382217#10410747, @Kipod wrote:

[...]

worse yet, there is an undisputable bug in the implementation of this (bad/wrong) feature:
even though the changes in hidden cats are not shown, they _are_ counted against the "show XXX last changes" selection.
IOW, if i choose to display 100 latest changes and show changes in categories, and it so happen that the 100 most recent changes in my watchlist are all additions/removals of pages from some hidden cat (something that can easily happen in real life, e.g. when using a tool like cat-a-lot, or making some change in a template which adds or removes large number of pages from some maintenance hidden category), the watchlist will show empty: those 100 "filtered out" changes push out all the other changes from the watchlist.

Technically (as far as I can see) this is a re-report of the issue reported in T161756: Unchecking category leads to more results on plwiki, but this task's description is more detailed/clear about what the issue is than that task's description, so I've merged that one over to here :)

In T394485#10829225, @hashar wrote:

@A_smart_kitten thank you so much for having filed that task. I did notice the popup showing up but never went to spend time finding why it happened :-]

• Later this week, an updated [[Special:SpecialPages]] design will be used. […]

See also T142981: Provide a single entry point for notification that anticipates the urgency of the notifications received - potentially a duplicate of that task?

Can this be closed as resolved now that Trust and Safety Product Team is stewarding SecurePoll? (xref https://www.mediawiki.org/w/index.php?title=Developers/Maintainers&diff=prev&oldid=6902363)
(I assume that the discussions which led to that decision may have occurred outside the context of this task)

In T394111#10824021, @Reedy wrote:

I imagine the number of people that have patches only in REL1_ branches by backport is slim, but that doesn't mean we shouldn't cater for it.

Given @cscott's comment above, is this reproducible/does this issue occur with any versions of MediaWiki later than 1.38? If not, should this be closed as 'declined' given that MW 1.37/1.38 are no longer in support?

Yeah, kinda agreed with @Jdforrester-WMF here. In addition, as the proposed patch would modify the default behaviour of the Wikibase extension, it might potentially merit more discussion than has taken place so far (but to be fair, that'd presumably be up to the Wikibase maintainers).

@Reedy ccing you on this task as you're involved with the maintenance/security releases; and also tagging MediaWiki-Engineering for your thoughts, given that (if I understand correctly) MWE currently oversees the overall MediaWiki releasing process. (as a side note, is MWE's stewardship(?) of the release process documented anywhere/should it be documented anywhere?)

I think it should hopefully be safe to do so :)