[Kanti]

Follow-up to #161 and #162, before the next release.

Problem

Since #161, the spotlight holes only follow the scrolling for sticky and fixed targets and for targets in scroll containers. A class or style change of an ancestor of the targets only recomputed the holes when it started or stopped this. Targets that a script moves while scrolling kept their old holes, and the overlay covered them:

• a parallax effect that sets a transform on a section while scrolling,
• a reveal effect that removes a class with an offset from a section once it is scrolled into view.

1.10.4 recomputed all holes on every scroll event, so these targets stayed clickable there. #144 is not released yet, so this would be a regression in the next release.

Implemented behavior

• A class or style change of an ancestor of the targets recomputes the holes, at most once per frame, and still checks whether the holes have to follow the scrolling.
• Pages whose scripts do not change the ancestors of the targets still run no code while scrolling. Pages whose scripts do, recompute the holes per frame, as 1.10.4 did on every page.
• Not covered, as in 1.10.4: elements that keep moving after the last change, e.g. through a CSS transition of a reveal effect, and CSS scroll-driven animations.

Tests

• spotlight-overlay.test.js (browser):
  • A script that moves the section of the target by a style while scrolling: the target stays clickable, the element next to it stays blocked. Fails without the fix, passes with the spotlight of 1.10.4.
  • The same with a class that a script removes while scrolling. Fails without the fix, passes with the spotlight of 1.10.4.
• The test for static targets (no getBoundingClientRect call while scrolling) and all other spotlight tests stay green.
• npm run test: 101 passing, npm run lint