Last modified: 2014-09-22 14:21:03 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T73074, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 71074 - Parsoid: Selser drops fostered categories?
Parsoid: Selser drops fostered categories?
Status: NEW
Product: Parsoid
Classification: Unclassified
serializer (Other open bugs)
unspecified
All All
: Normal normal
: ---
Assigned To: Parsoid Team
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2014-09-19 22:24 UTC by Roan Kattouw
Modified: 2014-09-22 14:21 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Roan Kattouw 2014-09-19 22:24:56 UTC
User-facing example: go to https://www.mediawiki.org/wiki/User:Roan_Kattouw_%28WMF%29?veaction=edit , make a small change, click "Save page" then "Review changes". Note that the diff drops the category. Now click "Return to save form" and "Resume editing", undo your changes manually (NOT using the undo function), and review changes again. This time the categories aren't dropped.

Note that in the Parsoid HTML, the category is fostered to before the table. Selser then seems to drop it on the floor, but only if there was a change to the body.

I was unable to reproduce this exact bug on the command line but I did see weird things:

$ echo '<table><tr><td>Hello</td></tr>[[Category:Foo]]' | node tests/parse.js --wt2wt
[warning][enwiki/Main Page] DSR inconsistency: cs/s mismatch for node: BODY s: 0 ; cs: 30
[[Category:Foo]]<table><tr><td>Hello</td></tr>


$ echo '<table><tr><td>Hello</td></tr>[[Category:Foo]]' | node tests/parse.js --wt2wt --selser
<nowiki>[[Category:Foo]]</nowiki>
{|
|Hello
|}
Comment 1 ssastry 2014-09-19 22:51:50 UTC
This behavior is partly "by design". The current behavior is optimized for scenarios where the table (from which content got fostered) is not edited. We want to prevent corruption (loss of information OR duplication of content) in those scenarios.

The wt2html parse assigns zero-width dsr info to fostered content. This works well in selser because when it encounters these nodes, it just emits an empty string and the table after it emits the original content (as long as it was not edited).

But, if the table is edited, the fostered content node before it goes to '', and the table is serialized normally. Since the table html no longer has the fostered content there, the table doesn't emit the fosterable content either, and effectively, that is lost.

The solution to this problem would be to fix our DOMDiff to set edit-flags of fostered content nodes to be the same as edit-flags of the table from which they were fostered.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links