Page MenuHomePhabricator

Update DSR computation to ignore fostered content
Closed, ResolvedPublic


In bug 50502 comment 7, Guillaume reported:

In this edit, a table was duplicated (but it wasn't in a template):

I was able to replicate this in Chrome. In addition, I was able to download the original Parsoid HTML for that old-id, the wikitext for that old-id, edit the HTML locally and verify the table duplication on the command line as follows.

$ node parse --html2wt --selser --oldhtmlfile /tmp/fr.html --oldtextfile /tmp/fr.orig.wt < /tmp/fr.edited.html > /tmp/fr.edited.wt

Investigating ...

Version: unspecified
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 1:55 AM
bzimport set Reference to bz53429.

Verified on HTML output generated by latest master (84fac157) -- this rules that that is just a problem with old cached html.

Traced this to buggy DSR on a paragraph before fostered content. This only happens when a DSR carryign element (like a link) gets fostered out of the table. The DSR for the paragraph effectively spanned the actual start till the end of the fostered element -- which then causes duplication of table content till that point.

Change 81429 had a related patch set uploaded by Subramanya Sastry:
(Bug 53429) Fixed buggy fostered-node handling in DSR computation

Change 81429 merged by jenkins-bot:
(Bug 53429) Fixed buggy fostered-node handling in DSR computation

The fix and new code is deployed on production. However, because of caching reasons, you should make a null wikitext source edit on that page so that the old html is purged from the cache. On a new VE edit, you should see the fix working without corrupting the page.

We could have purged the cache completely, but we think this problem only affects a small fraction of pages and it seems better to just wait for template changes and wikitext source edits to gradually purge the bad versions.

I am closing this now, but please reopen if the problem isn't fixed.