Last modified: 2014-10-22 23:36:08 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 T72857, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 70857 - When you copy and paste a table, the result shouldn't have nowikis inserted (scope=col)
When you copy and paste a table, the result shouldn't have nowikis inserted (...
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-15 18:40 UTC by WhatamIdoing
Modified: 2014-10-22 23:36 UTC (History)
4 users (show)

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


Attachments

Description WhatamIdoing 2014-09-15 18:40:13 UTC
See https://fr.wikipedia.org/w/index.php?diff=107442976&oldid=107442557 for an example.

Cutting and pasting the table takes this line of wikitext:

! scope=col| Performance


and turns it into this mess:

! scope="col" |
<nowiki> </nowiki>Performance
Comment 1 James Forrester 2014-10-22 21:51:53 UTC
Can't quite work out what's going wrong here; this feels like a Parsoid bug, but I can't pin it down. Don't suppose this looks familiar to them?
Comment 2 ssastry 2014-10-22 23:00:32 UTC
Seems like on cut-paste, the contents of the <th> are being wrapped in a p-wrapper.

<th scope="col"> <p>Épreuve</p></th>
<th scope="col"> <p>Performance</p></th>
<th scope="col"> <p>Lieu</p></th>

Parsoid then serializes them on newlines but also moves the leading space to the next line which forces it to nowiki wrap it to prevent it from re-parsing as an indent-pre.

So, there are a couple issues here:
(a) Parsoid could leave the whitespace behind on the previous line which will eliminate the nowiki.
(b) But, fixing (a) will still serialize the content on a newline. To prevent that, either VE should not wrap content in <p>-tags or Parsoid could enforce normalization when serializing content in new table cells under certain conditions.

For now, I'll investigate (a) and see what is involved.
Comment 3 ssastry 2014-10-22 23:36:08 UTC
For whoever is debugging on the Parsoid end. Here is what I found out so far.

Looks like the serializer is unable to distinguish between the 2 separator scenarios in the two <th> tags and serializes them identically whereas the first one shouldn't get the <nowiki>, but the second one should. makeSeparator in wts.separators.js is the code in question.

<table><tbody>
<tr><th> <!--a--><p>h1</p></th></tr>
<tr><td>a</td></tr>
<tr><th><p> <!--b-->h2</p></th></tr>
<tr><td>b</td></tr>
</tbody></table>

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


Navigation
Links