Hell yeah. Thanks for y'all's work on this., Hugely appreciated.

Just noting I just got Sendmail exited with non-zero exit code 74 twice in a row when attempting to email the Oversight user (!) on enwiki. (I then switched to sending via normal email.)

Looks like this is a known limitation documented here.

I currently don't have quite enough time to say in the short term that this is something to work on, though it's entirely possible (and somewhat likely probably around December) that I'll be able to get back to this if no-one else does.

Resolved on testwiki.

It's worth mentioning that at least one component of this issue is the fact that all whitespace query names are allowed, which is actually what causes the blank entries to show up in the recent queries view. This should probably be disallowed and also migrated to use a default query name. (Or implement a default query name on the web UI side.)

Confirmed, thanks, and congrats on the release! :)

Aha! Okay, I got this to work:

❯ DOCKER_HOST=unix:///Users/perry/.docker/run/docker.sock mw docker dc ps
WARN[0000] The "SHELLBOX_SECRET_KEY" variable is not set. Defaulting to a blank string.
WARN[0000] The "SHELLBOX_SECRET_KEY" variable is not set. Defaulting to a blank string.
WARN[0000] The "SHELLBOX_SECRET_KEY" variable is not set. Defaulting to a blank string.
NAME      IMAGE     COMMAND   SERVICE   CREATED   STATUS    PORTS

I do not, but I'll go ahead and figure out how to debug Go to see if I can figure out anything since that'll save you some trouble.

So I can't think of any way to work around this, since it's not something we can gate with @supports, besides like... just removing the parent .mw-parser-output selector which isn't really a good idea, so I suppose this is something that just needs to be fixed on the local side. I'm not going to close this right away though in case anyone has some other idea that I haven't thought of, or if anyone believes this issue should stay open albeit unfixed for now (e.g., until we have wider support for :where in like ten years or something).

Hrm, well shoot—I suppose that is the correct answer (curse doing things the right way...), but that does make this more complicated.

Thanks for the clarification—to be clear I was testing on Edge as a rough proxy for what it would look like on a browser that doesn't support :where(), and I didn't notice any significant issues.

I actually checked in Edge's IE compatibility mode (best I have for testing grade C right now) and things seemed fine, but I'm happy to be corrected if I missed something. (It's possible that between IE (which isn't even supported but it's what I had in a VM :P) and between supported browsers that there's a browser with more of a problem.)

Does Minerva still need its version of this styling now that it's been upstreamed, or can it be removed? The only difference is Minerva sets the border of .content table.wikitable to 0. Would like to know since I'm touching it as part of fixing T403779. See here.

Could this be from https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/1183154?

I can confirm when the issue occurs that editAttemptStepHandler is never called, and it is called when the edits do save. It seems like it commonly (always?) happens when, on a talk page, I use "edit section" and then try to save some new text.

Yeah, this is due to a client JS exception. I just got a breakpoint down, so I can now confirm this is during editAttemptStep.js 's handleInitEvent. This means that handleFirstEvent is never getting called, meaning that editAttemptStepHandler isn't getting called. So maybe editAttemptStep isn't getting hit when it should be?

This has been happening on enwiki too for me when using the 2017 wikitext editor. As soon as I reload it tends to resolve itself. You can see an example console error for it in P82432. (I don't know why it's formatted so weird; it looked like that in the browser console too.) Judging by that, it seems like it could be related to WikimediaEvents.

Yeah I'm not super torn up about it, and I do definitely prefer the deeper indentation that Timeless has. It does make me a little sad though. :)

@matmarex, is there any chance I could get your eyes on the above? I know it's a new feature and not just a bugfix, but it would be really nice to get this in and you're all I got for +2 right now. :) (No pressure if you're understandably busy!)

Hmm. It's built via Scribunto which manually puts in some calculated width in ems for the depth that's passed as an argument. I guess one funny (hacky) way of doing it would be to have a skin specific templatestyles for its containing div that sets its fontsize. Would then have to switch the height style it has to be in rems instead of ems so that's not affected?

In T402747#11129379, @jsn.sherman wrote:

We are planning to end this experiment no later than 9/15, so I suggest that we live with it as it is for now and take this into account ahead of our next experiment.

Hm, after some discussion with someone else I think it makes more sense to rely on things like edit notices or core changes to help with this specific use case (i.e., don't use edit filters for working around suboptimal UX). Since I think the applicability of this function is pretty limited otherwise, I'm going to close this, but if anyone does want this functionality for a use case I haven't thought of then I do have a patch for it locally and am happy to submit it.

A quick prototype that checks for existence via Title::newFromText(blah)->isKnown() ends up having a runtime of a bit over one millisecond when put into a basic filter that does the use case mentioned. That feels like it's on the high side but I'm not sure if that's prohibitively high.

That's interesting, I want to look to see what happens when you don't select Vector 2022, do we pick some other skin you've selected? I don't know offhand.

Hmm. The tricky part is that there's a hidden element which is currently set as invisible but still reserves space (I'm not sure why it's set to take up space. Since I assume there is a plan to maybe make that control visible, I would suspect that it's necessary to also design around its layout as well? Here's what a video of what the layout looks like with that element visible:

Yeah, the accessibility support for Timeless right now is... rough. The issue is it's not just this but a whole lot more. (Lots of semantic element violations, many more issues of poor tab support, and pretty poor usage of aria attributes. I'll see what I can do to address this specific issue but there's a whole lot more that I want fixed too.

This seems resolved: with grouped edits enabled, the font sizes from recent changes versus watchlist seem the same to me—15.2 px. The font size for inside a group of edits also seems to be 15.2 px. Please correct me if I'm wrong or missing something!

Not sure when it got resolved (no results from git log -S box-pack?) but this seems to no longer be the case.

Seems fixed since I'm not seeing any issue here now.

Ah! Yeah, I see it now. Yup, it just wasn't getting passed the username even though it should've.

Is this still an issue? I see that you updated the translations a bit before you made this issue, and those have since been merged in—it takes a bit for those to get updated (a week or so for WMF wikis).

Interestingly, this doesn't seem to affect Safari, as it seems to treat the conflicting text-decoration shorthand that it uses versus the text-decoration-style longhand that is normally present. Easy enough fix though!

Hm—I might not be following completely. What I have right now is one usage of CentralAuthTestUser (though I think maybe not strictly necessary now that I think about it) in order to have a non-locally existing user. The rest of the users are then made with getMutableTestUser when I then call CentralAuthUser::getPrimaryInstance on and then register, attach (to current wikiId), and insert into localnames (also for current wikiId). This seems to work okay, unless there's a subtlety that I'm missing.

Note that I'm taking a stab at the approach suggested in T261752#10917331, which I think would mostly resolve this issue, though the property support in the current patch isn't as extensive as what globaluesrinfo has.

Ah! Thank you, that works great. The only issue I'm running into is testing if a user is attached locally—it seems that no matter what I do (via TestUser or CentralAuthTestUser), they're never actually made to be local according to CentralAuthUser::existsLocally. I assume there's just some method that I'm missing here, though I suppose it doesn't help that I don't really know the difference between an account being attached and it existing locally. (I think the latter is that the user simply exists in that wiki's DB but I could be wrong.)

Keeping this ticket open despite it being younger since it has a bit more activity (and because I'm super biased).