Page MenuHomePhabricator

Unpredictable behavior of Widgets on Mobile Frontend
Open, Needs TriagePublic

Description

Update: TemplateStyles seems to be unrelated from the unpredictable behavior of widgets.
This issue seems to be unrelated to platforms, as it was reproduced with Chrome on both desktops and android devices.

To reproduce:

  1. Create a Widget that contains jQuery script.
  2. Create a CSS stylesheet. Change the content model to pure CSS.
  3. Add the widget and the CSS stylesheet linked via <templatestyles> onto a wiki page.
  4. View the saved page on mobile frontend.

Observed results:

  • The widget behaves unpredictably; occasionally it works, but often part of the script is cut off and apparently treated as pure text.
  • The linked stylesheet may or may not fail. Seems to be caused by failing widgets.
  • The problem is more pronounced if the page contain large amount of entries, for example repeated calls of templates that make use of templatestyles. Caused by the failed widget, placed in front of every template, breaking styles of all templates following it.

Expected result:

  • The widget and templatestyles behave as they should.

Event Timeline

One_Six created this task.Apr 29 2020, 5:29 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 29 2020, 5:29 PM
RhinosF1 changed the task status from Open to Stalled.Apr 29 2020, 5:36 PM
RhinosF1 added a subscriber: RhinosF1.

@One_Six: Could you expand on the task description to explain how it is unpredictable?

One_Six changed the task status from Stalled to Open.Apr 29 2020, 5:38 PM
One_Six updated the task description. (Show Details)

@One_Six: Could you expand on the task description to explain how it is unpredictable?

Sorry, I accidentally published the task before writing details.

@One_Six: Welcome to Wikimedia Phabricator! Thanks for updating the task description.

One_Six updated the task description. (Show Details)Apr 29 2020, 5:40 PM
One_Six updated the task description. (Show Details)Apr 29 2020, 5:46 PM
One_Six updated the task description. (Show Details)Apr 29 2020, 5:49 PM
One_Six updated the task description. (Show Details)Apr 29 2020, 6:11 PM
Tgr added a subscriber: Tgr.Apr 29 2020, 9:47 PM

Probably some parser limit is reached?

Is the mobile parser limit significantly lower than the standard parser? I am able to reproduce the described issue on this revision (mobile view) with a rather simple widget and a <div> that needs a fairly simple stylesheet.

widget: https://zh.moegirl.org/index.php?oldid=3712310&action=raw
Stylesheet: https://zh.moegirl.org/?oldid=3699386

Ah, I did some more playing around on preview and the issue seems to be isolated to the widget; same issue can be reproduced without templatestyles present. It appears that it is whatever the widget bleed through that broke the styles.

One_Six renamed this task from Unpredictable behavior when both Widgets and TemplateStyles are present on Mobile Frontend to Unpredictable behavior of Widgets on Mobile Frontend.Apr 30 2020, 1:27 AM
One_Six updated the task description. (Show Details)

Any reason why this issue has not been triaged? Large backlogs? Is there something I can do to help?

Any reason why this issue has not been triaged?

As no one/team has picked it up yet

Large backlogs?

Teams may triage things weekly or at set intervals but without knowing whose going to pick it up we can’t answer.

Is there something I can do to help?

We’ll say if there is

Shizhao moved this task from Extensions to Apps on the Chinese-Sites board.Jul 6 2020, 1:06 AM
Jdlrobson moved this task from Backlog to Tracking on the MobileFrontend board.Jul 24 2020, 2:35 AM
Jdlrobson edited projects, added MobileFrontend (Tracking); removed MobileFrontend.
Nzh21 added a subscriber: Nzh21.Jul 24 2020, 6:23 PM

I note that HtmlFormatter use DOMDocument here.

There may be a bug of DOMDocument while parsing HTML with javascript code, like this:

<?php
$doc = new \DOMDocument();
$doc->strictErrorChecking = false;
$doc->loadHTML( "<div><script>const jsString = '</div>'; /* some js code here */</script></div>" );
echo $doc->saveHTML();
?>

After I run it, I got:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html><body><div><script>const jsString = '</script></div>'; /* some js code here */</body></html>

It seems that DOMDocument cannot recognize js code correctly.

Tgr added a comment.Jul 25 2020, 12:55 AM

That's valid behavior for a HTML4 parser, as per the spec:

Although the STYLE and SCRIPT elements use CDATA for their data model, for these elements, CDATA must be handled differently by user agents. Markup and entities must be treated as raw text and passed to the application as is. The first occurrence of the character sequence "</" (end-tag open delimiter) is treated as terminating the end of the element's content. In valid documents, this would be the end tag for the element.

HTML5 would be more forgiving (although there are some restrictions still), but DOMDocument does not support it. T217360: Replace libxml/xpath in HtmlFormatter with Remex/zest is the relevant task.

Shizhao moved this task from Apps to Extensions on the Chinese-Sites board.Jul 27 2020, 1:49 AM