Change the order of checks to ensure that we have at least one comment
before we try comparing ranges, to avoid issues with empty headings
having collapsed ranges. It should be a tiny bit faster this way, too.
Bug: T304377
Change-Id: I59ad30cfc075dcec882e048d2d199744efec2114
Exposed as DiscussionToolsPageInfo prop threaditemshtml. It returns a
version of the output of CommentParser, lightly adjusted to provide a
nested comment structure rather than a pure flat list.
Bug: T285971
Change-Id: I2f8503d4ed740a04fb2f1e3a37ae4db649b3faba
We were calling Title::newFromText() before setupEnv(), which meant
that the title for each test case was parsed using the default rules
for English, rather than the rules for the specified wiki.
This only makes a practical difference for tests with self-links.
Changed the only such test to demonstrate the fix.
Change-Id: I45561f1c9f0d149e2b743f0000b742bf6fc014af
The ParserAfterParse hook will likely be deprecated, as Parsoid can't
properly support it as-is. Luckily, DiscussionTools isn't doing
anything in ParserAfterParse that couldn't happen in the (supported)
ParserAfterTidy hook.
Bug: T303630
Change-Id: If72feb1e277c09f4ea0df339f2dd097a9b329d71
Also fix a bug where headings would be ignored while checking for
comment frames. See task for detailed explanation.
Bug: T303396
Change-Id: I6495826b4b050ea80680e0798ac6ab4497a7c09e
Since times immemorial, and for reasons lost to history, our test code
was adding an extra <div> wrapper before parsing the HTML used for
tests. This wasn't a problem, until now, because I want to add some
tests for T303396 that need to check that the *real* wrappers present
in some test cases are handled correctly.
Changes to test cases mostly remove a leading "0/" from serialized
ranges, corresponding to removing the extra wrapper.
Change-Id: Ia50e3590538c8cd274b02d2a937ba1a3fbb4ac89
The CommentController stores a list of the new comments that
triggered the reload warning. Just highlight all the comments
in this list, as we always reload to the revision we got from
the same API call.
Bug: T303261
Change-Id: I960f3cf33e25004bad6ab6df907121a87555aaf4
Phan can analyze them now and reports some issues with types.
* Add some assertions on types where we're sure that we're using an
Element or non-null, but Phan can't prove it
* Fix incorrect type hints on getFullyCoveredSiblings() and
getCoveredSiblings(), luckily it was harmless
Change-Id: I8cc12450378efa7434c4d66882378b715edd4a70
We call CommentUtils::getHeadlineNodeAndOffset() before constructing
the HeadingItem in CommentParser, so the range's startContainer
is always the headline node.
Change-Id: I2afb6ba9100e785cd91f31d82f4cea59fa8b5443
`tagName` is only defined on Element, and it returns its tag name.
`nodeName` is defined on Node, and it returns the tag name for Elements,
and a string like '#text' or '#document-fragment' for other types.
We were using both, which made it harder to reason about what types
we're dealing with.
Change-Id: I8e621e5872bdf78c84ec553cfbfcdbf0192f0589
It is friendlier for static analysis tools like Phan, which can't
infer anything from the `->nodeType === …` checks, and we were already
using it in most places.
Fix newly revealed Phan failures (and one unneeded suppression).
Change-Id: Id789f05e16a210f7ba22ca7514587c392fac0741
Added in 76289cdf73,
should no longer be needed since we switch to Parsoid's
HTML parser in 3e6ab2c4d2.
Change-Id: Ic0b7ed8089b71f2338e604f68d547759e069f0b2
