* When wikipage.tableOfContents is executed, the table of contents has been
replaced so we should update the sections associated with the section
observer as the old sections no longer exist in theDOM.
* If VisualEditor repaints the page, we should update the elements associated
with the table of contents as the body-content element no longer exists in the page.
* When VisuaLEditor is active we should disable the intersection observer as
there is no table of contents to update.
Minor changes:
* Light refactor of large function in main.js
* reloadTableOfContents returns a promise and now fires a new hook
wikipage.tableOfContents.vector to signal when it is finished which
has also been requested by community members. This allows the code in main.js
to update elements at relevant point in time
* Add FIXME note (doing this would have been considerable work)
* I've added a call to mw.log.warn which would have saved me considerable
debugging time for this issue to diagnose the issue.
Bug: T316037
Bug: T316025
Change-Id: Ib42d532d4e900c01061e1c5e39c03b17f0619c46
This mostly reverts commit f5ad6fe78a but
keeps the SectionObserverProps typedef.
Instead, we will use @module introduced in
Ib68de8cd97cc1111a5a33e100e688d6832fc7e6e.
Change-Id: I7aff49a3d922889cc99bc4313a6cb416410a7a0d
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
This commits sets up the Table of Contents to bold the active section
when the section is scrolled.
Unfortunately, because our content does not have actual sections but
instead has a flat list of headings and paragraphs, we can't use
IntersectionObserver in the conventional way as it is optimized to find
intersections of elements that are *within* the viewport and the
callback will not reliably fire during certain scenarios (e.g. with fast
scrolling or when the headings are not currently within the viewport).
Furthermore, iterating through a list of elements and calling
`getBoundingClientRect()` can be expensive and can also cause
significant forced synchronous layouts that block the main thread.
The best compromise in terms of performance and function that I've found
is to use a combination of a throttled scroll event listener and
IntersectionObserver's ability to asyncronously find the
boundingClientRect of all elements off the main thread when `.observe`
is called which is the approach this patch takes. Although this is an
unorthodox way to use IntersectionObserver, performance profiles
recorded while holding the "down" arrow and scrolling for 10 seconds
with a 6x CPU throttle are comparable between master and this patch:
master: https://phabricator.wikimedia.org/F34930737
this patch: https://phabricator.wikimedia.org/F34930738
Bug: T297614
Change-Id: I4077d86a1786cc1f4a7d85b20b7cf402960940e7
