The problem was fixed in 15cb419f56,
then the comment restored in 633cc9a7b3
(looks like a rebase mistake).
Change-Id: Ic31ea0bf88480cff02f40701f1317f35c1c6e891
* Use a slightly different color
* Use 'mix-blend-mode: multiply' when available to avoid fading
the text color
* Add fade-in animation and make fade-out animation slower
Bug: T268994
Change-Id: I210ed4fd55c3dc184d13daf915fa93bee3699ad5
We've recently decided that we want to "extend" comments until
the end of the paragraph (e36dc8e78a,
d0ae6c4e44).
However, we still had this special case that did the opposite: it
ensured that if a comment ended in the middle of a text node, the
comment would not be extended to the end of the node. Remove it.
Note the change in the test file signatures-funny-formattedreply.html,
which actually covered this case specifically.
Change-Id: Id1384bb0c6e1a5f0c70f55efcb4caa240f230f07
The end marker is skipped forward until an open or close
block tag is reached. In tree traversal terms this means
moving either to the next sibling, or the parent (to skip
over close tags).
Bug: T256033
Change-Id: Iaa2c588698790d576ac4f9ecc126f58a082ef6b3
The general rule is that comments start after their preceding
thread item, but when that is a heading we should skip past
the entire <h[1-6]> node to avoid making section edit links
part of the first comment.
Bug: T267988
Change-Id: Ia7f1b27e0a69a9aab7c7da743bf8549479304096
Even though the field is supposed to resize itself to match the text
inside, vertical scrollbar would sometimes appear when the user has
zoomed in. Some calculation probably handles fractions of pixels
incorrectly (might be a bug in OOUI or a browser bug).
Since this field has no limit on max rows, we can just hide the
scrollbar. This can't be fixed in OOUI itself, since its autosize text
fields usually have a limit to how tall they are allowed to grow
before a scrollbar is used.
Bug: T267609
Change-Id: Id36ed417c4678e469a6c05715404e330064c2017
Matches what we end up posting. Leave context-aware code
commented out as this issue is not settled yet.
Change-Id: I7360e53d5d7823b2b52318005459212a21a6edc2
Ideally the edit autosummary would be generated in the same
way as in the old wikitext editor: from the wikitext of the
heading. But on the JS side, we don't have access to the
wikitext, or to the PHP method that generates autosummaries.
This might seem crazy at first, but ultimately the point of
the autosummaries is to link to the section heading by its
'id' attribute, so it is perfectly reliable.
Doing it this way depends on $wgFragmentMode being set to
[ 'html5', 'legacy' ] or [ 'html5' ], otherwise the escaped IDs
are super garbled (particularly in non-Latin-alphabet languages)
and can't be unescaped reliably. Conveniently, we already
require that since 9ee0fd69f5.
Bug: T264561
Bug: T266725
Change-Id: I7d35098d672d0edb50d49e22de1686d5cc83b60e
After recent changes allowing ThreadItems to have IDs, they can now
also have warnings about duplicate IDs.
Bug: T267035
Change-Id: If3edfe34e6e29741e29fac8946a3c88badc4ab7f
