Page MenuHomePhabricator

wikitext-to-mobile-html API failing in iOS and Android apps
Closed, ResolvedPublic


iOS and Android apps aren't showing section edit previews for non-intro sections.

This is the response:

	"type": "",
	"title": "TypeError",
	"method": "POST",
	"detail": "Cannot read property 'tagName' of null",
	"uri": "/"

Some background
The wikitext/to/mobile-html call [restbase, I believe] just pipes output from wikitext/to/html API [parsoid, I believe] into html/to/mobile-html [in PCS].

Some investigation
If you remove the section header from the wikitext, it doesn't fail. (And thus the intro section doesn't fail, as it doesn't have a section header.)

The html-to-mobile-html conversion is failing because the request html (in part) looks like this:

<body id="mwAA" lang="en" class="mw-content-ltr sitedir-ltr ltr mw-body-content parsoid-body mediawiki mw-parser-output"
	<section data-mw-section-id="0" id="mwAQ"></section>
	<section data-mw-section-id="1" id="mwAg">
		<h2 id="Social_activities_and_organizations">Social activities and organizations</h2>

If you remove <section data-mw-section-id="0" id="mwAQ"></section>, it works just fine.

I can replicate this bug locally with PCS. Thus the current question is "did parsoid recently chagne and add that empty section, or did PCS recently change and become unable to handle that empty section?"

From pulling an older version of PCS, it seems that this is a PCS problem. I'm currently working on isolating exactly which merge introduced the problem.

Event Timeline

MattCleinman triaged this task as Unbreak Now! priority.May 4 2021, 11:29 PM
MattCleinman updated the task description. (Show Details)
MattCleinman updated the task description. (Show Details)

Found the problem code: It's in MobileHTML.js's moveLeadParagraphUp. If you comment out these three lines, the bug goes away:

if (child.tagName === 'STYLE' || child.tagName === 'LINK') {
        child = child.nextElementSibling;

Looks like it's from this patch, which was further modified by this patch.

Since I can't deploy a fix anyway, I'll leave the fix to someone who knows this codebase a bit better than I.

Also it would seem we don't have any tests for html-to-mobile-html that use realistic output for an article section. (Or if we do, that html output is out of date.) I know I've touched that before, so fault partially lies with me - but if we added testing for some real HTML here, would the output change so often that keeping the tests' intended output current be difficult?

Change 685321 had a related patch set uploaded (by MSantos; author: MSantos):

[mediawiki/services/mobileapps@master] html/to/mobile-html: fix endpoint failure

Change 685321 merged by jenkins-bot:

[mediawiki/services/mobileapps@master] html/to/mobile-html: fix endpoint failure