Also fix a CSS selector to handle content added in multiple
'OutputPageBeforeHTML' hook calls.
Bug: T323376
Bug: T323833
Change-Id: I480d9bf544d61f0cb7bfd04cadfbf053e7e1b70e
After recent changes (I101c1e84739a2ac1f562f2f7bdc4b8f53d9f3b23 and
Ifbde590ccb6bf3203a2f664cb0d8a73b8d507b78) these methods became
basically the same.
Change-Id: Iedc201e798a5a34713296b20b97ae6cc8b991b66
ApiDiscussionToolsPageInfo and ApiDiscussionToolsCompare in direct parsoid
or VRS modes tries to fetch HTML using VisualEditor thus stashing the
HTML gotten which we don't want, we only need it for viewing in these cases.
This seems like something that was/is already happening in RESTBase. So for
APIs in DiscussionTools that need the HTML for viewing, just get it from
parser cache and not stash it.
Bug: T323357
Change-Id: I101c1e84739a2ac1f562f2f7bdc4b8f53d9f3b23
Ideally this would just not run the hook for any interface messages, but
that condition isn't obviously available.
Bug: T316175
Change-Id: Ibd354eb7a0fb7a316dcbf09e64b80f2d9b4008c8
(Also fix some related CSS that was accidentally moved in
Ie5198e902ec3fa7a7eba56cef6c6f0ef71ef7314)
Bug: T323241
Change-Id: I1fa67965a1b6b827c500a9de63f5b5295bee840d
When a comment almost exactly matches the range of an
accidental complex transclusion consisting only of
pages from the 'Template' namespace and wikitext fragments,
I think we can safely allow replying to the comment.
Even if this turns out to be incorrect in some cases,
the failure will be more graceful after the changes in T313100:
instead of potentially duplicating contents from a template,
the worst case now is that the reply will appear in the wrong
place (at the end of the transclusion).
Bug: T313093
Change-Id: Ie8da09d74a652d893fd8c3e2435ef6cb70fad64a
We wrap a `<div>` tag around the `<h2>`, and move some elements there.
The markup is inspired by and compatible with my proposal for T13555.
The "ext-discussiontools-init-section" class is moved to the `<div>`.
A small patch is needed in MobileFrontend to preserve the section
collapsing functionality: I11bff21e81046898ca63f3f432797129fa70ad88.
The following elements are now outside of `<h2>`:
* Metadata bar
* Subscribe button
* Ellipsis menu (only shown on mobile)
The following elements are sadly still inside of `<h2>`:
* Subscribe links (only shown on desktop)
* Section edit links from MediaWiki core
Trying to move them mucks up the CSS too much. I hope we can resolve
this later as a part of the work on T13555.
Depends-On: I11bff21e81046898ca63f3f432797129fa70ad88
Bug: T314714
Change-Id: I0bbdcfa02c334858737855349d7a35746de1d8f2