New Vector:

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

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.

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#9909206, @doctaxon wrote:

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

Unfortunately, I can't, sorry.

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.

It wasn't changed from March, and I'm for sure saw the right areas later. And it definitely does not distinct skins. So it's just something from Mediawiki, that it uses.

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.

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.

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.

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

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?

Sorry, I don't understand, could you be more specific, please?

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.

Once again, local script takes Mediawiki area tag and colors it, so we can see it. So the problem is not in local script, and I should not adjust the local script, it worked fine in the New Vector many months, until something was broken, and the script wasn't edited.

So please remove the "Local-Wiki-Template-And-Gadget-Issues", it confuses people to think that the problem is in some Gadget.

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.

@thiemowmde: Kriegst Du das hin, den Code so zu fixen, indem man das hovering overlay einfach um position 40,0 pixel verschiebt?

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.

I don't believe the problem is in the gadget. But let's check it. Is there a way to recognize the exact position of the area tag in safemode?

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.

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#9909206, @doctaxon wrote:

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

There was no problem for sure at June 5, 2024, 18:57 UTC.

The gadget author suggests it could be T265549.

When we change local css we should take care that the problem is only Vector 2022 and not Vector Legacy, so I guess the really better next step is calling @hnowlan as expert.

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.

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

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.

When comparing
https://ru.wikipedia.org/wiki/Template:Интерактивная_схема_Московского_метрополитена?useskin=vector&safemode=1 and
https://ru.wikipedia.org/wiki/Template:Интерактивная_схема_Московского_метрополитена?useskin=vector-2022&safemode=1
we can see that the image renders in two different sizes. It should be 270px but is 262px in the new skin.

The same happens with the basic imagemap template. When we compare
https://ru.wikipedia.org/wiki/Template:Одноразмерная_карта_изображений?useskin=vector and
https://ru.wikipedia.org/wiki/Template:Одноразмерная_карта_изображений?useskin=vector-2022
we can see that the (in this case yellow) hover regions in the example image are slightly misplaced in the new skin. I suggest to fix that first and then see if the issue with the subway map disappears.

We have responsive images since last week (like on mobile). That is likely related.

Even though there is a noresize class used by this template, the noresize class is currently on the figure and not on some element that is wrapping the figure. I'm not sure that works in mobile, but it doesn't in the vector responsive rules at least (I see now that the whole widget is hidden on mobile, so that explains why it wasn't noticed before). So lifting the noresize class one level higher in the DOM will help here.

But we also assume that the content by default will FIT. However, the generated HTML for the image here is max 262px wide (internal, which is 270px on the EXTERNAL dimensions of the infobox) wide, and then has a 270px wide image inside it. This means that people were relying on the wrapping table to grow beyond its 'allowed' size to a size that fits the image. This TOO should be fixed.

mobile:

.content .noresize {
    max-width: 100%;
    overflow-x:auto
}

.content .noresize a > img {
    max-width: none !important
}

vector:

.noresize figure img.mw-file-element {
	max-width: none;
}

This is because <figure> was the only way to distinguish block and inline images. Possibly we can improve the line by making it:

.noresize figure img.mw-file-element,
figure.noresize img.mw-file-element {
	max-width: none;
}

Just to agree, this isn't a problem with the gadget. In safe-mode you can (painfully) see that the <area> tags we're outputting aren't aligned with the correct areas on the map, by carefully hovering over the image and seeing where the clickable areas are. Compared to the safemode version in classic vector, you can see they're misaligned with the shapes in the image (I found the centermost brown circle to be pretty usable for checking this).

This is because map/area are entirely specified with dimensions in absolute pixels, and completely fall apart if the original image is scaled in some way after the fact.

Since this is inherent to image maps, maybe we could adjust the code to remove that max-width:100% so it doesn't apply it to img[usemap]? It's going to be breaking something anywhere that attribute is present, after all, and it'd be easier if users didn't need to know to add noresize.

In T368034#9910045, @DLynch wrote:

Since this is inherent to image maps, maybe we could adjust the code to remove that max-width:100% so it doesn't apply it to img[usemap]? It's going to be breaking something anywhere that attribute is present, after all, and it'd be easier if users didn't need to know to add noresize.

Some further digging reveals that it is the imagemap extension that is adding noresize onto the figure element.

Well, if it's automated that's not so bad. It still seems sensible to acknowledge usemap in the skin CSS for responsive images in case other extensions / gadgets output imagemaps in the content in the future, but it's no longer directly related to fixing this issue.

In safe-mode you can (painfully) see that the <area> tags we're outputting aren't aligned […]

You can use the tab key and let the browser highlight the areas.

Change #1048053 had a related patch set uploaded (by TheDJ; author: TheDJ):

[mediawiki/core@master] Ensure noresize also works when placed on figure

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

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.

It's a multilevel problem. I discovered 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

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

Thanks a lot, it works perfect now. I hope one day I'll have got enough knowledge to understand what happened, and why in Vector 2022 only.

For now, I can say I do not like this structure either, and in the last ten days I'm working on a new one, using flex-wrap to be able to responce to window size and device orientation changes. It's in a different draft file, and it has those -10 pixels from the beginning. And I'll definitely check all the things I was told above when it will be ready.

Change #1048053 merged by jenkins-bot:

[mediawiki/core@master] Ensure noresize also works when placed on figure

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

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.

This issue also applies to Monobook and Timeless.

In T368034#9916126, @TheDJ wrote:

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

Thanks a lot. Last thing left, I really hope somebody could be able to answer on the date question.

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.

That's great to hear. Thanks a lot for the extra effort!