Updated mediawiki/extensions
Project: mediawiki/extensions/Parsoid  2e8619ad498033b1504e4e2e17fe6c503305ba18

(Bug 52296) Delete empty autoinserted tags in the last DOM pass

* Normally td-tags should have a leading pipe-char in start-of-line
  position. However, with buggy wikitext, table-row tag ("|-")
  is followed by text on a new line without the leading pipe.

  In order to accommodate and support such buggy wikitext, the tokenizer
  attempts to recognize "implicit" td-tags that follow a tr-tag.
  However, the tokenizer doesn't have sufficient information to
  always do this correctly and occasionally introduces an unnecessary
  td-tag (which turns out to be empty).

  We also handle this scenario in a DOM pass by recognizing empty
  DOM elements that were auto-inserted by the tokenizer (or the
  tree-builder when fixing mis-nested buggy wikitext -- more often
  than you would think).

  However, the dom pass that deleted empty DOM elements was run
  too early (when the "empty" elements had marker meta tags used
  for other DOM passes).  So, it wouldn't get deleted and would
  then introduce empty cells in output (examples + live diffs are
  linked in the bug report).  Simplified test case below:

{{Certification Table Top}}
|-
|foo||bar||baz
|}

* This patch moves the dom pass that deletes empty elements right
  to the end before saving data-parsoid.  This now fixes the bug,
  the test snippet and the examples in the bug report.

* Cleaned up saveDataParsoid uses.

* We have a wt2wt failure introduced by the reordering.  The test
  case is a contrived test case where a newline is missing in wt2wt
  output. This also leads to a bunch of selser failures (normal
  when wt2wt fails).

  The reason for wt2wt failure is because the html output is
  slightly different.  "<tr>\n</tr>" instead of "<tr></tr>\n".
  Since the empty td is not deleted before 'migrateTrailingNLs'
  pass is run, the newline in <tr> before the empty-td doesn't
  migrate out which accounts for the difference in HTML output.

  In turn since this <tr> is now followed by a template, the
  serializer does not emit any separator before it which leads
  to the newline diff in RT-ing.

  This behavior should be harmless in production and might introduce
  dirty syntactic diffs in some cases.

  I have blacklisted these failures for now.

Change-Id: Iaea6e144aae4d7461775b898968231c9e4cb7254