Makes the class more similar to PHP. The non-native
ranges exist for efficiency, but users will usually
want native ranges.
Change-Id: Ifd7dd034d2e0f3b9af050ecdab3e063df73dde5e
* Looks for heading IDs matching "h-<heading text>-%" that once
existed on the target page.
* For such IDs, finds where those items currently exist,
presumably in an archive.
Pros:
* Doesn't need to know anything about the local wiki's archiving
conventions, so can be deployed universally.
Cons:
* ID conflicts will return matches in unrelated archives, e.g.
MassMessages.
Bug: T349653
Change-Id: Ie94efd0503e9f4689d3421babe445f9f4e2b4fb7
* The :first-child pseudo-selector to suppress top border of the first
div.ext-discussiontools-init-section ends up suppressing top borders
of all these divs since they are the first child of a <section> tag
in Parsoid's HTML.
Add `.mw-parser-output >` to these selectors, so that they don't apply
when <section> wrappers are present in Parsoid's HTML.
* Re-implement the logic for suppressing top border with new selectors
that work correctly with Parsoid's <section> wrappers.
Note that one of the cases requires using the :has() selector, which
is not supported by all browsers yet. This should not be a big deal
in practice, as that case should be rare on Wikimedia projects.
* This can be reverted if T333031 decides to strip <section> tags
from Parsoid's read view HTML.
Bug: T333031
Bug: T341010
Change-Id: If513c90033e9a77c8885b3b1c937e016064cc5ba
(split off from I5ab9d3373a6911c1456c30d844b66576b278a1b5)
Bug: T13555
Depends-On: I44587461582d648b56ef0c9c7ae0c322895c69c2
Change-Id: Ia32d3b3ac0de2f17401fc1a26c1fe451f273c688
This was being overridden by a later rule that only affected reply
buttons on mobile.
Bug: T351542
Change-Id: Iad2f6b703827cccf46ad5909d11fe3912d7023d5
This was causing a misalignment on mobile pages that loaded the DT
styles but didn't have visual enhancements enabled.
Bug: T351044
Change-Id: Ib5e392943331467c3d29ee2b10d3bbe4995137d0
This requires something like an invalid timestamp, to produce a reply
link whose associated comment ID is going to not be findable.
Bug: T350633
Change-Id: Ib50c11096b9af9961b74309b60524a4b986e04aa
It does the same as before.
I think performance is not a concern here, and wasn't my motivation
either. But I hope this makes the code easier to read and to reason
with.
I added a pure unit test case (without involving an actual Language
object) to cover the previously uncovered digits feature.
Change-Id: I6a0fc86035817eabb42b55e58183ae094c052aa6
I was curious why running the CommentParserTest takes so long. I
found this is one of the bottlenecks because it's called so often,
but many link titles that are parsed as user names turn out to be
something else. This little hack speeds up the test by 15% and has
probably a similar impact in production scenarios.
Change-Id: I5a0b3a49ba5793c8a345baaa7118fed500c082b6
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
These are not widely used anywhere, but linking to an #h- heading ID
that doesn't exist should say "topic not found" rather than
"comment not found".
Change-Id: Ifd269cc72e640f36431f85c751874ca06229ba9f
Replacing legacy breakpoint variables with new Codex
design system `@max-width-breakpoint-*` tokens.
Bug: T331403
Change-Id: Ib1ff07a7692948b1fd22e9620c132133d392dab9
Saying that ctrl-enter would submit the post at a moment when it
wouldn't may be confusing to users.
Bug: T326500
Change-Id: Ib513c8a6c36a0f607cc2034fc830dbfcdf10f554
We support highlighter HeadingItem's despite saying CommentItem
in a bunch of places.
Also potentially show the "not found" notification if the URL hash
starts "h-" as well as "c-".
Change-Id: I51894902bfca405bbdec89806bb9c1d76e0b40ef
Why:
- Per T338534, we want to display the overflow menu next to topics and
comments. Supporting topic-level placement is a little more
complicated, so just go with comments for now.
What:
- Rework the is-mobile check to allow the code to run on desktop/mobile,
while excluding topic-level replacement on desktop (T342627)
Bug: T338534
Bug: T342625
Change-Id: I520c377120e16aa3a6fedcc8c39075958a942e4c
