Page MenuHomePhabricator

Requesting content revision from the API, in case Parsoid is down, results in showing "Due to a technical error, this post could not be retrieved." inside the editor
Closed, ResolvedPublic

Description

This seems to be the "fault" of Templating.php lines 153-160 ('catch' block) where if the request for the format failed, the content itself is changed to the message 'flow-stub-post-content'. This means that the recipient is unaware of the fact that there was a problem with fetching the data.

This is fine for viewing data (say, if a topic revision has failed, it will render on the page with that message) - but it is pretty unhelpful for the editing process, where the editor then simply displays that raw message in the editor as if that's the edited content. If a user clicks "save" on that, that will save and the user will have no indication that an error ever occurred.

To reproduce:

  1. In a local wiki, shut down parsoid.
  2. Go to a Flow page.
  3. Edit the description/header

The editor opens as if nothing is wrong, with the content "Due to a technical error, this post could not be retrieved."

Details

Related Gerrit Patches:
mediawiki/extensions/Flow : masterDon't wrap Documents with <body> tags

Event Timeline

Mooeypoo created this task.Aug 5 2015, 7:24 PM
Mooeypoo raised the priority of this task from to Needs Triage.
Mooeypoo updated the task description. (Show Details)
Mooeypoo added a subscriber: Mooeypoo.
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptAug 5 2015, 7:24 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Catrope triaged this task as Medium priority.Aug 5 2015, 11:34 PM
Catrope added a subscriber: Catrope.

Matt says we should (re)throw the exception rather than overwriting the content.

I got the "Due to a technical error, this post could not be retrieved" error on some older comments in Flow and tracked it down to this block of code.

For reasons unknown to me right now, Flow\Parsoid\ContentFixer::createDOM( $content ) was being fed $content that began <!DOCTYPE html> and contained a complete HTML document.

Adding a check for <!DOCTYPE at the beginning seemed to fix my case.

Change 390078 had a related patch set uploaded (by MarkAHershberger; owner: MarkAHershberger):
[mediawiki/extensions/Flow@master] Don't wrap Documents with <body> tags

https://gerrit.wikimedia.org/r/390078

Change 390078 merged by jenkins-bot:
[mediawiki/extensions/Flow@master] Don't wrap Documents with <body> tags

https://gerrit.wikimedia.org/r/390078

MarkAHershberger closed this task as Resolved.Apr 18 2018, 6:13 PM
MarkAHershberger claimed this task.