I'm just curious, why wasn't the standart Wikicode editor Search popup extended with the new functionality instead of creating two working at the same time?

In T110645#10014240, @01tonythomas wrote:

The expected Flow shutdown will kill the Newsletter extension, FMHO, if there will not be done adjustments in the extension code.

This is news for me (was away for a long time). From what I know, we are not directly dependant on Flow. Or, do you see something which I dont, @IKhitron?

Answering to the wikitech letter. As a heavy user of the extension over the years I can add my five cents.

1. I really hope there will be local notifications, so the readers can see their content immediately, without a need to go to Meta.
2. The expected Flow shutdown will kill the Newsletter extension, FMHO, if there will not be done adjustments in the extension code.
3. The Newsletter extension is a great thing, and it should continue and evolve.

Yes, good idea. One possible impact is that looks like it kills the Newsletter extension, except there will be found an alternative way to keep it.

In T368034#9909566, thiemowmde wrote:

By the way, the gadget has apparently no support for keyboard navigation, one of our most basic Accessibility requirements.

Well, @thiemowmde, it took us always a month, but I've implemented it by your request. So much time because I've made it at least ten times more functional than the bare minimum, and every key was needed to be coded and approved in the metro project. Hope you like it, on both maps. Thanks again for paying my attention to this issue.

Maybe there is a way to add to the algorithm a paragraph "if you show subsubpage in the line X, but its master page exists and wasn't shown above, then show the master page in the line X+1?"

Done.

I think the task should be reopened, there were a couple of cases in the last few days.

In T368034#9916126, @TheDJ wrote:

@IKhitron This would have started affecting sites in the week of june 11th.

In T352320#9777680, @gerritbot wrote:

Change #1028849 had a related patch set uploaded (by Jack who built the house; author: Jack who built the house):

[jsdoc/wmf-theme@master] js: Fix redirecting for links to methods and properties

https://gerrit.wikimedia.org/r/1028849

Could anyone, please, tell me, for inwiki purposes, when exactly the noresize code was changed in the New Vector, so I could tell the community when the problem started. Thank you in advance.

In T368034#9911279, @TheDJ wrote:

It's a multilevel problem. I discocered that the metromap module in turn uses https://ru.wikipedia.org/w/index.php?title=Шаблон:Одноразмерная_карта_изображений

It uses a width for the outside, and then uses that same with for the image size, even thought hat is supposed to be 10pixels smaller.

This is where the root problem is (the patch is just a tidy up on the MediaWiki side).
Fix: https://ru.wikipedia.org/w/index.php?title=Шаблон:Одноразмерная_карта_изображений&diff=prev&oldid=138474305

Thank you all for this. I'm not so sure I'm smart enough to understand all this but I'll try my best at least to evaulate it as described. I'm glad you agree it's not the gadget problem.

In T368034#9909566, @thiemowmde wrote:

I don't think it can be an issue with the SVG rendering because it would be equally broken in all skins then.

I tried to dig into the gadget, but it's surprisingly complex. As far as I can tell what it does is:

1. A normal 270px thumbnail of https://commons.wikimedia.org/wiki/File:Moscow_metro_map_sb.svg.
2. It looks like there is a <map> with a series of <area> shapes. But that is completely invisible and only used to make the areas interactive when hovering them with the mouse.
3. There is a transparent <canvas> on top that's probably used to display the colored lines. But I couldn't figure out where they come from.

One thing I noticed is that it's not an issue with the position, but with the size.

• In the upper left corner everything is almost correctly placed, but more and more wrong in the lower right corner.
• I believe this issue is also reflected in the code. There are a lot of "262" in the resulting HTML that should probably be 270.

I don't know where this code is that calculates these width and height values.

I don't think you should check the gadget at all, just the area tags in the safemode. But if you insist, there is a completely separate sandbox with completely separate sandbox javascript code, and you can edit them all, if you wish. The area coordinates are here.

By the way, the gadget has apparently no support for keyboard navigation, one of our most basic Accessibility requirements.

Great idea, thanks, we'll consider it.

The gadget author suggests it could be T265549.

In T368034#9909206, @doctaxon wrote:

Can you remember when the hovering behavior was okay last time?

Maybe if I could know, what changed in the New Vector in svg rendering on in area tag, I could understand what to look.

In T368034#9909370, @thiemowmde wrote:

What probably happened is that some of the code (CSS?) in the gadget is a little fragile and starts to behave odd depending on the skin. It's entirely possible that such issues are invisible for a very long time and only become visible much later together with seemingly unrelated changes in MediaWiki, skins, or extensions.

This is possible, of course. But I have no idea how to find what part could volitale, when the gadget do not distinct between skins.

In T368034#9909370, @thiemowmde wrote:

Sorry, my comment was not very helpful. What probably happened is that some of the code (CSS?) in the gadget is a little fragile and starts to behave odd depending on the skin. It's entirely possible that such issues are invisible for a very long time and only become visible much later together with seemingly unrelated changes in MediaWiki, skins, or extensions. Still I suspect the issue is probably in the gadget and needs to be fixed in the gadget.

We have https://www.mediawiki.org/wiki/Stable_interface_policy/Frontend that aims to cover situations like this. I can't tell if it applies here.

In T368034#9909340, @Aklapper wrote:

In T368034#9909314, @IKhitron wrote:

Of course you can't, because without the highlighting script you can't see any area at all, and do not know if it's broken or not.

The initial task description does/did not mention a local script. Thus I pointed out how you can check if a local script is involved before filing a task: Trying safemode, as mentioned on https://www.mediawiki.org/wiki/How_to_report_a_bug . Better bug descriptions often help to fix issues faster.

And I think that "Local-Wiki-Template-And-Gadget-Issues" has nothing to do with the fask, because there is no problem in the gadget, it just helps to see the New Vector problem.

Sounds like that local gadget code needs to be adjusted to work with all skins.

In T368034#9909337, @doctaxon wrote:

Can you shift the hovering overlay to (40,0) pixels by a change of this community .js file?

In T368034#9909260, @Aklapper wrote:

Removing SVG (see its dsescription).

Cannot reproduce on https://ru.wikipedia.org/wiki/Шаблон:Интерактивная_схема_Московского_метрополитена?useskin=vector-2022&safemode=1 so this is custom local code that needs to get fixed.
See https://www.mediawiki.org/wiki/Help:Locating_broken_scripts for how to use safemode.

For future reference, please use the bug report form (linked from the top of the task creation page) to create a bug report, and fill in all the sections in the template, instead of deleting them. Thanks.

In T368034#9909214, @thiemowmde wrote:

I might be wrong, but as far as I can see this has nothing to do with MediaWiki, but is a community gadget: https://ru.wikipedia.org/wiki/MediaWiki:Gadget-ondemand-imagemapHighlight.js. The skin has no knowledge about this.

In T368034#9909206, @doctaxon wrote:

Can you remember when the hovering behavior was okay last time?

New Vector:

Well, for the last 21 hours no querry could run. So it's pretty bad.

I didn't see any complains this time on hewiki forums.

-1. But I think it's fine to have a non default preference for this. So anyone who does want to get these mails could turn this on.

In T366461#9857814, @DannyS712 wrote:

@IKhitron if adding

#ext-globalwatchlist-toolbar {
	background: var(--background-color-base)
}

is really all that is needed, maybe you want to try sending a patch yourself and I can review it?

I hope it will work soon, because now I can't delete any item, not just some.

Any solution that avoids the situation with script does not run without any explanation is fine.

Yep. Exactly. There are a lot of people that upload files with wrong licenses onto local wikis and Commons. There are special forces which are supposed to stop them, VRT. There will be the same count, or maybe even more, people that will do it inline. Who will recognize and stop them? Or the VRT groups are supposed to do much more work? And to learn how to do this at all?

A silly question. Apologies if it was already mentioned before and I missed it.
Where exactly will be the license? And how exactly it will be checked, and by whom, to avoid copypasting inline some copyrighted svg file, such as a company logo?

Thanks, done.

In T353996#9721338, @Samwilson wrote:

(By the way @IKhitron, the file you attached is restricted; could you change its visibility?)

A pity.

Well, there is a new button "delete" on mediawiki.org. Clicking on it makes the item disappear. Refreshing Special:EditRecovery brings everything back. Houston, we have a problem.

There are much more cases when this needed, see here.

Looks like it indeed.

My attention was drawn to this bug after I saw this, when moving the help icon to its appropriate place:

In this case we definitely should consult to community first, because otherwise, from my experience, nobody will pay attention. A week discussion will put it on the radar.

"Opt-in" means that newcomers to enwiki, for example, do not get it by default, @MusikAnimal?

I request to cancel the change for hewiki, please. The community decided to ask this, in Village pump, with more than enough voices, at least 31 supported from 32 that participated. You can find the voting over here. Thank you.

Well, I tried a couple of times to explain you it has nothing to do with all this, with new pages for example, only with any edit in any article. I can see no way to explain more.

This is something else, of cource. For me, if some user can't be trasted to make their one edits in articles, they for sure can't be trusted to have an Interface admin flag, which was created just because the Foundation didn't think the admins (sic!) were trusted enough to have. You definitely can have different ipinion.

In T356044#9587090, @Xaosflux wrote:

In most WMF projects "autopatrol" is only in sysop, bot. I can't see why we would want to prevent a community from assigning someone this group if they want to without also making them one of those other groups. Additionally, the assertion that "everyone has" autopatrol is false. For example, see ruwiki. Not only do they have non-admin/non-bot intadmins, but they also do not have anygroup with autopatrol. dewiki is deprecating patrol as well (see T316393).

This is not a software security concern, and is not a globally supported default setting. Task should be declined.

Don't know what are the relevant tags.

Seems obvious, but OK.

In T170001#9574231, @MusikAnimal wrote:

If anyone wants to test this, CodeMirror 6 is installed on https://en-rtl.wikipedia.beta.wmflabs.org and https://he.wikipedia.beta.wmflabs.org. We have not done any additional work yet for RTL support other than what comes stock with CodeMirror, but two things I'd like to look into are:

• Add bidi isolation to tags such as <div class="foobar">
• Use LTR inside the content of applicable tags like <div dir="ltr">. We probably can't do the same if the direction is changed with a template, unfortunately.

Are there other things I should be looking at? Most of the things mentioned at T170001#3676449 by @IKhitron should be fixed now.

Any help with testing is appreciated :) Thank you!

In T355639#9574561, @Iniquity wrote:

In T355639#9574560, @IKhitron wrote:

In T355639#9561700, @IKhitron wrote:

One more question, please. If we "write it as a task on the Phabricator", as mentioned above, what are our chances to leave it on our wiki as is? You said nothing about this.

While we're waiting for the answer, one more question, please. When you say in the Tech News that "Your community can ask to retain the old configuration on your wiki before this change happens.", what do you expect? A local concensus? A request from random user? A request from somebody that actualy used this? Thank you.

For both questions, a link to the discussion on the wiki with a request to keep everything as it is + minimal consensus is enough.

In T355639#9561700, @IKhitron wrote:

One more question, please. If we "write it as a task on the Phabricator", as mentioned above, what are our chances to leave it on our wiki as is? You said nothing about this.

Really hope this is the case. The current text looks like "write us, we make statistics, and abandon the current task, if there are a lot".

One more question, please. If we "write it as a task on the Phabricator", as mentioned above, what are our chances to leave it on our wiki as is? You said nothing about this.

Hi there. A couple of questions.
If patroller X has a patrolling script that adds tags to some existing edit, will it work?
If AbuseFilter triggered by autoconfirmed adds tags to theirs edit, will it work?

In T356984#9544519, @IKhitron wrote:

Well, I've just tried four most significant scenarios, and it works fine.

Wow, I created a task, a d didn't even remember the previous one that I created in 2017 wasn't fixed, thought it's a new bug.

Well, I've just tried four most significant scenarios, and it works fine.

I've asked to retrieve my bot flag, which I temporarily gave away a while ago due to lack of time. I know pretty well what is going on now on Watchlist in different modes, because I wrote a huge gadget, Whatchlist Manager, years ago. So, I'm planning to create various use cases to check what is the state after the deployment. Starting from this one:

1. Open some watched page at 23:59.
2. Close it.
3. Go away for an hour.
4. During this period, another accounts edit this page: three non-bot edits, a bot edit, three more non bot edits.
5. Return to the screen and open the Watchlist in group mode, showing new edits only.

I expect to see a new group with seven edits. As far as I understand from todays Tech News, I will see none. Those before because of the new change, since marking an edit as seen marks automatically all the previous ones. Those after because of the mentioned old bug in the new conditions. The best result will be if I see all the seven.

In T356044#9495871, @JJMC89 wrote:

Also, a core user group cannot depend on something defined in an extension.

Very well. Changing to "Avoid the possibility to give the interface-admin rights to users without autopatrolled or autoreviewed rights" will by OK for you? So that user must have at least one of these two.

Because as far as I understand, not being a regular on enwiki, just from reading that page, autoreview and autopatrol are synonims. If they are not, I can always change the task title to be "Avoid the possibility to give the interface-admin rights to users without autopatrolled or autoreviewed rights", to fit both cases.

What do you mean by "autopatrol"? (in enwiki, to be more clear)

You mean, each sysop's edit is patrolled by a human patroller? The page https://en.wikipedia.org/wiki/Special:ListGroupRights claims otherwise, see "Have one's own revisions automatically marked as "accepted"" in sysop chapter.

I'm not talking about autopatrol group, but about autopatrol rights. The user's edits should not be manually patrolled. Sysops have this included for there group too.

I suggest to restrict someone without autopatrol rights to get interface admin, because that means the local community does not trust them. Autoconfirmed is just automatic rights, not related to my suggestion.

I see now. You changed my words too, not just title. Itbrakes also the facts and my thoughts. I don't know why did you do this, but if you think the opposite of my suggestion, you can always create another task. I return my request back.

@JJMC89, I do not understand your edit. It has no sence now.

In T356044#9495296, @sbassett wrote:

I think this needs to be a Community decision and should require more (public) discussion, so we should probably make this task public (there's nothing super-sensitive here IMO). Implementing this as an additional technical control should be fairly trivial, but there should already be a Community workflow control in place, if that is deemed appropriate.

I would suggest somethink like

Pages that use the JSON contentmodel will now use tabs instead of spaces for autoindentation. This will significantly reduce the page size.

The first sentence because otherwise it will look like "name":"John Doe" -> "name":"John\tDoe" conversion, or even asking the users to insert tabs manually. The second one explains the large impact more straightforward.

Well, enough time later I can say that the problem disappeared a second after the consequent deployment. Unless somebody else continues experiencing it, I would suggest to close the task.

In T352548#9398486, @Tgr wrote:

Doesn't Samsung Internet enable browser extensions?

You do remember it's an Android problem?

In T115809#9396532, @thiemowmde wrote:

I can't reproduce this any more. It's possible this was fixed as part of the big refactoring of the Cite codebase we did in 2019.

Even didn't see the misaligned part.