I tested the example under https://en.wikipedia.org/wiki/User:Kallichore/sandbox2?useskin=minerva on en.Wikipedia with MW 1.46.0-wmf.4:

• no loss of focus under Firefox 140.5.0esr on my desktop computer (issue resolved)
• loss of focus on my Android phone (I tested Samsung Internet, Chrome and Firefox) (issue not resolved on mobile)

So this was actually a documentation problem. The ability for anonymous users to disable multimedia viewer was proposed and declined in https://phabricator.wikimedia.org/T378400

Using the preferences only works for logged-in users. The problem for logged-out users was already mentioned on Oct 27 2024 in https://phabricator.wikimedia.org/T77349

There are further reports in de.Wikipedia here:
https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#Im_Visual_Editor_kann_man_oft_nicht_mehr_an_den_Artikelanfang_scrollen

I have noticed changes to MediaWiki:Gadget-Stockphoto.js (https://commons.wikimedia.org/wiki/MediaWiki:Gadget-Stockphoto.js) in June 2025 that reactivate the "vertical mode" under certain conditions. @Krinkle Can you explain what you did? Is there a solution when "users resize their browser window"?

The problem has been reported again in de.Wikipedia:
https://de.wikipedia.org/wiki/Wikipedia:Fragen_zur_Wikipedia#Sehe_nur_ich_das_%C3%BCberlagert?

Kienny reported an interesting observation under https://de.wikipedia.org/wiki/Hilfe_Diskussion:Chart#Beschriftung_links_am_Rand:

I observed that it is insufficient to just look at the page on commons. The embedded version should be tested too, like under https://de.wikipedia.org/wiki/Benutzer:Kallichore/Test2

I had a look at the change on ImageMap in MediaWiki 1.45/wmf.1:
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ImageMap/+/1142604 (belongs to https://phabricator.wikimedia.org/T341775)
I noticed that this change replaces <tag/> by <tag /> (extra space before closing slash) for <img> and <area> at some points in the rendered html. I found this out by comparing the html source of the article with the version in the internet archive.

I've been testing this issue with a local vector-2022.css:

html.vector-sticky-header-enabled,
html {
  scroll-padding-top: 50px !important; /* Try a smaller value instead of the default ~75px or more */
}

I learned that 50px works well for me, but there is a browser zoom dependence. For large browser zoom factor the zone created by scroll-padding-top appears to be "overzoomed". I don't understand all details, but it appears to me that a solution with a static value cannot work.

Yes, I think this is the same problem.

I believe we should address the "dragging the mouse up" and "dragging the mouse down" case separately:

I now observed a connection of the problem to the zoom function. In mobile Firefox using a font size of 125% or larger in the accessibility settings makes it possible to scroll the table horizontally. I observed the same with the zoom functions of mobile Chrome or Samsung Internet. (For clarity: I mean cases where horizontal scrolling is not possible with the standard zoom setting of 100% in landscape mode.)

Using the Network tab of Firefox I saw a delay for images with status 304. In the following example there is a 292 ms delay for an image on the de.wiki starting page. It can be seen that this time is used for waiting:

Here is a screenshot of the problem (3 delayed images + black square problem; 1 image without the problem):

I want to point out that this problem has significant impact on Wikipedia versions with many pending changes like de.Wikipedia (>18,000) and pl.Wikipedia (>11,000). It is still possible to review pages by using the history, but not all users know that.

I have described this problem with "mouse out detection" in https://phabricator.wikimedia.org/T374214 in the past. I still support a change from onhover to onclick, which has no need for such a detection.

For clarity: Here is an image of the problem I see for this example https://de.wikipedia.org/wiki/Wikipedia:Hauptseite#/media/Datei:Hussitenf%C3%BChrer_Jan_Zizka.jpg:

I noticed right after the backport that copy and paste within tables works again in de.Wikipedia.

I still observe the problem (tested on Firefox, Chrome and Edge). There is a random component, so pages should be reloaded several times for testing. In an incognito window the problem is typically not there for the first loading of the page, but after reloading the page the problem appears.

I am not an expert here, but the "mouse out detection" implemented in the "isMouseOutBubble" function in
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/FlaggedRevs/+/1072591/2/modules/ext.flaggedRevs.advanced/advanced.js#36
seems to miss several scenarios. For example, when the curser is moved to the area with "View history, [Star Symbol], Tools" under the Vector2022 skin, the popup does not close as expected. This explains the problem I described earlier.

Is the new version really the "Status quo ante"? If I move the curser upwards to "Tools" the popup appears, it disappears if I move the curser down over the popup. However, if the curser's path does not cross the popup, it remains open, even if I click elsewhere on the page.

I noticed that because of https://phabricator.wikimedia.org/T369659 changes were made to mmv.ui.canvasButtons.js two month ago:
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/MultimediaViewer/+/1053722/5/resources/mmv/ui/mmv.ui.canvasButtons.js
@Ebrahim: Do you think that there could be a connection to the problem with "strange white squares" in this thread?

I experienced this problem too (e.g. with https://en.wikipedia.org/wiki/Estrel_Tower#/media/File:Au%C3%9Fenansicht_Fassade_des_Estrel_Towers_Berlin.jpg, but the problem is also there for other pictures). There is a random element for the light mode (I never saw the problem in the dark mode): sometimes the correct icons are there (e.g. a gear symbol for "Enable or disable Media Viewer", sometimes they disappeay after a tiny moment so that white squares are displayed, sometimes there are white squares from the start.

The bug was about a bluelink for non-existing talk pages, so https://www.mediawiki.org/wiki/BlueSpice is not a correct example, because the talk page exists.

The problem is present in MediaWiki 1.43/wmf.11 as well. I noticed the problem in de.Wikipedia, where it present for vector-2022, but not for vector-2010 or timeless:
https://de.wikipedia.org/wiki/Wladyslaw_Buchow?useskin=vector-2022
https://de.wikipedia.org/wiki/Wladyslaw_Buchow?useskin=vector
https://de.wikipedia.org/wiki/Wladyslaw_Buchow?useskin=timesless

Thanks, I had a look at the changes and I like the solution for pages needing review. To my knowledge it works well in de.Wikipedia now.

@Jdlrobson : I am not an expert here . But many pages are affected by this. The search function gives over 30k results for "float-right" in de.Wikipedia:
https://de.wikipedia.org/w/index.php?search=insource%3A%2Ffloat%5C-right%2F&title=Spezial:Suche&profile=advanced&fulltext=1&ns0=1&ns10=1

Today a problem with infoboxes appeared in de.Wikipedia under Vector2022. Example: https://de.wikipedia.org/wiki/Japan?useskin=vector-2022

This would still require scrolling below the full list of included templates, which can be quite long like in this case with 57 included templates:
https://de.wikipedia.org/w/index.php?title=Bundesministerium_f%C3%BCr_Gesundheit_(Deutschland)&action=info#mw-pageinfo-header-properties

I noticed the change in de.Wikipedia now. I understand that it was necessary to make a change. However, I wonder if there is a solution where the list of transcluded pages can be found more intuitively. In de.Wikipedia you have to scroll to the bottom of page information ("Seiteninformationen") to find the list under "Transkludierte Seiten warten auf Überprüfung". How are users supposed to know this?

I think the problem is not present anymore. I checked this in test.wikipedia (example above: "Anchor Link Test"), en.wikipedia ("Facial expression recognition") and de.wikipedia ("Schneller Reaktor"). I don't know what fixed the problem.

I want to point out that the problem is still present in many Wikimedia projects, there are currently 105 pages found in de.Wikipedia:
https://de.wikipedia.org/w/index.php?search=%22Math+extension+cannot+connect+to+Restbase.%22&title=Spezial%3ASuche&ns0=1

I think I found out that this problem started before August 2023: The html source of articles contains a timestamp from the parser. For the article https://pt.wikipedia.org/wiki/Esquema_de_Horner with the problem the timestamp is:
<!-- Saved in parser cache with key ptwiki:pcache:idhash:3991620-0!canonical and timestamp 20230727175816 and revision id 63128952. Rendering was triggered because: page-view
-->
I suppose timestamp 20230727175816 means July 27 for the day.

Thanks for the quick answer. So the version that "went live" in the last days in all wikipedias is 1.41.0-wmf.20. And this version contains no changes in the Math extension.

The problem is still there, here are some numbers for different projects obtained with the search function: en (61), es (54) and fr (50).