2019-11-05 13:55:01 +00:00
|
|
|
'use strict';
|
|
|
|
|
2019-12-10 21:46:22 +00:00
|
|
|
var
|
|
|
|
parser = require( 'ext.discussionTools.parser' ),
|
|
|
|
modifier = require( 'ext.discussionTools.modifier' ),
|
2020-02-19 01:25:38 +00:00
|
|
|
logger = require( 'ext.discussionTools.logger' ),
|
2020-02-15 04:03:18 +00:00
|
|
|
pageDataCache = {},
|
2019-12-10 21:46:22 +00:00
|
|
|
$pageContainer,
|
2019-11-21 13:12:24 +00:00
|
|
|
scrollPadding = { top: 10, bottom: 10 },
|
2019-11-05 14:07:50 +00:00
|
|
|
config = require( './config.json' ),
|
|
|
|
replyWidgetPromise = config.useVisualEditor ?
|
|
|
|
mw.loader.using( 'ext.discussionTools.ReplyWidgetVisual' ) :
|
|
|
|
mw.loader.using( 'ext.discussionTools.ReplyWidgetPlain' );
|
2019-11-05 13:55:01 +00:00
|
|
|
|
|
|
|
function setupComment( comment ) {
|
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
|
|
|
var $replyLink, widgetPromise, newListItem,
|
2019-11-05 13:55:01 +00:00
|
|
|
$tsNode = $( comment.range.endContainer );
|
|
|
|
|
|
|
|
// Is it possible to have a heading nested in a thread?
|
|
|
|
if ( comment.type !== 'comment' ) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
$replyLink = $( '<a>' )
|
|
|
|
.addClass( 'dt-init-replylink' )
|
2019-12-06 18:43:46 +00:00
|
|
|
.text( mw.msg( 'discussiontools-replylink' ) )
|
2019-11-05 13:55:01 +00:00
|
|
|
.on( 'click', function () {
|
2019-11-24 15:39:52 +00:00
|
|
|
var $link = $( this );
|
2019-11-05 13:55:01 +00:00
|
|
|
|
2020-02-19 01:25:38 +00:00
|
|
|
logger( {
|
|
|
|
action: 'init',
|
|
|
|
type: 'page',
|
|
|
|
mechanism: 'click',
|
|
|
|
// TODO: when we have actual visual mode, this needs to do better at
|
|
|
|
// working out which will be used:
|
|
|
|
// eslint-disable-next-line camelcase
|
|
|
|
editor_interface: config.useVisualEditor ? 'wikitext-2017' : 'wikitext'
|
|
|
|
} );
|
|
|
|
|
2019-11-25 16:20:41 +00:00
|
|
|
$link.addClass( 'dt-init-replylink-active' );
|
2019-11-05 13:55:01 +00:00
|
|
|
// TODO: Allow users to use multiple reply widgets simlutaneously
|
|
|
|
// Currently as all widgets share the same Parsoid doc, this could
|
|
|
|
// cause problems.
|
|
|
|
$pageContainer.addClass( 'dt-init-replylink-open' );
|
|
|
|
|
|
|
|
if ( !widgetPromise ) {
|
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
|
|
|
newListItem = modifier.addListItem( comment );
|
2019-12-06 18:43:46 +00:00
|
|
|
$( newListItem ).text( mw.msg( 'discussiontools-replywidget-loading' ) );
|
2019-11-05 13:55:01 +00:00
|
|
|
widgetPromise = replyWidgetPromise.then( function () {
|
2019-12-10 21:46:22 +00:00
|
|
|
var
|
2019-11-05 14:07:50 +00:00
|
|
|
ReplyWidget = config.useVisualEditor ?
|
|
|
|
require( 'ext.discussionTools.ReplyWidgetVisual' ) :
|
|
|
|
require( 'ext.discussionTools.ReplyWidgetPlain' ),
|
2019-12-10 21:46:22 +00:00
|
|
|
replyWidget = new ReplyWidget(
|
|
|
|
comment
|
|
|
|
);
|
2019-11-05 13:55:01 +00:00
|
|
|
|
2019-12-10 15:15:40 +00:00
|
|
|
replyWidget.on( 'teardown', function () {
|
2019-11-25 16:20:41 +00:00
|
|
|
$link.removeClass( 'dt-init-replylink-active' );
|
2019-11-05 13:55:01 +00:00
|
|
|
$pageContainer.removeClass( 'dt-init-replylink-open' );
|
|
|
|
$( newListItem ).hide();
|
|
|
|
} );
|
|
|
|
|
|
|
|
$( newListItem ).empty().append( replyWidget.$element );
|
|
|
|
return replyWidget;
|
|
|
|
}, function () {
|
2019-11-25 16:20:41 +00:00
|
|
|
$link.removeClass( 'dt-init-replylink-active' );
|
2019-11-05 13:55:01 +00:00
|
|
|
$pageContainer.removeClass( 'dt-init-replylink-open' );
|
2020-02-19 01:25:38 +00:00
|
|
|
|
|
|
|
logger( {
|
|
|
|
action: 'abort',
|
|
|
|
type: 'preinit'
|
|
|
|
} );
|
2019-11-05 13:55:01 +00:00
|
|
|
} );
|
|
|
|
}
|
|
|
|
widgetPromise.then( function ( replyWidget ) {
|
|
|
|
$( newListItem ).show();
|
2019-12-10 15:15:40 +00:00
|
|
|
replyWidget.setup();
|
2019-11-21 13:12:24 +00:00
|
|
|
replyWidget.scrollElementIntoView( { padding: scrollPadding } );
|
2019-11-05 13:55:01 +00:00
|
|
|
replyWidget.focus();
|
2020-02-19 01:25:38 +00:00
|
|
|
|
|
|
|
logger( { action: 'ready' } );
|
|
|
|
logger( { action: 'loaded' } );
|
2019-11-05 13:55:01 +00:00
|
|
|
} );
|
|
|
|
} );
|
|
|
|
|
|
|
|
$tsNode.after( $replyLink );
|
|
|
|
}
|
|
|
|
|
|
|
|
function traverseNode( parent ) {
|
|
|
|
parent.replies.forEach( function ( comment ) {
|
|
|
|
setupComment( comment );
|
|
|
|
traverseNode( comment );
|
|
|
|
} );
|
|
|
|
}
|
|
|
|
|
2019-11-05 14:07:50 +00:00
|
|
|
function autoSignWikitext( wikitext ) {
|
2019-12-12 15:28:42 +00:00
|
|
|
wikitext = wikitext.trim();
|
|
|
|
if ( wikitext.slice( -4 ) !== '~~~~' ) {
|
|
|
|
wikitext += ' ~~~~';
|
|
|
|
}
|
|
|
|
return wikitext;
|
|
|
|
}
|
|
|
|
|
2019-11-05 13:55:01 +00:00
|
|
|
function postReply( widget, parsoidData ) {
|
2020-02-20 20:24:07 +00:00
|
|
|
var root, summaryPrefix, summary,
|
2019-11-05 13:55:01 +00:00
|
|
|
comment = parsoidData.comment,
|
|
|
|
pageData = parsoidData.pageData,
|
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
|
|
|
newParsoidItem = modifier.addListItem( comment );
|
2019-11-05 13:55:01 +00:00
|
|
|
|
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
|
|
|
widget.insertNewNodes( newParsoidItem );
|
2019-11-05 13:55:01 +00:00
|
|
|
|
|
|
|
root = comment;
|
|
|
|
while ( root && root.type !== 'heading' ) {
|
|
|
|
root = root.parent;
|
|
|
|
}
|
2020-02-20 20:24:07 +00:00
|
|
|
if ( root.placeholderHeading ) {
|
|
|
|
// This comment is in 0th section, there's no section title for the edit summary
|
|
|
|
summaryPrefix = '';
|
|
|
|
} else {
|
|
|
|
summaryPrefix = '/* ' + root.range.startContainer.innerText + ' */ ';
|
|
|
|
}
|
2019-11-05 13:55:01 +00:00
|
|
|
|
2020-02-20 20:24:07 +00:00
|
|
|
summary = summaryPrefix + mw.msg( 'discussiontools-defaultsummary-reply' );
|
2019-11-05 13:55:01 +00:00
|
|
|
|
2020-01-24 23:39:06 +00:00
|
|
|
return mw.libs.ve.targetSaver.saveDoc(
|
|
|
|
parsoidData.doc,
|
|
|
|
{
|
|
|
|
page: pageData.pageName,
|
|
|
|
oldid: pageData.oldId,
|
|
|
|
summary: summary,
|
|
|
|
basetimestamp: pageData.baseTimeStamp,
|
|
|
|
starttimestamp: pageData.startTimeStamp,
|
|
|
|
etag: pageData.etag,
|
2020-02-15 02:01:31 +00:00
|
|
|
assert: mw.user.isAnon() ? 'anon' : 'user',
|
|
|
|
assertuser: mw.user.getName() || undefined,
|
2020-02-05 18:24:23 +00:00
|
|
|
// This appears redundant currently, but as editing / new-topics get added, we'll expand it
|
2020-02-06 20:54:58 +00:00
|
|
|
dttags: [ 'discussiontools', 'discussiontools-reply', 'discussiontools-' + widget.mode ].join( ',' )
|
2020-01-24 23:39:06 +00:00
|
|
|
}
|
|
|
|
);
|
2019-11-05 13:55:01 +00:00
|
|
|
}
|
|
|
|
|
2019-11-13 13:57:57 +00:00
|
|
|
function highlight( comment ) {
|
|
|
|
var padding = 5,
|
2020-01-15 16:07:05 +00:00
|
|
|
// $container must be position:relative/absolute
|
|
|
|
$container = OO.ui.getDefaultOverlay(),
|
|
|
|
containerRect = $container[ 0 ].getBoundingClientRect(),
|
2020-02-05 18:30:21 +00:00
|
|
|
nativeRange, rect,
|
2019-11-13 13:57:57 +00:00
|
|
|
$highlight = $( '<div>' ).addClass( 'dt-init-highlight' );
|
|
|
|
|
2020-02-05 18:30:21 +00:00
|
|
|
nativeRange = document.createRange();
|
|
|
|
nativeRange.setStart( comment.range.startContainer, comment.range.startOffset );
|
|
|
|
nativeRange.setEnd( comment.range.endContainer, comment.range.endOffset );
|
|
|
|
rect = RangeFix.getBoundingClientRect( nativeRange );
|
|
|
|
|
2019-11-13 13:57:57 +00:00
|
|
|
$highlight.css( {
|
|
|
|
top: rect.top - containerRect.top - padding,
|
|
|
|
left: rect.left - containerRect.left - padding,
|
|
|
|
width: rect.width + ( padding * 2 ),
|
|
|
|
height: rect.height + ( padding * 2 )
|
|
|
|
} );
|
|
|
|
|
|
|
|
setTimeout( function () {
|
|
|
|
$highlight.addClass( 'dt-init-highlight-fade' );
|
|
|
|
setTimeout( function () {
|
|
|
|
$highlight.remove();
|
|
|
|
}, 500 );
|
|
|
|
}, 500 );
|
|
|
|
|
2020-01-15 16:07:05 +00:00
|
|
|
$container.prepend( $highlight );
|
2019-11-13 13:57:57 +00:00
|
|
|
}
|
|
|
|
|
2019-11-24 15:39:52 +00:00
|
|
|
function commentsById( comments ) {
|
|
|
|
var byId = {};
|
|
|
|
comments.forEach( function ( comment ) {
|
|
|
|
byId[ comment.id ] = comment;
|
|
|
|
} );
|
|
|
|
return byId;
|
|
|
|
}
|
|
|
|
|
2020-02-15 04:03:18 +00:00
|
|
|
/**
|
|
|
|
* Get the Parsoid document HTML and metadata needed to edit this page from the API.
|
|
|
|
*
|
|
|
|
* This method caches responses. If you call it again with the same parameters, you'll get the exact
|
|
|
|
* same Promise object, and no API request will be made.
|
|
|
|
*
|
|
|
|
* @param {string} pageName Page title
|
|
|
|
* @param {number} oldId Revision ID
|
|
|
|
* @return {jQuery.Promise}
|
|
|
|
*/
|
|
|
|
function getPageData( pageName, oldId ) {
|
|
|
|
pageDataCache[ pageName ] = pageDataCache[ pageName ] || {};
|
|
|
|
if ( pageDataCache[ pageName ][ oldId ] ) {
|
|
|
|
return pageDataCache[ pageName ][ oldId ];
|
|
|
|
}
|
|
|
|
pageDataCache[ pageName ][ oldId ] = mw.loader.using( 'ext.visualEditor.targetLoader' ).then( function () {
|
|
|
|
return mw.libs.ve.targetLoader.requestPageData(
|
|
|
|
'visual', pageName, { oldId: oldId }
|
|
|
|
);
|
|
|
|
}, function () {
|
|
|
|
// Clear on failure
|
|
|
|
pageDataCache[ pageName ][ oldId ] = null;
|
|
|
|
} );
|
|
|
|
return pageDataCache[ pageName ][ oldId ];
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* Get the Parsoid document DOM, parse comments and threads, and find a specific comment in it.
|
|
|
|
*
|
|
|
|
* @param {string} pageName Page title
|
|
|
|
* @param {number} oldId Revision ID
|
|
|
|
* @param {string} commentId Comment ID, from a comment parsed in the local document
|
|
|
|
* @return {jQuery.Promise}
|
|
|
|
*/
|
|
|
|
function getParsoidCommentData( pageName, oldId, commentId ) {
|
|
|
|
var parsoidPageData, parsoidDoc, parsoidComments, parsoidCommentsById;
|
|
|
|
|
|
|
|
return getPageData( pageName, oldId )
|
|
|
|
.then( function ( response ) {
|
|
|
|
var data = response.visualeditor;
|
|
|
|
// TODO: error handling
|
|
|
|
parsoidDoc = ve.createDocumentFromHtml( data.content );
|
|
|
|
parsoidComments = parser.getComments( parsoidDoc.body );
|
|
|
|
|
|
|
|
parsoidPageData = {
|
|
|
|
pageName: pageName,
|
|
|
|
oldId: oldId
|
|
|
|
};
|
|
|
|
parsoidPageData.baseTimeStamp = data.basetimestamp;
|
|
|
|
parsoidPageData.startTimeStamp = data.starttimestamp;
|
|
|
|
parsoidPageData.etag = data.etag;
|
|
|
|
|
|
|
|
// getThreads build the tree structure, currently only
|
|
|
|
// used to set 'replies'
|
|
|
|
parser.groupThreads( parsoidComments );
|
|
|
|
parsoidCommentsById = commentsById( parsoidComments );
|
|
|
|
|
|
|
|
if ( !parsoidCommentsById[ commentId ] ) {
|
2020-02-15 04:31:06 +00:00
|
|
|
return $.Deferred().reject( 'comment-disappeared', { errors: [ {
|
|
|
|
code: 'comment-disappeared',
|
|
|
|
html: mw.message( 'discussiontools-error-comment-disappeared' ).parse()
|
|
|
|
} ] } ).promise();
|
2020-02-15 04:03:18 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
return {
|
|
|
|
comment: parsoidCommentsById[ commentId ],
|
|
|
|
doc: parsoidDoc,
|
|
|
|
pageData: parsoidPageData
|
|
|
|
};
|
|
|
|
} );
|
|
|
|
}
|
|
|
|
|
2019-11-13 13:57:57 +00:00
|
|
|
function init( $container, state ) {
|
2019-11-24 15:39:52 +00:00
|
|
|
var
|
|
|
|
pageComments, pageThreads, pageCommentsById,
|
2020-02-15 04:03:18 +00:00
|
|
|
repliedToComment;
|
2019-11-05 13:55:01 +00:00
|
|
|
|
2019-11-13 13:57:57 +00:00
|
|
|
state = state || {};
|
2019-11-05 13:55:01 +00:00
|
|
|
$pageContainer = $container;
|
2019-12-10 21:46:22 +00:00
|
|
|
pageComments = parser.getComments( $pageContainer[ 0 ] );
|
|
|
|
pageThreads = parser.groupThreads( pageComments );
|
2019-11-24 15:39:52 +00:00
|
|
|
pageCommentsById = commentsById( pageComments );
|
|
|
|
|
2019-11-05 13:55:01 +00:00
|
|
|
pageThreads.forEach( traverseNode );
|
|
|
|
|
2019-11-13 13:57:57 +00:00
|
|
|
$pageContainer.addClass( 'dt-init-done' );
|
|
|
|
$pageContainer.removeClass( 'dt-init-replylink-open' );
|
|
|
|
|
2019-11-05 13:55:01 +00:00
|
|
|
// For debugging
|
|
|
|
mw.dt.pageThreads = pageThreads;
|
|
|
|
|
2019-11-24 15:39:52 +00:00
|
|
|
if ( state.repliedTo ) {
|
|
|
|
// Find the comment we replied to, then highlight the last reply
|
|
|
|
repliedToComment = pageCommentsById[ state.repliedTo ];
|
|
|
|
highlight( repliedToComment.replies[ repliedToComment.replies.length - 1 ] );
|
2019-11-13 13:57:57 +00:00
|
|
|
}
|
|
|
|
|
2020-02-15 04:03:18 +00:00
|
|
|
// Preload the Parsoid document.
|
|
|
|
// TODO: Isn't this too early to load it? We will only need it if the user tries replying...
|
|
|
|
getPageData(
|
|
|
|
mw.config.get( 'wgRelevantPageName' ),
|
2020-02-15 04:49:58 +00:00
|
|
|
mw.config.get( 'wgCurRevisionId' )
|
2020-02-15 04:03:18 +00:00
|
|
|
);
|
2019-11-05 13:55:01 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
module.exports = {
|
|
|
|
init: init,
|
2020-02-15 04:03:18 +00:00
|
|
|
getParsoidCommentData: getParsoidCommentData,
|
2019-12-12 15:28:42 +00:00
|
|
|
postReply: postReply,
|
2019-11-05 14:07:50 +00:00
|
|
|
autoSignWikitext: autoSignWikitext
|
2019-11-05 13:55:01 +00:00
|
|
|
};
|