Page MenuHomePhabricator

[MEX] 🐛️ horizontal-scrolling for items with globe coordinates in RTL languages
Open, Needs TriagePublic

Description

As a logged-in user with the MEX beta feature enabled, view an item that has at least one globe-coordinates statement, in a RTL language.
For example: https://www.wikidata.org/wiki/Q42?uselang=ar&useformat=mobile

note: initially, I could only reproduce this in debug mode, but it is now happening consistently for me in normal (non-debug) mode. I'm unsure whether debug is part of this, or if there's some other random variable I didn't control for initally. Upon having trouble reproducing this bug, append debug=2 to the end of the url.

When the page fully loads, scroll to the left. The scrollable area is about 10 times the width of the viewport. It's easy to scroll into a completely blank screen and get lost there.

By a process of deleting elements from the DOM to observe their effect on scrollability, I narrowed it down to one specific element, belonging to the Kartographer extension. It can be found with this css selector:
.mw-parser-output>div.leaflet-control-container>div.leaflet-top.leaflet-left>div.leaflet-control-zoom

Event Timeline

AudreyPenven_WMDE renamed this task from [MEX] 🐛️ horizontal-scrolling with RTL in debug-mode to [MEX] 🐛️ horizontal-scrolling for items with globe coordinates in RTL languages.Jun 15 2026, 2:24 PM
AudreyPenven_WMDE updated the task description. (Show Details)

This seems to be yet another symptom of Kartographer producing invalid html, as I previously reported in T401606: Kartographer's frontend map initialization creates invalid html. That ticket currently has a patch for review.

When testing locally with that patch, this bug no longer occurs.

Change #1293140 had a related patch set uploaded (by HakanIST; author: HakanIST):

[mediawiki/extensions/Kartographer@master] mapframe: Use <div> container instead of <a> to fix nested anchors

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

As of today, this issue on production:

  • does not display on iphoneSE iOS 26.6.1
  • does display iphone12mini iOS 26, android

Change #1339623 had a related patch set uploaded (by Mahmoud-abdelsattar; author: Mahmoud-abdelsattar):

[mediawiki/extensions/Kartographer@master] mapframe: Let a caller keep the map interactive on small screens

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

Change #1339624 had a related patch set uploaded (by Mahmoud-abdelsattar; author: Mahmoud-abdelsattar):

[mediawiki/extensions/Wikibase@master] wbui2025: Fix horizontal scrolling issue triggered by map preview

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

I narrowed the issue down to the CSS rule .leaflet-control-zoom-in, .leaflet-control-zoom-out { text-indent: -999em; }. This is part of the Leaflet library, which is part of the Kartographer extension. The negative indent is an old CSS trick to move elements out of the viewport but have them still accessible by screenreaders and such.

When I add .rtl .leaflet-control-zoom-in, .rtl .leaflet-control-zoom-out { direction: rtl; } the negative indent goes to the other side and the issue with the scrollbar disappears. That should be semantically correct as the two links in question don't show anything but a + and a - sign.

It would also be possible to hide the elements completely via .rtl .leaflet-control-zoom-in, .rtl .leaflet-control-zoom-out { display: none; } since they aren't visible anyway. But this probably breaks intended use cases for screenreaders or other keyboard users.

Update: While these would all work the actual problem was that the negative indent hack needs to be combined with overflow, but Leaflet forgot that.

Change #1342249 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):

[mediawiki/extensions/Kartographer@master] Fix CSS hack in Leaflet causing scrollbars in RTL languages

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

Change #1342270 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):

[mediawiki/extensions/Wikibase@master] Don't initialize Kartographer mapframes twice

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

Change #1342272 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):

[mediawiki/extensions/Wikibase@master] Fix type issue in OtherProjectsSitesGenerator found by Phan

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

Change #1342272 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Fix type issue caused by nullable Site return type

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

Change #1342597 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):

[mediawiki/extensions/Kartographer@master] Don't initialize Kartographer mapframes twice

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

Change #1342270 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Don't initialize Kartographer mapframes twice

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

Change #1343467 had a related patch set uploaded (by Arthur taylor; author: Arthur taylor):

[mediawiki/extensions/Wikibase@master] Revert "Don't initialize Kartographer mapframes twice"

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

Change #1343467 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Revert "Don't initialize Kartographer mapframes twice"

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

Change #1342249 merged by jenkins-bot:

[mediawiki/extensions/Kartographer@master] Fix CSS hack in Leaflet causing scrollbars in RTL languages

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

it is not scrolling for me anymore, but it looks like this:

Screenshot 2026-09-28 at 11.40.56.png (836×828 px, 118 KB)

@Alice.moutinho there are a few things going on, as far as I can see.

  • The fact that the map is not interactive is expected. See T438714.
  • Why is the map so narrow? I currently cannot reproduce this. Can you share which page you are using as an example? I guess this is because the map is not in a statement's value but in a qualifier. That's probably worth a new ticket then.

@thiemowmde i used the link from the description, this one.

i checked location as a qualifier on LTR which is also not ideal but makes sense - it takes the space it is given (we could make it nicer but it doesn't look broken).
It looks like this:

Screenshot 2026-09-29 at 15.14.13.png (904×656 px, 166 KB)

@Arian_Bozorg should we make a ticket to make RTL coordinates as a qualifier less bad (looking like LTR but in the other direction)?

Given the issues that these maps have whenever we touch them, and the time pressure to get this live, i am tempted to say we can live with it, since it is not so often that coordinates are used as a qualifier. But the final word is yours!