I've mentioned this bug in standup a couple times as part of working on T230695, but here it is formalized as a ticket.
== Steps to reproduce
# Visit https://en.m.wikipedia.beta.wmflabs.org/wiki/Talk:Test_ascii_toc
# Click on '存在' section
== Expected results
- TalkSectionOverlay opens
== Actual results
- TalkSectionOverlay does not open
Different browsers have different behavior depending on the section clicked:
| Section | chrome 78 | safari 13.0.3 | firefox 65.0 | Android chrome 78 | iOS Safari 12.0
|存在| doesn't open| doesn't open| doesn't open | doesn't open | doesn't open
| `backtick test|doesn't open| opens| doesn't open | doesn't open | opens
| "Quote" test|doesn't open| opens| doesn't open | doesn't open | opens
|2 > 1|doesn't open| opens| doesn't open | doesn't open | opens
|😭|doesn't open| doesn't open| doesn't open | doesn't open | doesn't open
|abc123| opens | opens| opens | opens | opens
=== Check any additional observations
[x] Observed on the [[ https://en.m.wikipedia.beta.wmflabs.org/wiki/Talk:Test_ascii_toc | beta cluster wiki ]]
[] Observed on a [[ https://en.wikipedia.org/wiki/Barack_Obama | production wiki ]]
[] Observed on [[ https://en.wikipedia.org/wiki/Barack_Obama | Vector desktop skin ]]
[] Observed on [[ https://en.m.wikipedia.org/wiki/Barack_Obama | MinervaNeue responsive skin ]]
[x] Observed while logged in
[x] Observed while //not// logged in (anonymous)
== Dev notes
Each section contains an `.mw-headline` element with an `id` attribute. Whatever is in that `id` attribute is [[ https://github.com/wikimedia/mediawiki-skins-MinervaNeue/blob/3e26cb560ba9a79e820ac7dc06d75e0ad9c2ffcc/resources/skins.minerva.scripts/talk.js#L115 | registered as a path in OverlayManager ]]. OverlayManager listens to hash changes and only opens up the overlay if the id [[ https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/f586b1bc6ccb4c69c7cbc394936b865d59eafcad/src/mobile.startup/OverlayManager.js#L232 | exactly equals the hash path ]].
However, browsers can encode location addresses in different ways which can break this equality check. If they perform any encoding at all on the characters, the overlay will not open.
E.g. Try clicking on the `存在` section. And then in dev console enter:
```
location.hash
```
This gives:
```
"#%E5%AD%98%E5%9C%A8"
```
But OverlayManager is registered as `存在` so because `"存在" !== "%E5%AD%98%E5%9C%A8"`, the equality check fails. Furthermore, because browsers encode different characters differently as evident from the table above, we can't simply register the route with OverlayManager in its percent encoded form - we would also need the browser to navigate to this percent encoded hash (e.g. The `.mw-headline` id would need to also be percent encoded).
A workaround which literally relies on how the browser performs the encoding was performed here: https://gerrit.wikimedia.org/r/#/c/mediawiki/skins/MinervaNeue/+/548945/
But there is more discussion to be had on whether the section id should be percent encoded to begin with (e.g. via the Parser) which would seem to avoid this problem. However, there might be other concerns associated with doing it this way (see T152540).
== QA Steps
Because browsers can exhibit different behavior with this ticket, it is important to test the following steps across a range of browsers. Therefore, it would be good idea to test:
**Android Chrome, Android Firefox, Android Edge, iOS Safari**:
1) Go to https://en.m.wikipedia.beta.wmflabs.org/wiki/Talk:Test_ascii_toc
2) Click on each section. Verify that the Talk Overlay opens and that it corresponds to the section clicked.