swift-waddling-beacon.md

Plan: Diagnose "x/y scroll options discarded" warning attributed to error-tracking.js:31

Context

A customer reports console noise on their site:

error-tracking.js?ver=1.14.2:31 The following options are discarded due to invalidity:
{ "x": "scroll", "y": "scroll" }

They (correctly) note that no code in our error-tracking.js calls scrollTo/scroll with those options, and that the file at their CDN URL doesn't contain such code either. ChatGPT mistakenly concluded our script was the caller because the browser attributes the warning to line 31 of our file.

Root cause

Line 31 of assets/js/error-tracking.js is:

originalWarn.apply(console, args);

This is inside our console.warn override (lines 25–39). The flow is:

1. Some other script on the customer's page (theme, page builder, smooth-scroll plugin, third‑party widget) calls window.scrollTo({ x: "scroll", y: "scroll", ... }) or a sibling API. The browser's CSSOM-View spec says invalid ScrollToOptions produce a console warning ("The following options are discarded due to invalidity: …").
2. The browser issues that warning via console.warn(...).
3. Our wrapper at error-tracking.js:25 intercepts the call and re-emits it through originalWarn.apply(console, args) at line 31.
4. Because we relay through apply, the browser's "source location" for the printed message is our apply call, not the original caller. That's why every console.warn on the page looks like it came from error-tracking.js:31.

So:

• The warning itself is real and is not from our plugin — it's from a third-party script doing an invalid scrollTo.
• Our console.warn override masks the true source, which is why the customer (and ChatGPT) blamed us.
• As a side effect, the same warning is being forwarded to the FEN backend as a console_warn event (see error-tracking.js:33-38) and will appear in their FEN dashboard / notifications until rate‑limited.

What to tell the customer

Short version: line 31 is the spot in our wrapper where we re-emit warnings to the browser console. The browser then labels the printed warning with that line. The actual call that produced the bad {x:"scroll", y:"scroll"} is coming from another script on the page — most often a theme/page-builder smooth‑scroll feature or a "back to top" plugin.

To find the real culprit, in Chrome DevTools:

1. Open Console → click the gear/settings → enable "Log XMLHttpRequests" is not needed; instead expand the warning row.
2. The collapsed stack frame below error-tracking.js:31 is the real caller. Click it to jump to the originating script.
3. Or temporarily deactivate Fatal Error Notify Pro and reload — the warning will reappear attributed to its true source.

Common culprits we've seen produce this exact message:

• Elementor / Bricks / Divi smooth-scroll handlers
• "Scroll to top" / scroll-snapping plugins
• Older versions of Lenis / SmoothScroll / locomotive-scroll wrappers
• Theme custom JS passing CSS keywords ("scroll", "smooth") where pixel offsets are expected

Optional code-level follow-ups (not required to answer the customer)

If we want to reduce confusion / noise for everyone, two cheap improvements are worth considering:

1. Suppress known browser-emitted CSSOM noise from backend forwarding. In reportError (or before the originalWarn.apply call), pattern-match args[0] against /options are discarded due to invalidity/i and skip the fetch to fen_js_error. The warning still prints in the user's console (so the third party can be diagnosed) but doesn't spam the FEN dashboard.

2. Stop masking call sites for console output. Replace the override pattern with a Function.prototype.bind trick so the browser keeps the original caller's line number in the printed warning:

   const bound = originalWarn.bind(console);
   console.warn = function (...args) {
     // do side-effect (reportError) here
     bound(...args); // <-- still shows original caller in DevTools
   };

   Note: this preserves the call site for the printed warning but the synthetic Error().stack we capture for backend reporting will still start inside the override. That's fine — DevTools is where the customer is looking.

Neither change is needed to resolve the support ticket; they would just prevent future tickets of the same shape.

Files referenced

• assets/js/error-tracking.js — the override that's being misattributed; lines 25–39 are the console.warn wrapper, line 31 is the originalWarn.apply call DevTools points to.

Verification

This is a diagnostic answer, not a code change. If the optional follow-ups above are pursued:

• For (1): trigger a console.warn("The following options are discarded due to invalidity:", { x: "scroll" }) from DevTools, confirm it prints to the console but no fen_js_error AJAX call fires (Network tab filter fen_js_error).
• For (2): same trigger from a separate .js file; confirm the printed warning's source link in DevTools points to that file/line, not to error-tracking.js.