Fix Explore>Map description showing raw HTML tags

[Salehcodes]

Description (required)

Fixes #6594

The description text shown in the Explore>map bottom sheet previously displayed raw HTML tags such as <br> and <b>, instead of rendering formatting. This reduced readability and made the UI appear visually broken.

This PR updates the description binding in ExploreMapFragment.passInfoToSheet() to use:

HtmlCompat.fromHtml(descriptionText, HtmlCompat.FROM_HTML_MODE_LEGACY)

This allows HTML to be rendered as styled text (e.g., bold and line breaks), matching the formatting already used in the Details screen.

Tests performed (required)

Tested on:

Build variant: betaDebug

Device: Samsung Galaxy S23

Android version: Android 16 (API level 35)

Steps:

Opened Explore → Map

Selected a nearby marker and tapped the bottom info banner

Verified that HTML is properly rendered:

<b> → bold text

<br> → correct line break

No visible raw HTML tags

Uploaded a test image to Beta Commons to ensure environment functionality

Test upload URL:
https://commons.wikimedia.beta.wmflabs.org/wiki/File%3ATest_html_tags.jpg

Screenshots (for UI changes only)

[RitikaPahwa4444]

Thanks @Salehcodes for your contribution. I'm not sure if users really pass HTML tags in these fields. There are some existing issues with more context around this. Could you please check those and see if this PR handles those use cases?

[Salehcodes]

Thanks a lot for your feedback :)
My assumption was based on the fact that the HTML tags are already being rendered correctly in the Details screen from the same bottom sheet. So I applied similar handling here to make the behavior consistent.
If there are cases where descriptions are not expected to contain HTML, I’d be happy to review and ensure we also cover those scenarios.
Since I’m still new to the project, could you please share the related issue numbers you mentioned so I can read through the context and confirm whether this PR fully addresses them?
Thanks again for guiding me.

[RitikaPahwa4444]

One that was fixed recently for the author field: #5030.

It's not a natural for a user to use tags, but since you're saying our codebase is inconsistent, I'll take a look at those areas and get back to you. Would you recommend having these checks for every edit text field within the codebase?

[Salehcodes]

Thank you, yes i think its very good idea as by checking we make sure nothing like this happens again in any field.

[whym]

In #5030 I worked with rendered HTML with no wiki code. I believe here we are working with wiki syntax, which happens to allow limited HTML, too. EDIT: no, it looks like it's also non-wiki HTML, judging by the fact that two bold text in https://commons.wikimedia.beta.wmcloud.org/wiki/File:Not_Googleplex.jpg both appeard as <b>.

Still, I think different text fields can have different expectations:

• text fields dealing with file page content - wiki code or HTML or plain text, depending on how you retrieve
• text fields dealing with Wikidata caption - plain text (with language specified)

[RitikaPahwa4444]

Thank you @whym for your inputs!

My only point here is that we need to understand if this is happening due to some glitch or we're just dealing with user input. If it's the latter, then we need not solve for it. Users can even decide to use asterisks for bold, underscores for italic, etc. which isn't HTML but a common behaviour on chat applications.

And if not, then your first point about file content retrieval would help.

@Salehcodes could you please confirm the use case once and possibly share a screen cast too for the inconsistencies you were referring to?

[RitikaPahwa4444]

I tested this branch as well as main, it does seem like a glitch at our end only. Sorry, by looking at the screenshots in the PR, I thought that's how we're providing the input.

On this branch, I'm getting this box at the end for every image I check:

[Salehcodes]

Screen_Recording_20260103_124428_Commons.mp4

As you can see here the description before pressing details button included raw html tags eg. <b> but after pressing details the tag was rendered correctly.

Ps. I did not upload this image this is real user image and input which I noticed that a lot of them in my area use html tags idk why.

[whym]

(This may be already obvious, but just to make it clear) I think it's reasonable to expect rendering similar to the website version (around "Description: In Nazareth" for example). In this case the syntax mentioned here seems to be part of MediaWiki's limited HTML that is rendered accordingly on the website.

The file page has the Israeli Pikiwiki project tag saying "This file has been submitted through the Israeli Pikiwiki project and uploaded here automatically". The automatic process might have contained rather rare (but still valid) syntax.

[RitikaPahwa4444]

@Salehcodes did you get a chance to check this: #6595 (comment)?

[Salehcodes]

I will look into this asap> @Salehcodes did you get a chance to check this: #6595 (comment)?

[Salehcodes]

@RitikaPahwa4444 I looked into this and I found out that the square comes from MediaWiki UI <img> elements in the description. When rendered via HtmlCompat.fromHtml(), Android shows a placeholder for images without an ImageGetter. Stripping those UI-only <img> tags removes the square while keeping the actual description text intact.

i added to the code the stripping of element.

screen recording :
before:

before.mp4

after:

after.mp4

[whym]

Can we have unit tests for this (what is to be parsed, ignored, left alone, etc)? One way to make it easier to test might be to refactor the conversion code added/modified here into a method.

This might be useful as a reference:
https://github.com/commons-app/apps-android-commons/pull/6603/files

[Salehcodes]

@whym Thanks for the suggestion I’ve updated the PR accordingly.
I refactored the HTML handling so the MediaWiki-specific UI markup is removed inside StringUtil.fromHtml() (instead of in the Fragment), making the behavior easier to test.

I also added a unit test (StringUtilImgTagTest) that verifies tags do not result in an ImageSpan being created, which prevents the placeholder “square” from appearing while keeping normal text formatting intact.

[github-actions]

✅ Generated APK variants!

• 🤖 Download betaDebugAPK
• 🤖 Download prodDebugAPK

[nicolas-raoul]

Should that HTML be shown as a link?

https://commons.wikimedia.org/wiki/File%3ABodhisattva_Padmapani%2C_art_du_Gandhara_%28Mus%C3%A9e_national_de_Tokyo%2C_Japon%29_%2844781049121%29.jpg

== {{int:filedesc}} ==
{{Information
| Description = <b>Bodhisattva Padmapani jambes croisées</b>
Cette représentation est fréquente dans l'art du Gandhara.
Le bodhisattva (Avalokitesvara) souvent qualifié de Padmapani (celui qui porte le lotus) est vêtu en prince indien avec de nombreux bijoux. Il est assis en délassement sur un siège ouvragé, orné de deux orants à ses pieds, et tient négligemment le lotus dans sa main gauche. Il porte un turban orné mais dont on ne distingue pas la nature exacte. (selon &quot;l'art bouddhique&quot; de Gilles Beguin, CNRS Éditions 2009, p. 213) 

Schiste
2-3ème siècle
Dynastie Kushan
Mardan, Pakistan
Collection privée

Galerie asiatique 
Musée national de Tokyo
<a href="https://colbase.nich.go.jp/collectionItems/view/12f08f3c06a62af80737925634848303/142416" rel="nofollow">colbase.nich.go.jp/collectionItems/view/12f08f3c06a62af80...</a>
| Source      = [https://www.flickr.com/photos/dalbera/44781049121/ Bodhisattva Padmapani, art du Gandhara (Musée national de Tokyo, Japon)]
| Date        = 2018-05-20 05:19
| Author      = [https://www.flickr.com/people/72746018@N00 Jean-Pierre Dalbéra] from Paris, France
| Permission  = 
| other_versions=
}}
{{Location dec|35.717771|139.776585|source:Flickr}}

[whym]

I started looking into what we could do to make the HTML like this more machine friendly at Commons Village Pump/Technical. (I just wanted to share the information. The best case scenario is that we will be able to use the "noprint" class to approximate (most) elements to be hidden, but there is nothing actionable yet and things could be messier than I hope, and I don't have a time frame to solve it on the Commons website side.)

@nicolas-raoul: do you mean this part? <a href="https://colbase.nich.go.jp/collectionItems/view/12f08f3c06a62af80737925634848303/142416" rel="nofollow">colbase.nich.go.jp/collectionItems/view/12f08f3c06a62af80...</a> It appears broken (raw HTML is visible) on the website too.

[nicolas-raoul]

@whym Yes. Understood, thanks for deep-diving on this! 🙂

[whym]

HTML now has now changed and the icon image is surrounded by a noprint span. Removing noprint elements will remove these images.

I think it's safer to create a new HTML function with this removal feature, and leave the existing one unchanged. We don't know if all other usage of the function is compatible with the change. (At least I haven't checked.)

A different example: https://commons.wikimedia.org/wiki/File:St_Peter,_Bounces_Road,_Edmonton_-_geograph.org.uk_-_3802520.jpg