This avoids the RuntimeException in old Vector, and means
we can safely enable this on the beta cluster
Note, for any users that are in migration mode e.g. skin is
set to 'vector' and the skin version is set to 2 they will
not see a table of contents in the sidebar or article.
This won't be a problem in production provided T299104
is resolved before we enable.
Change-Id: I942a1cb933e7364600fe1af7491aca20546545e5
Server render the table of contents in a collapsed state when the total
number of headings is equal or greater than the value of
`$wgVectorTableOfContentsCollapseAtCount`. Otherwise, the table of
contents will be server rendered in its "expanded" state.
In addition:
* Revise table of contents tests to call one `assertion` per element so
that it is easier to see the exact element that may fail an assertion.
* Revise table of contents tests to call a mount function that can merge
props to allow for a more flexible set of tests.
* Revise table of contents tests by wrapping a `describe` around tests
that expect the same prop state.
* Adds typedef for table of sections props
Bug: T300973
Depends-On: Ifaee451e1903f2accd0ada2f2ed6dfa3f83037b6
Change-Id: I382200bc603b6abf757a91f14a8a55a6581969bd
From what I could tell, most instances of `toHTMLElement` or @ts-ignore could be fixed by using typeguards or using Element over HTMLElement.
Element is a looser typing than HTMLElement, but given `querySelector` returns `Element|null` and the fact that we were already inconsistently using both Element and HTMLElement in this file, I feel it was a worthwhile tradeoff
Change-Id: I3512a98fa67c13a4383b9497e8588960259b5b68
This uses the sticky header's `.mw-sticky-header-element` utility class
to conditionally offset the table of contents to the height of the
sticky header only when the sticky header is enabled.
Bug: T300077
Change-Id: Ibad97a11e708ba19acf27ca82320f7c3e5f80447
Collapses sub-sections in the new table of contents by default
(except for non-js and reduced-motion users) and expands the
sections when the top-level section link has been clicked.
Refactors the `activateSection` TableOfContents methods into separate
`activateSection` and `deactivateSection` functions.
Adds `expandSection` and `collapseSection` methods.
Adds triangle icon as a visual expand/collapsed indicator
next to all ToC section headings and are hidden via CSS based on
whether or not the section contains subsections.
Adds test for tableOfContents.
Bug: T299361
Change-Id: I36b3ae7f9f633877683bc17a9444c970d7fa7293
Move jsdoc comment closer to the methods they are describing. This also
enables better typehint support.
I36b3ae7f9f633877683bc17a9444c970d7fa7293 will handle revising tableOfContents.js.
Change-Id: Ifcac7cfd88cd3f1c0405611c880a0d101d2aed3b
Given our use of constants for tracking classes this eslint rule
is more an annoyance than helpful.
Change-Id: I37570e3e851997d058f2d93777990dddb3d04089
Rather than test for fetch, limit the code to ES6 browsers.
Depends-On: I96a03796628a74ace93579d45a582711400c09c1
Change-Id: I4ca10182491118e61e155f99c713d4cb1b4fc7f0
Given that these styles deal with the layout of the sidebar button in
the main header and don't make sense in any other context (at least
currently), I think they belong in Header.less.
Change-Id: I191b9a404c82c5a1a80f97d98fa54535fdd53944
We want the link that the user has clicked inside the TOC to be "active"
(e.g. bolded) regardless of whether the browser's scroll position
corresponds to that section. Therefore, we need to temporarily ignore
section observer until the browser has finished scrolling to the section
(if needed).
However, because the scroll event happens asyncronously after the user
clicks on a link and may not even happen at all (e.g. the user has
scrolled all the way to the bottom and clicks a section that is already
in the viewport), determining when we should resume section observer is
a bit tricky.
Because a scroll event may not even be triggered after clicking the
link, we instead allow the browser to perform a maximum number of
repaints before resuming sectionObserver. Per T297614#7687656, Firefox
wasn't consistently activating the table of contents section that the
user clicked even after waiting 2 frames. After further investigation,
it sometimes waits up to 3 frames before painting the new scroll
position so we have that as the limit.
Bug: T297614
Change-Id: If3632529f58c15348a7200258f4f5999ea0dadc4
The behavior of data loading can differ between submitting and display,
so use FauxRequest to customize the method.
Also fix the order of parameters passing to assertSame(), the first one
should be the expected one.
Change-Id: Icfa062eada75c50cd2c8bc5db2930602d80e9ae7
