I tried to benchmark this. It's not really a big bottleneck in this
codebase, but can still be seen. For example, the relative runtime
of the method CommentUtils::isCommentSeparator (the heaviest user of
this feature) goes down from 1.5% to 0.3%.
Depends-On: If9252a97562542e7a4bec29edcc6e8dee0fb8221
Change-Id: I6b94a2481b5c4f7983df78ee48d45c0d8a50e53b
urldecode() should be used for decoding URL query parameters,
rawurldecode() should be used for decoding URL paths.
Bug: T367977
Change-Id: I7a7b14da85fb89f612c701d2746803d830017842
It needs to only look at the end of the added comments, and ignore
whatever is going on at the beginning, since the only thing it really
cares about is a functioning "Reply" button at the end.
Bug: T363285
Change-Id: Ia337be754deda741617d1343972f3e0a21c41b05
The PHP code should never see a `<span class="mw-headline">` node
since MediaWiki change If04d72f427ec3c3730e757cbb3ade8840c09f7d3,
but we have to support it for our old integration tests (T363031).
Improve code comments to explain this and move the handling to
one place, so that it can be deleted more easily in the future.
Follow-up to 08f61b2609.
Change-Id: I5ab9d3373a6911c1456c30d844b66576b278a1b5
Mixing different binary boolean operators within an expression
without using parentheses to clarify precedence is not allowed (T358966)
Change-Id: I9e9c9531ab0fa373606b19a5865cec748a3f36ff
MediaWiki's PHPCS plugin requires documentation comments on all
methods, unless those methods are fully typed (all parameters and
return value).
It turns out that almost all of our methods are fully typed already.
Procedure:
1. Find: \*(\s*\*\s*(@param \??[\w\\]+(\|null)? &?\$\w+|@return \??[\w\\]+(\|null)?)\n)+\s*\*/
Replace with: */
This deletes type annotations, except those not representable
as PHP type hints such as union types `a|b` or typed arrays `a[]`,
or those with documentation beyond type hints, or those on
functions with any other annotations.
2. Find: /\*\*/\n\s*
Replace with nothing
This deletes the remaining comments on methods that had no prose
documentation.
3. Undo all changes that PHPCS complains about (those comments
were not redundant)
4. Review the diff carefully, these regexps are imprecise :)
Change-Id: Ic82e8b23f2996f44951208dbd9cfb4c8e0738dac
There's now a different rule for the same thing in
mediawiki/mediawiki-codesniffer v43.0.0. Also document the reason for
the override. Follow-up to 8b00546749.
Change-Id: I392ee10639ffda6de55b091555e8c3cadd2af485
In this case, the generated regexp would match the '/local' part in
the generated URL. Prefixing 'https://local' is no longer necessary
since 10899af666.
Add tests for this, and some tests to cover T261711 as well.
Bug: T358321
Change-Id: Idf54deba13f30b799b7b8d17de1897bc90f95701
We already supported plain headings without the 'mw-headline'
wrappers, but now we need to parse the 'id' from a different
attribute.
Needed-By: If04d72f427ec3c3730e757cbb3ade8840c09f7d3
Bug: T357723
Change-Id: If85f89c40834618f23dc0ace2e599efb3b6d5ed4
I was curious why running some of the PHPUnit tests in this code base
takes so long. While I could not spot an obvious bottleneck I found
a lot of code that is extremely hot, e.g. called a hundred thousand
times. A few obvious optimizations are possible in this code, e.g.
not calling the surprisingly expensive DOMCompat::getClassList
multiple times.
Change-Id: If22bbc1aedd2c36db1ab2343de5737009050b7bb
MediaWiki's PHPCS plugin requires documentation comments on all
properties, unless those properties are typed.
This has potential to introduce bugs – in particular, because typed
properties without a default value will throw an exception if their
value is accessed before it's defined, while previously they defaulted
to null. I fixed this when I found it (making them nullable and null
by default), but I may have missed some cases.
Change-Id: If5b1f4d542ce3e1b69327ee4283f7c3e133a62a0
Since 92f5cfd8 we support "mw-notalk" to suppressing comment detection
in pages or sections.
Until now, it only worked when the comment timestamp was surrounded by
a marked element. However, when a marked element was directly adjacent
to a comment, it would sometimes become a part of the comment range.
This can no longer happen now.
Existing use cases for this were the {{outdent}} and {{tracked}}
templates, which we handle specially since 50ad5bb2 and ddd391b6.
It's a bit ugly to hardcode specific templates like that, and this
provides a better solution for the future. The added test case
displays some other potential uses.
Bug: T324132
Change-Id: I7ffd299ef5957b35da8d01f9a0ed5a7a9a78be83
Also merge setMwGlobals() calls because they are really expensive.
Also utilize the more readable str_contains() and related.
Change-Id: Iebde6aa17c2e366f0c0a98fe13a454f6a06c299b
This code was unnecessarily copied from VE. It's not needed for
anything in this extension, and it causes the headings to be treated
as modified by selser, which in turn causes dirty diffs.
Bug: T328268
Change-Id: Ibdbed430f2ff28d0ea2e67644075c1621d9fae53
* Detect comment separators at the end of comments too
* Consider TemplateStyles associated with ignored templates
This unexpectedly improves a lot of cases other than T313097 too,
mostly where <br> or {{outdent}} was used within a paragraph:
splitting comments that were previously jumbled together, or restoring
content that was previously ignored for apps / notifications.
Bug: T313097
Change-Id: I9b2ef6b760f2ffd97141ad7000f70919aeab7803
This improves the behavior when replying to these comments
and the message snippets shown in notifications.
Bug: T313097
Change-Id: Ia10400472c9e999fa526c7437a03b72461c37b74
Othercontent would often contain the opening tag of the next heading /
section. By looking for the closest node with a previousSibling we can
more-reliably escape the heading.
Also, only add the initial placeholder if there's content before the
first heading. We do this by testing for any siblings before the
startContainer of the first heading -- if there are any, assume this
means there's some sort of content. (This can still result in a
placeholder with `othercontent:""` if there's only whitespace before
the first heading.)
Bug: T313850
Change-Id: I080205b74413c46d3cf3442e79276145aaa9439c
Rename ThreadItem to ContentThreadItem, then create a new ThreadItem
interface containing only the methods that we'll be able to implement
using only the persistently stored data (no parsing), then create a
DatabaseThreadItem. Do the same for CommentItem and HeadingItem.
ThreadItemSet gets a similar treatment, but it's basically only for
Phan's type checking. (This is sad.)
Change-Id: I1633049befe8ec169753b82eb876459af1f63fe8
While in many cases the class will never be sub-classed, it's easier
just to always use static:: and not worry about predicting which
classes might have problems in the future.
Change-Id: I23072a1701b5acf62bb3379a877de97627d8fcf3
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
Also fix a bug where headings would be ignored while checking for
comment frames. See task for detailed explanation.
Bug: T303396
Change-Id: I6495826b4b050ea80680e0798ac6ab4497a7c09e
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
`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
Also special-case thumbnail wrappers generated by
MediaTransformOutput::linkWrap, for compatibility with
TimedMediaHandler.
Bug: T301427
Bug: T302296
Change-Id: I7f48d8b2261507c5a33526c54109f5187d062ed3
Previously, we required a signature at the end of the comment.
This was a pretty rough heuristic that did not correctly handle
many comments that we would consider entirely properly signed
in CommentParser (e.g. comments wrapped in formatting like
<small>…</small>, comments with a post-scriptum or in parentheses,
or comments generated by various templates).
Now we process the user input using the same code that adds reply
links, and only add a signature when we detect that there really
isn't a signature (including template-generated), or if the signature
is in the wrong place and would result in the reply link showing up
in the wrong place as well (not at the end of the comment).
Bug: T278442
Bug: T268558
Bug: T278355
Bug: T291421
Bug: T282983
Change-Id: I46b6110af328ebdf93b7dfc2bd941e04391a1599
Also, in ThreadItem::getSinglePageTransclusionTitle(), we don't need
this terribly complicated method.
Change-Id: If02c09aaa2f4dd66b2bc253a1edec4ea107564ee
