Page MenuHomePhabricator

Parsing/display issues with coffee roll / talk page banners
Open, LowPublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

  • Open an article that has talk page banner (en.wik: India, Thailand, id.wiki: Indonesia) on iOS app
  • Open Article Talk Page
  • Open banner using "Read more"

What happens?:

  • Message is not fully parsed into readable text

What should have happened instead?:

  • Message is fully parsed into readable text

Other information (browser name/version, screenshots, etc.):
id.wikipedia, Article: Indonesia

IMG_5322.PNG (2×1 px, 277 KB)

en.wikipedia, Article: Thailand
IMG_5323.PNG (2×1 px, 351 KB)

2022 Talk Page Epic: T301824

Event Timeline

tldr: this may actually boil down to a Parsoid issue.

If we look at the Parsoid version of the talk page in question (which is used by DiscussionTools API to give us the Talk messages and coffee-roll headings):
https://id.wikipedia.org/api/rest_v1/page/html/Pembicaraan:Indonesia

...and now look at the "source" of that page, we see a couple of places with slightly unusual markup:

...
data-mw='{"attribs":[[{"txt":"style"},{"html":"\n    text-align:center;\n    white-space:nowrap;\n    font-weight:bold;\n    background:<span typeof=\"mw:Nowiki\" data-parsoid=\"{}\">\n#b2ff66</span>;\n    "}]]}'
...

If you squint your eyes, you can see a weird bit of markup near the end: the closing span tag begins with a &lt; entity, but ends with a literal > character, which is inconsistent. It should be either <span> or &lt;/span&gt;.
Technically none of this should matter, since all of that markup is part of a data-mw attribute contained in a string, but I'm guessing for whatever reason your (iOS') HTML-to-native text parser might be tripping up on this inconsistency, while our Android parser simply ignores it. This is just a guess, but it seems to be plausible because the weird markup is rather close to the "unparsed" text seen in the screenshots.