FWIW I also found it very confusing when someone thanked me for both the edit and the comment recently. I feel like there isn’t really a circumstance where allowing people to thank for edits that are simultaneously comments is warranted enough. Obviously you wouldn’t want to prohibit such thanking entirely but it looks like a bug more so than a feature.

The logic for these decisions would also apply to desktop editors.

Does this mean that it doesn’t matter where a person edits, their edit level would reflect what they see on mobile, or something else? Because if the answer is ‘something else’, then this is a huge breaking change that would never be accepted by Wikimedia communities. The notion that certain features need to be hidden from people is not something that should be decided by WMF developers (which, let’s face it, don’t have enough hands-on experience here to know what they’re doing is good) without community approval.

A bit confused about this task because Advanced Mobile Contributions mode already includes that link in More dropdown (option 2):

FWIW it didn’t get a lot of questions in Russian Wikipedia, just this one (with some suggestions that it should link to the actual start of the article instead):
https://ru.wikipedia.org/wiki/Википедия:Форум/Технический#c-Jet_Jerry-20260503213500-Редактирование_первого_раздела_статьи

This basically breaks the easiest ways to edit sections for templates with documentation pages. It is quite unfortunate that there is also no way to differentiate Parsoid-rendered pages from non-Parsoid ones via CSS since I’d rather hide those edit links while this bug is still active than mislead people into thinking they lead somewhere useful, like they did before.

Are you sure you’ve visited just the page with underscore? Because that’s where the problem lies here: unless you go through a Parsoid URL with a space instead of an underscore, it is not highlighted as visited, even if you already visited it. I doubt that’s different in different browsers, and I am on Windows 10 anyway.

In T379645#11921970, @cscott wrote:

This seems to be a Safari bug, though, not an inherent feature of URL normalization.

No, this happens in every browser and is different from the Safari bug reported in T425211: Link colours on mobile not changing to purple when clicked on. I use Firefox only and on my own user page I don't see the page for the script I wrote marked as visited because the interwiki link uses spaces:
https://ru.wikipedia.org/wiki/Участник:Stjn (Ctrl+F for Translator Buddy)

@OSleger-WMF are you sure it’s the same bug? I was also under this impression but it seems different since users report that they don’t see it just for interwiki links.

In T294188#10435047, @CCiufo-WMF wrote:

Not sure how much of an interest there still is in updating this icon, but the Design System Team may revisit the icon set holistically some time this year, and we can take this icon into account (cc @DTorsani-WMF).

Now that it’s being used by Vector 2022 for all users, definitely something that’s needed. Someone put it best that this is a move icon for photo editing software (or some drag and drop situation), not an icon for renaming something.

I’m not sure if POC is purely for demonstration purposes as it’s unclear from the task text but, if it’s not, please be aware that changing the order of the sections with CSS does not change the accessibility tree of the elements, so any potential section-swap should only happen server-side for accessibility reasons.

2026 version of this bug does this at https://ru.wikipedia.org/wiki/Макмиллан,_Дональд

<a href="//ru.wikipedia.org/wiki/en:Peary_Polar_Expedition_Medal" title="en:Peary Polar Expedition Medal"><img resource="//ru.wikipedia.org/wiki/Файл:Perry_Polar_Expedition_Medal_ribbon.png" src="//upload.wikimedia.org/wikipedia/commons/thumb/9/91/Perry_Polar_Expedition_Medal_ribbon.png/60px-Perry_Polar_Expedition_Medal_ribbon.png" decoding="async" data-file-width="212" data-file-height="60" data-file-type="bitmap" height="17" width="60" srcset="//upload.wikimedia.org/wikipedia/commons/thumb/9/91/Perry_Polar_Expedition_Medal_ribbon.png/120px-Perry_Polar_Expedition_Medal_ribbon.png 2x" class="mw-file-element"></a>

The link is not to a wrong place but because it’s not resolved properly, you see a failed Page Previews popup.

Ugh. Thought so at the first glance but then thought it was too weird to be true on a wiki that uses Parsoid by default :-/

https://en.wikipedia.org/wiki/MediaWiki:Blanknamespace is locally defined to be (Article). If the dropdown somehow displays (Main) despite that, that’s a bug that should be fixed in a separate task. FWIW I see (Article) there.

@JSengupta-WMF I don’t think this is a correct link since it’s not about watchlist star at all?

Same with Special:MovePage btw (and I assume Special:Undelete? no idea).

I feel like even if you are able to add your own username via preferences to Special:Mute, this is definitely not something that should be visible to the end-user. @Dreamy_Jazz, do you have objections if I submit a simple patch that removes the link to Special:Mute from my own contribs?

I prefer the current dropdown to stay so I’ll brainstorm my own solution. To be honest, I really dislike typing in those selects that @matmarex proposes, so I feel like that would be an even bigger downgrade in comparison to a plain old <select>. To me the ideal for most people would be something like this:

1. We show the full title in the page title field while keeping the select. The validation for how long that title should be can happen on the server/client without counting namespace name, but we could limit the field itself to 256 + [number of symbols in the longest namespace name or alias] if we really cared. I think MW JS code that can count remaining symbols can be used to count it to specific amounts of characters, so we could adjust how many symbols are max allowed depending on the input before the first :.
2. When the namespace part of the title field changes without adjusting the namespace select, there is a checkbox prompt shown to user to confirm changing the namespace to the new one.
3. If they check the checkbox with JS enabled, the select instantly changes to the new namespace choice and the title gets normalised (WP: → Wikipedia: etc.). The prompt gets unchecked and hidden again until the next change. The label could be something like Confirm namespace change to Wikipedia (bolded).
4. If they have JS disabled, the prompt to confirm the namespace change gets displayed on form submission before a rename. The resulting name of the page should be displayed, so something like Confirm move to Wikipedia:Foo (bolded).
5. When someone changes the namespace in the namespace select on their own, we assume they did this willingly and don’t ask to check. With JS there should be a simultaneous corresponding change to the text field text. Without JS there should be a confirmation prompt if the title ends up to be something like User:Wikipedia:Foo.
6. There are titles like Category:Wikipedia:Articles for deletion in a number of wikis. Those shouldn’t be touched or asked about unless someone changes the namespace field.
7. Just so it’s not confusing, there should be a label above namespace select and the label beside the input can be changed to Full title.

Yeah, just tested share API at https://6e9260483c.catalyst.wmcloud.org/wiki/Алан_Тьюринг with Firefox for Android and it also only copies URLs encoded. I think that’s a definite ‘no’ for anything aimed at the editors (and honestly why I might end up switching experimental flag off on desktop once T18691 hits the production).

In T418197#11886303, @matmarex wrote:

Should DiscussionTools's option do the same, or be different?

The other parts of DT copying don’t use share API so probably best not to use it here, either. Especially since right now it allows to quickly copy something while share API is a bit more intrusive to editor experience (at least I found it so while testing in Firefox), and doesn’t actually allow to copy Unicode as Unicode in all contexts (definitely not on Windows 10 where I tested).

It's the same as with not having Talk tab on most wikis even though that’s the basic feature of all MediaWiki websites: the development team is thinking of mobile website as a cut-down, dumbed-down, readers-only version of the desktop interface, so anything too inconvenient was cut a long time ago and now there’s resistance to getting it back there. Which is ironic considering that the WMF seems to want to improve the mobile editing experience in the following year.

Sorry, may have been premature. This is specific to mobile Parsoid according to reports:

• https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Links_not_changing_colour
• https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Some_new_mobile_(web)_issues

but probably not exactly the same as that other task.

T379645: Parsoid does not convert underscores to spaces for interwiki links is what causes this discrepancy from Parsoid, and I doubt there is another reason for it so I closed this as a duplicate. On mediawiki.org specifically, it is also the fact that there are Special:MyLanguage/ links there which do not lead exactly to the pages you end up on.

Similar thing with disambiguation box styling missing on mobile:
https://en.wikipedia.org/w/index.php?title=Alexander_(disambiguation)&useparsoid=1&useformat=mobile

I do somewhat worry that this implementation would cause newcomers to fill in the section part instead of writing after it, but they already do it sometimes, I guess.

Heads-up for others after updating https://ru.wikipedia.org/wiki/MediaWiki:Gadget-edittop.js that this is now inserted automatically when editing section=0 (T2156#11881517).

Would be nice to somehow add it to their overflow menu on mobile. Not a necessity of course but this is probably one of the most useful feature applications for the editors.

In T18691#11882580, @egardner wrote:

Introducing similar functionality outside of the experiment (but at the same time) is just going to add confusion.

I don't see a problem with this going out to Vector but I'm opposed to making this change on mobile right now. We can revisit after we have A/B test results from the ShareHighlight experiment.

Then ShareHighlight experiment could remove that link for people using it, as I mentioned. This is going to be a core feature so turning it off for a WMF-run experiment would also affect, for instance, translatewiki which also uses the latest alpha but won't have the WMF-specific extension.

It feels to me that hiding the link from Minerva is extremely wrong if it's something that's going to be in MediaWiki core. The icon ID should just be fixed to display a supported icon, third-party wikis won't have the same experiment (never mind that it's also not a given it'll be kept) for the WMF wikis. If the experiment devs decide section links are detrimental, they could just hide it themselves.

In T18691#11881882, @DLynch wrote:

The no-js display issue is because VisualEditor assumes that when there's no JS .editsection-divider should be given display:none, which is normally correct because it's part of hiding the "edit with VE" link... but now there's another element present and it all falls apart.

But isn't this link practically useless without JS? Or at least should be renamed to 'link' or something since it's not going to pull up a share menu.

Looks like this with JS disabled:

Meant to tag the other Sam, apologies to both.

It seems to be a bug since unwatch popup closes with Esc. It's also a clear accessibility violation and probably not intentional. @Samwalton9-WMF any ideas?

I very strongly dislike the suggestion of experienced editors that newbies should know some keyboard shortcut to use site features beneficial to everyone. I use temporary watching and it's amazing. I don't have a use for watchlist labels yet but it doesn't mean someone else won't. There is no access issue to doing two taps on mobile, people do them there every day. If anything, it's more beneficial on mobile because you cannot accidentally unwatch something any more.

In T417847#11877950, @Samwilson wrote:

A few people have said that one-click unwatching would be good, but I'm still not sure how that should work now that we've got watchlist labels — is unwatching more useful than being able to change the labels (or expiry) for a page? Because if you click to unwatch, then you also discard your labels. We thought about adding a second button next to the watchstar, but that's a lot more complicated (especially now that the watch link is also more likely to appear in the tools menu, if Reading Lists is enabled).

Discord (and maybe some other apps) offers to skip the confirmations with Shift-click. I think that's sensible as a way for experienced editors to adjust to it, as long as it's shortly mentioned in the popup.

Currently on latest Firefox, Windows 10. I see a variation of the same thing happening on latest Edge (old suggestions appear, then new ones replace them). It happens on Special:Search pages for some result when you do the actions described in the task. I do them because unfortunately Special:Search input suggestions do something different from regular ones on top (they do not redirect to the page directly, see T210649: Suggestions in a search field on Special:Search should act the same as suggestions in search bar).

All of this was logged out since I don't use Vector 2022 logged in. I just visited the page again and did the same and the same thing happened, so there's definitely something. I suspect it might have something to do with search suggestions from the search input on the page maybe?

In T142981#11119985, @Samwalton9-WMF wrote:

A +1 vote from me for doing this. I've been editing the entire time Echo has been available and I still couldn't tell you what the difference between the Alerts and Notices is, let alone any time that my behaviour has been different as a result of them being separated as compared to if this was a single tray. It seems absurd that Vector 2022 only has room for ~5 important icons in the top right and two of them are notifications.

That's a problem with skin design that shoved everything into dropdowns and then told us that there's no space. There's a pretty simple separation there, one type of alerts is important to look at ASAP and the other is various cruft. The problems introduced by Vector 2022 should be fixed by changing the bad design of Vector 2022.

In T308286#11831371, @Iniquity wrote:

If there is any way to change the serif to sans serif, that would be absolutely fantastic.

I don't think there is enough consensus for this, especially when logos in other languages have serif there. I think we should stick to what was actually discussed and supported in writing. (At least unless English would also have the same change of fonts.)

Also, if the intent is to safeguard users from malicious JS execution, then it should be possible to enable safe mode for yourself and then not have to deal with the annoying and ill-written restrictions that exist right now. I would much rather toggle that setting and do my edits in peace than have to re-login every 15 minutes for no reason (I don’t think any website is as draconian in their restrictions of this kind, even Github's sudo mode for changing restricted settings is much more permissive).

Yeah, I see no reason why it shouldn't be 9 (IIRC) like in ULS suggested languages list itself.

My current goal is to say that the half-baked solution that isn't relevant to the incident but did significantly increase the friction of doing good-faith edits should be removed and the actual solution should be done with care and consideration to the editors and without that friction. If the point was to make people stop doing the edits as much as possible, then I guess it's not a problem.

In T197137#11821539, @matmarex wrote:

The details may not have escaped outside of WMF, but I know that @sbassett has been appropriately contrite. Please focus on the problem rather than the person who has accidentally reminded us how easily the problem can happen.

The details are pretty much public. There is no way any competent interface admin on any wiki would load thousands of scripts from random users, especially users with no edits, to check if they're working after the changes they've made. The fact that after this wild malpractice interface admins are suffering from unnecessary and ill-written restrictions (that are not in any way related to someone running thousands of scripts from their privileged account) is an insult. And the elephant in the room in this whole situation. The security team didn't expose anything that wasn't known by them for years, they just exposed themselves to the silliest exploit.

If this worked independently from ULS or at least from compact links feature, it would also be able to replace a number of gadgets for this purpose in Russian Wikipedia:
https://ru.wikipedia.org/wiki/MediaWiki:Gadgets-definition#interwiki

The first example has nothing to do with the second, though, see markbot at https://www.mediawiki.org/wiki/API:Rollback

You can customise that message on your wiki.

In T248294#11792451, @IKhitron wrote:

Sounds great, but can you please add a link to this special page to MediaWiki:Noarticletext? Otherwise, it's pretty unreachable. Something like "You can create this page or create it with a different content model".

This is something very technical so it shouldn't be easily accessible in most namespaces anyway.

Since same question in T197160 might be ignored, what's the timeline for making re-auth less painful to deal with? It's been 2 weeks since your self-inflicted petard hoisting incident. This actively prevents people from making well-intentioned edits.

After doing some gadget edits, I can only agree with the comment above by @Nux wholeheartedly. Currently you need to re-login every 15 minutes, you're required to re-login if you're renaming something into MediaWiki namespace without any actual way to do so, and there is no actual logic behind this decision. Frankly, it is unacceptable that WMF has shown such a glaring lapse of judgment and then forced everyone else to suffer as a consequence.

And https://ru.wikipedia.org/wiki/MediaWiki:Gadget-vector2022KillSwitch.js was turned on to provide a way to easily disable the forced upon skin

Does navigator.share require encoded URL to work? Because that's what's currently gets passed there.

Not entirely since my task is about making it so there are no font size jumps between heading levels, as that makes to jarring to enter heading markup, and not about disabling size difference itself.

Would be great if for this feature it was possible to override the default behaviour to do something else. That way, Wikipedians could set it to display a popup with various types of link syntax and regular readers could just get Web Share API or a fallback.

Unicode being encoded is not ideal. Most websites and apps these days support readable links, and this renders the potential feature not useful for non-Latin wikis.

That script was running synchronous code once per a page loaded, which anyone with basic JS knowledge should be able to tell. Having it in an open tab would've done nothing after it already ran once on that tab.

In T419152#11680996, @mszwarc wrote:

So, yes – additional reauth for editing JS wouldn't have prevented the original bad things from happening, but would make it much easier to remove the malicious code from wiki, without the need to make it readonly.

There was never a need to make the wiki, and especially all wikis, read-only. That only happened because there is no protocol for these types of issues despite them already being very known. What should've happened was some account going into safe mode and dealing with the consequences. That's it. Doing site-wide read-only for hours was just another mistake by the WMF yesterday.

Yes, all in all it is unfortunate that a mistake on the part of the WMF is being used to push half-baked solutions that would not have prevented the issue of sticking a fork into various electrical sockets until one backfires. The handling of the incident was subpar to say the least. I can only hope that the re-login 'solution' would be amended swiftly to be less intrusive.

In T197137#11679454, @Bawolff wrote:

Instead of making the edit action require 2fa when editing a js page, an alternative version might be:

• have interfaceadmin be a group that only allows adding yourself (with an expiry) to a group called interfaceadmins-real that contains the real right.
• have changing group rights require reverifying 2FA.

I think that would be easier to implement in the short term. We've basically got all the pieces already.

Please don't. I would personally hate this bureaucratic solution enough to remove the group from myself. There is zero reason why these 2FA checks can't happen pre-edit.

Slippery slope that would be too annoying to deal with if not implemented properly. At most something like this can require 2FA once a day, otherwise, most users will just curse whoever came up with this change. In an ideal scenario, this should probably be even simpler than 2FA (something like bawolff's suggestion to have to confirm the action on a separate website). Editing other users' JS should require the same as editing site-wide JS, though.

In T419154#11679097, @sbassett wrote:

To help protect against things like this while we work to better secure user and interface JavaScript on the projects. A public meta-wiki announcement is in this works.

Things like loading hundreds of random unused scripts from a privileged account? I think doing some restrictions as a result of this is valuable but scripts should not be disabled for days because of a personal misjudgment.

In T419143#11678515, @Bugreporter wrote:

If a steward is compromised they can theorically put malicious JS to common.js in every Wikimedia wikis (which will cause much larger mess than the current one). So I do not believe doing so is good.

I’ve wrote my comment based on available code, not theoretically. It doesn’t do that sort of thing. And unless another person loads some other bullshit script, it won’t.

In T419143#11678498, @Ahecht wrote:

Given the gaping security hole this revealed, I wouldn't be surprised if user scripts are disabled until more safety rails are in place (such as preventing them from non-interactive editing of common.js).

I think the known nature of the incident shows that this is not necessarily required to be done ASAP. Never mind that the WMF was not focusing on obvious solutions (such as requiring a 2FA confirmation step for editing site-wide JS) for years already.

It would be good if the user script disabling would be limited to Meta, since this issue didn’t affect other wikis. People seem to be angry enough about this, no reason to make them angrier, as many workflows depend on user scripts in most wikis.

Not sure if WMF configuration allows it but TemplateStyles is also supposed to allow web font usage under specific safeguards:
https://www.mediawiki.org/wiki/Extension:TemplateStyles#Caveats

T411834 seems to be describing some pretty outlandish concepts with an unclear roadmap to ever being completed. The reality on the ground right now is that shared Lua modules get unsynchonised fairly quickly because either of conflicting changes, not having a shared repository and not propagating changes between them. There are some tools to help with that but I see no issue with @PerfektesChaos’s opinion that this new magic word should validate ISBNs in some way (I don’t have a problem with it being an extension) if it exists. The problem with a shared Lua module approach is that eventually you’ll run into the same problem as T343131: Commons database is growing way too fast, in the case of a module, both for the module itself and for the wrapping template (since most wikis are not bad enough to include modules without a template). ISBNs are highly used on multiple wikis so that’s a real possibility.

Either way, the notion that this styling should only be present depending on whether a page has a signature on it or not is simply misguided. Either that should be the default style everywhere or nowhere. The weird inconsistencies only highlight this. (Personally I also don’t think that what DiscussionTools is doing with <h2>-level headings, making them Arial and bolded even though we moved away from that style in 2014, is motivated by anything reasonable either.)

I don’t have a strong opinion on the change in general, but I think both hiding the comment and requiring the user to hover over it to actually see it once it’s not hidden is a weird overkill that I don’t see any motivation for. If there is a (fairly prominent) UI part that shows the comment, then it should show the comment, not show the blurred version of it.

That was already always possible both via CSS (body.ns-special .mw-userlink) or via JS:

• mw.config.get( 'wgNamespaceNumber' ) === -1
• mw.config.get( 'wgCanonicalSpecialPageName' ) !== false
• mw.config.get( 'wgCanonicalNamespace' ) === 'Special'

I think it is quite unfortunate that this ended up limited just to temp account links. Complicated heuristics to tell where user links are on the discussion pages etc. are a constant in a number of MediaWiki user scripts like Gadget-markadmins.js or Gadget-markblocked.js, so it would’ve been very nice to have this class-based indication instead of having to rely on parsing all links and sifting through titles in tooltips. A much better solution would’ve been fixing the scripts that are misbehaving (or, maybe, introducing these classes in a different convention?) rather than removing a perfect solution to a long-standing problem with user links on content pages.

FWIW to Go/пщ problem: there are current examples of this right now, for example php/зрз returns first one potentially relevant result in Cyrillic and then a bunch of results related to PHP. I think this is actually how this redirect thing should/would function too in that case, so returning a full match title somewhere in the list of suggestions (maybe even always as a last one out of potential ones if it’s too generic, but always the first one out of the ones added by the algorithm) doesn’t seem all that problematic.

Is there any plan to make it so that search pages like https://ru.wikipedia.org/wiki/Special:Search/,fhfr_j,fvf («Барак Обама», Barack Obama) display relevant results as well?

Sorry for misinforming in earlier comment. It is not exactly related because the unstrip post-expand size (UPES) increase happens in the size of the original stylesheet, not in the size of a <link> tag generated by deduplication. So if someone adds some more CSS to the styles page (let’s say 100 bytes), every instance ends up contributing 100 bytes to UPES, 400 for 4 template calls, 800 for 8 template calls, etc.

Would’ve been good to find a way to do this change without affecting Special:RecentChangesLinked (since usually 1 day isn’t enough on that special page) but it’s a really small nitpick.

In T361934#11274958, @cscott wrote:

It might be possible to address this by allowing a single var as a special case to these rules, while disallowing the general case, which is I think what @zdev is suggesting.

This was suggested by many people over the years, as can be seen in T364685: CSS sanitizer refuses TemplateStyles variable assignment to border-color but does permit background-color. No one just picked up on it, even though it’s the most rationale way to set the border colour.

Yes, thanks. This does seem like a flaw, since any extensive use of one template, no matter how small it is, would eventually break the page once a certain number of elements get present. Although it didn’t yet appear in the WMF wikis, there might be a point where it ends up happening, as more and more templates get converted to TS model.

I think the second security requirement is not really necessary if the variable name would enforce what values it might have and TemplateStyles would only accept CSS variables of a particular type. As you yourself say, it’s not a particularly strong protection anyway, so unless it would be required by TS to validate the variable values, it doesn’t seem useful to have.

IMO it might be better to not mention it at all or mention it a week later: category will not become empty immediately after the patch gets deployed, so for a while admins should not delete it because that would make a category red link appear on all those pages where the page is still cached in that version. Any note on this would be better to have once the category actually becomes empty across wikis, and then it can be said something like ‘Administrators can remove the tracking category previously added by JsonConfig, see Wikidata item.’

While it would be better than nothing, it is not really a ‘compromise approach’ since one of the best uses for CSS variables is to simplify colour assignment. I don’t think there’s anything wrong with the idea, though.

…And for messages like (hidetoc) and (echo-badge-count) in most skins you cannot copy their name at all. (This is now solved by Translator Buddy, as well.)

TS could add any random prefix to all defined variables in its output. But I think the task description was never meant to display the required specification in regards to variable safety (and it’s unclear whether this will be implemented at all, unfortunately).

Only because .mw-logevent-actionlink a, .mw-logevent-tool a, .mw-diff-tool a, .mw-pager-tools a is now assigned a link colour. There are other places where this might still fail the same way.

I think you misunderstood what I wrote. I don’t need toggle buttons for elements I am trying to uncollapse (forms on history page etc., certain collapsed elements on wiki pages). I just want to see them uncollapsed. Before, it took a simple CSS declaration to do so. I get that it is more so a problem of CSS specification you’ve used, but still, the resulting reset styles on these elements are pretty annoying to deal with. Having simply all: initial or something would be an improvement, indeed.

It originated from T189316: Developer review of changes to Hindi Wikipedia Main_page [3 hours] which was done with the involvement of then Web team. Then, considering this was a generalised solution at the time, I used it in the Russian Wikipedia main page design as well, and from there it probably spread to various wikis. (I don’t think it is a far representation to say that this was ‘never officially supported by the Minerva skin’ when it was part of Minerva source code for 6 years and was done with skin-specific prefix.)