There is a bug with lazy loaded references that leads to references not showing up and the drawer being closed.
Steps to reproduce
- Opt into beta
- Visit https://en.m.wikipedia.org/wiki/Barack_Obama
- Search for "[11]"
- Tap "[11]"
Expected results
The reference drawer is shown and stays open until dismissed manually
Actual results
Sometimes nothing happens, other times the drawer opens and immediately slams shut!
note: this is happening on stable as well
https://drive.google.com/file/d/1qEDv9fU89pAyl7StrHpu7uwoasB9bEis/view?usp=sharing
Environments observed
Browser Version:
- Chromium v64.0.3282.167 (Official Build) Built on Ubuntu , running on Ubuntu 17.10 (64-bit)
- Mobile web BETA mode
OS Version:
- Ubuntu v17.10
- Android v8.1.0
Device Model:
- Desktop
- Pixel XL
Device Language:
- English
Developer notes
The bug is inside ReferencesHtmlScraperGateway.getReferenceFromContainer
I started by investigating beta. Inside ReferencesDrawer.showReference
gateway is an instance of ReferencesMobileViewGateway
The call to getReference throws an error
ReferencesGateway.ERROR_NOT_EXIST
This bug, as reported by @Mhurd in T183049, is caused because of unexpected encoding occurring on the HTML.
Mobile:
<sup id="cite_ref-Obama_1995,_2004,_pp._9–10_11-0" class="reference"><a href="#cite_note-Obama_1995,_2004,_pp._9%E2%80%9310-11">[11]</a></sup>
Desktop:
<sup id="cite_ref-Obama_1995,_2004,_pp._9–10_11-0" class="reference"><a href="#cite_note-Obama_1995,_2004,_pp._9–10-11">[11]</a></sup>
The problem lies somewhere inside the HTMLFormatter. After 20 mins debugging it seems that the problem relies inside MobileFormatter::filterContent or HtmlFormatter::getDoc
A client side fix can be made but it feels a little hacky. It would look like this:
- If the reference cannot be found, attempt to call decodeURIComponent on the href and try again.
A server side fix will be trickier as it's likely to be related to the loadHTML method of DOMDocument. We do not directly modify the href attributes of the link.
