2020-01-21 22:01:11 +00:00
|
|
|
var
|
|
|
|
utils = require( './utils.js' ),
|
|
|
|
parser = require( 'ext.discussionTools.parser' ),
|
|
|
|
modifier = require( 'ext.discussionTools.modifier' );
|
|
|
|
|
|
|
|
QUnit.module( 'mw.dt.modifier', utils.newEnvironment() );
|
|
|
|
|
|
|
|
QUnit.test( '#addListItem', function ( assert ) {
|
|
|
|
var i, j, cases, actualHtml, expectedHtml, comments, node, fixture;
|
|
|
|
|
|
|
|
cases = [
|
|
|
|
{
|
|
|
|
name: 'plwiki oldparser',
|
|
|
|
dom: mw.template.get( 'test.DiscussionTools', 'oldparser/pl-55171451.html' ).render(),
|
|
|
|
expected: mw.template.get( 'test.DiscussionTools', 'oldparser/pl-55171451-modified.html' ).render(),
|
|
|
|
config: require( './data/plwiki-config.json' ),
|
|
|
|
data: require( './data/plwiki-data.json' )
|
|
|
|
},
|
|
|
|
{
|
|
|
|
name: 'plwiki parsoid',
|
|
|
|
dom: mw.template.get( 'test.DiscussionTools', 'parsoid/pl-55171451.html' ).render(),
|
|
|
|
expected: mw.template.get( 'test.DiscussionTools', 'parsoid/pl-55171451-modified.html' ).render(),
|
|
|
|
config: require( './data/plwiki-config.json' ),
|
|
|
|
data: require( './data/plwiki-data.json' )
|
|
|
|
},
|
|
|
|
{
|
|
|
|
name: 'enwiki oldparser',
|
|
|
|
dom: mw.template.get( 'test.DiscussionTools', 'oldparser/en-913983958.html' ).render(),
|
|
|
|
expected: mw.template.get( 'test.DiscussionTools', 'oldparser/en-913983958-modified.html' ).render(),
|
|
|
|
config: require( './data/enwiki-config.json' ),
|
|
|
|
data: require( './data/enwiki-data.json' )
|
|
|
|
},
|
|
|
|
{
|
|
|
|
name: 'enwiki parsoid',
|
|
|
|
dom: mw.template.get( 'test.DiscussionTools', 'parsoid/en-913983958.html' ).render(),
|
|
|
|
expected: mw.template.get( 'test.DiscussionTools', 'parsoid/en-913983958-modified.html' ).render(),
|
|
|
|
config: require( './data/enwiki-config.json' ),
|
|
|
|
data: require( './data/enwiki-data.json' )
|
Pick reply insertion point based on parser tree, not DOM tree
I don't like that I had to special-case `<p>` tags (top-level
comments) in this code. I feel like it should be possible to handle
top-level comments and replies in a generic way, but I couldn't find
a way to do it that actually worked.
Notes about changes to the behavior, based on the test cases:
* Given a top-level comment A, if there was a "list gap" in the
replies to it: previously new replies would be incorrectly added at
the location of the gap; now they are added after the last reply.
(T242822)
Example: "pl", comment at "08:23, 29 wrz 2018 (CEST)"
* Given a top-level comment A and a reply to it B that skips an
indentation level: previously new replies to A would be added with
the same indentation level as B; now they are added with the
indentation level of A plus one. (The old behavior wasn't a bug, and
this is an accidental effect of other changes, but it seems okay.)
Example: "pl", comment at "03:22, 30 wrz 2018 (CEST)"
and reply at "09:43, 30 wrz 2018 (CEST)"
* Given a top-level comment A, a reply to it B, and a following
top-level comment C that starts at the same indentation level as B:
previously new replies to A would be incorrectly added in the middle
of the comment C, due to the DOM list structure; now they are added
before C. (T241391)
(It seems that comment C was supposed to be a multi-line reply that
was wrongly indented. Unfortunately we have no way to distinguish
this case from a top-level multi-line comment that just happens to
start with a bullet list.)
Example: "pl", comments at "03:36, 24 paź 2018 (CEST)",
"08:35, 24 paź 2018 (CEST)", "17:14, 24 paź 2018 (CEST)"
* In the "en" example, there are some other changes where funnily
nested tags result in slightly different results with the new code.
They don't look important.
* In rare cases, we must split an existing list to add a reply in the
right place. (Basically add `</ul>` before the reply and `<ul>`
after, but it's a bit awkward in DOM terms.)
Example: split-list.html, comment "aaa"; also split-list2.html
(which is the result of saving the previous reply), comment "aaa"
* The modifier can no longer generate DOM that is invalid HTML, fixing
a FIXME in modifier.test.js (or at least, it doesn't happen in these
test cases any more).
Bug: T241391
Bug: T242822
Change-Id: I2a70db01e9a8916c5636bc59ea8490166966d5ec
2020-01-15 06:09:13 +00:00
|
|
|
},
|
|
|
|
{
|
|
|
|
name: 'Must split a list to reply to one of the comments',
|
|
|
|
dom: mw.template.get( 'test.DiscussionTools', 'other/split-list.html' ).render(),
|
|
|
|
expected: mw.template.get( 'test.DiscussionTools', 'other/split-list-modified.html' ).render(),
|
|
|
|
config: require( './data/enwiki-config.json' ),
|
|
|
|
data: require( './data/enwiki-data.json' )
|
|
|
|
},
|
|
|
|
{
|
|
|
|
name: 'Must split a list to reply to one of the comments (version 2)',
|
|
|
|
dom: mw.template.get( 'test.DiscussionTools', 'other/split-list2.html' ).render(),
|
|
|
|
expected: mw.template.get( 'test.DiscussionTools', 'other/split-list2-modified.html' ).render(),
|
|
|
|
config: require( './data/enwiki-config.json' ),
|
|
|
|
data: require( './data/enwiki-data.json' )
|
2020-01-21 22:01:11 +00:00
|
|
|
}
|
|
|
|
];
|
|
|
|
|
|
|
|
fixture = document.getElementById( 'qunit-fixture' );
|
|
|
|
|
|
|
|
for ( i = 0; i < cases.length; i++ ) {
|
|
|
|
utils.overrideMwConfig( cases[ i ].config );
|
|
|
|
utils.overrideParserData( cases[ i ].data );
|
|
|
|
|
|
|
|
$( fixture ).empty().append( cases[ i ].expected );
|
|
|
|
expectedHtml = fixture.innerHTML;
|
|
|
|
|
|
|
|
$( fixture ).empty().append( cases[ i ].dom.clone() );
|
|
|
|
comments = parser.getComments( fixture );
|
|
|
|
parser.groupThreads( comments );
|
|
|
|
|
|
|
|
// Add a reply to every comment. Note that this inserts *all* of the replies, unlike the real
|
|
|
|
// thing, which only deals with one at a time. This isn't ideal but resetting everything after
|
|
|
|
// every reply would be super slow.
|
|
|
|
for ( j = 0; j < comments.length; j++ ) {
|
|
|
|
if ( comments[ j ].type === 'heading' ) {
|
|
|
|
continue;
|
|
|
|
}
|
Pick reply insertion point based on parser tree, not DOM tree
I don't like that I had to special-case `<p>` tags (top-level
comments) in this code. I feel like it should be possible to handle
top-level comments and replies in a generic way, but I couldn't find
a way to do it that actually worked.
Notes about changes to the behavior, based on the test cases:
* Given a top-level comment A, if there was a "list gap" in the
replies to it: previously new replies would be incorrectly added at
the location of the gap; now they are added after the last reply.
(T242822)
Example: "pl", comment at "08:23, 29 wrz 2018 (CEST)"
* Given a top-level comment A and a reply to it B that skips an
indentation level: previously new replies to A would be added with
the same indentation level as B; now they are added with the
indentation level of A plus one. (The old behavior wasn't a bug, and
this is an accidental effect of other changes, but it seems okay.)
Example: "pl", comment at "03:22, 30 wrz 2018 (CEST)"
and reply at "09:43, 30 wrz 2018 (CEST)"
* Given a top-level comment A, a reply to it B, and a following
top-level comment C that starts at the same indentation level as B:
previously new replies to A would be incorrectly added in the middle
of the comment C, due to the DOM list structure; now they are added
before C. (T241391)
(It seems that comment C was supposed to be a multi-line reply that
was wrongly indented. Unfortunately we have no way to distinguish
this case from a top-level multi-line comment that just happens to
start with a bullet list.)
Example: "pl", comments at "03:36, 24 paź 2018 (CEST)",
"08:35, 24 paź 2018 (CEST)", "17:14, 24 paź 2018 (CEST)"
* In the "en" example, there are some other changes where funnily
nested tags result in slightly different results with the new code.
They don't look important.
* In rare cases, we must split an existing list to add a reply in the
right place. (Basically add `</ul>` before the reply and `<ul>`
after, but it's a bit awkward in DOM terms.)
Example: split-list.html, comment "aaa"; also split-list2.html
(which is the result of saving the previous reply), comment "aaa"
* The modifier can no longer generate DOM that is invalid HTML, fixing
a FIXME in modifier.test.js (or at least, it doesn't happen in these
test cases any more).
Bug: T241391
Bug: T242822
Change-Id: I2a70db01e9a8916c5636bc59ea8490166966d5ec
2020-01-15 06:09:13 +00:00
|
|
|
node = modifier.addListItem( comments[ j ] );
|
2020-01-21 22:01:11 +00:00
|
|
|
node.textContent = 'Reply to ' + comments[ j ].id;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Uncomment this to get updated content for the the "modified HTML" files, for copy/paste:
|
|
|
|
// console.log( fixture.innerHTML );
|
|
|
|
|
|
|
|
actualHtml = fixture.innerHTML.trim();
|
|
|
|
|
|
|
|
assert.strictEqual(
|
|
|
|
actualHtml,
|
|
|
|
expectedHtml,
|
|
|
|
cases[ i ].name
|
|
|
|
);
|
|
|
|
}
|
|
|
|
} );
|