It appears PHP's DOM library always uses CDATA nodes for the contents of
<style> tags, even if there is no such markup in the source HTML.
Change-Id: Id04b27086c5e7a0b016a3a440b2b4895d6b13c93
It's more convenient for display or comparing it with other things.
Depends-On: I03bc455d5484a6c51f3fa2397c64936b829fe7e3
Change-Id: I88d7aa68977210b16860075ed52983a5e99ee0f7
When trying to reply to a comment that is inside a transclusion,
detect if it's transcluded from a subpage or simply wrapped in a
template, and show appropriate error messages.
References:
* VisualEditor ve.dm.Converter#getAboutGroup()
* VisualEditor ve.dm.ModelRegistry#matchElement()
* Parsoid Linter#findEnclosingTemplateName()
Bug: T245694
Change-Id: If3dd1ebbf1d02ee4379c200019bfc3a8ec02325b
If two signatures for a single comment were near each other,
we would sometimes treat them as one huge signature.
Change-Id: Ied4b3aa535a9ca6bebef8a004ae48b7d5a8f2f9b
Currently not used for anything. May be used later for editing
comments (T245225) or reformatting timestamps (T240360).
Note that a comment may have multiple signatures+timestamps,
and we return them all so that you have to deal with that.
Fix some unrelated incorrect documentation comments.
Bug: T245220
Change-Id: I51b8bf4a3bb7968f35e32c7e44c95c2ab079d9ac
They are not generated by MediaWiki, but they often appear when users
sign others' unsigned comments by copy-pasting the timestamp from the
history page.
Add test config data for nlwiki, exported by running this in the
browser console:
copy(
JSON.stringify( { wgArticlePath, wgNamespaceIds, wgFormattedNamespaces }, null, 2 ) + '\n' +
JSON.stringify( mw.loader.moduleRegistry['ext.discussionTools.parser'].packageExports['data.json'], null, 2 )
);
Bug: T245784
Change-Id: Icbcdc5a028e9ce2cb09173f87769e525ec3082fc
Consequences of this are visible in the test cases:
* (en) Tech News posts are not detected.
Examples: "21:22, 1 July 2019 (UTC)", "21:42, 29 July 2019 (UTC)"
* (en) Comments by users who customize the timestamp are not detected.
Examples: "10:49, 28 June 2019 (UTC)", "21:34, 14 July 2019 (UTC)"
* (en) Comments with signatures missing a username are not detected.
This sometimes happens if a comment is accidentally signed with
'~~~~~' (five tildes), which only inserts the timestamp.
Examples: "17:17, 27 July 2019 (UTC)", "10:25, 29 July 2019 (UTC)"
* (pl) A lone timestamp at the beginning of a thread is not detected.
It's not part of a post, it was added to aid automatic archiving.
Example: "21:03, 18 paź 2018 (CET)"
Bug: T245692
Change-Id: I0767bb239a1800f2e538917b5995fc4f0fa4d043
Native Range objects are automatically updated when the DOM elements
they refer to are affected (e.g. detached from the DOM, or their offset
changes because of siblings being added/removed).
This seemed harmless or maybe even slightly useful, but it turns out
it conflicts with VisualEditor, which has to wrap the entire page in a
new DOM node when it opens (and unwrap it when it closes), effectively
temporarily detaching it from the DOM, which destroys all our ranges.
Just use a plain object that stores the same data as a Range. And when
we need to use Range's API, we can simply construct a temporary one.
Bug: T241861
Change-Id: Iee64aa3d667877265ef8a59293c202e6478d7fb6
The loop in parser.js assumed that there was always a heading before
any comments (not counting the page title, only section headings).
Bug: T243869
Change-Id: I3a0bb06716e75d4a17e25c40748673a071ee5f30
Even when you have multiple signatures by multiple users in one
paragraph (or list item), it's still basically a single comment.
We don't want to offer multiple buttons to reply to it.
The changed parser test cases are illustrative:
* All affected comments in the "pl" example are comments with a
"post-scriptum", which is now more intuitively treated as part of
the main comment.
* The first comment in the "en" example would probably have been
better if it wasn't merged, but a weird use of the outdent template
causes us to not be able to distinguish that the two parts of the
comment display on separate lines.
* The last comment in the "en" example (isn't that neat?) was previously
incorrectly treated as two comments, because there's a timestamp in
the middle of it (the user is referring to another comment).
* Remaining affected comments in the "en" example are also comments
with a "post-scriptum" and their treatment is clearly better now.
It also accidentally fixes some problems with modifier tests (but not
all), where previously <dl> nodes would be inserted in the middle of
<p> nodes, to reply to the comments which are now merged.
Bug: T240640
Change-Id: I0f2d9238aff75d78286250affd323cd145661a11
Possible use cases:
* Matching comments between PHP and Parsoid HTML [implemented here]
* Finding the same comment in a different revision of a page
(e.g. while resolving an edit conflict, or to allow resuming
composition of autosaved comments) [implemented for highlighting
user's own posted comment only]
* Permanent links to comments [future]
The reasoning for this form of ID is:
* _Timestamp_ by itself is a nearly unique identifier, so it's a good
thing to start with
* Users may post multiple comments in one edit (or in many edits in
one minute), so we need the _sequential number_ to distinguish them
* _Username_ is probably not required, but it may reduce the need
for sequential numbers, and will help with human-readability if we
add permanent links
The ID remains stable when a new comment is added anywhere by anyone
(excepts comments within the same minute by the same user), or when a
section is renamed.
It's not always stable when a comment is moved or when an entire
section is moved or deleted (archived), but you can't have everything.
Change-Id: Idaae6427d659d12b82e37f1791bd03833632c7c0
Add the Moment Timezone library. Add a script for managing libraries,
like in MediaWiki core.
Depends-On: I9a59a6ad01850b30327e4215f2be61b8d1c41277
Change-Id: I64bc79e7d0ccdf42b006e5a225c8aa70ea5f4e15
For example, the default date format for Japanese (ja) is
"Y年n月j日 (D) H:i", which contains parentheses.
Change-Id: I4fce11f2913959dad06b3846d03df1da1e84e435
