Hi everyone,I’m the lead architect for Core Blast Solutions (coreblastsolutions.com), where we manufacture industrial abrasive blasting media and nozzles. Our e-commerce B2B platform runs on WordPress (Astra Pro + WooCommerce) with custom vanilla JS modules.Recently, a few of our European engineering clients reported that our interactive Abrasive Media & Nozzle Consumption Calculator on product pages fails to render or update pricing matrices when using Opera One (tested on 139.0.6053.22, Windows 11 64-bit), even though it works flawlessly in Google Chrome, Brave (Shields down), and Firefox.How the Feature Works (The Stack):On our WooCommerce product templates (for Steel Grit, Glass Beads, Aluminium Oxide, and Boron Carbide nozzles), we inject an interactive spec calculator via an Astra hook.When a user adjusts the mesh size slider or nozzle PSI input, our script dispatches an asynchronous fetch() POST request to a custom WordPress REST endpoint (/wp-json/cbs-calc/v1/telemetry-quote) and triggers a standard WooCommerce fragment refresh (/?wc-ajax=get_refreshed_fragments).The response dynamically updates the technical spec table and injects updated Product / Offer JSON-LD structured schema into the <head>.The Bug in Opera One:In Chrome (same Chromium Blink engine), the fetch() resolves in ~45ms with HTTP 200, and the DOM updates.In Opera One, the initial preflight Options / Post request to /wp-json/cbs-calc/v1/telemetry-quote immediately aborts in the DevTools Network tab with (failed) net::ERR_BLOCKED_BY_CLIENT (Initiator: cbs-media-tracker.min.js), and the calculator container stays stuck on the skeleton loader with Uncaught (in promise) TypeError: Failed to fetch.Even more bizarre: if the user has Opera Aria sidebar or Tab Islands active with Opera Tracker Blocker enabled, Opera’s cosmetic filter injects an inline display: none !important; style directly onto our <div id="cbs-abrasive-advisory-box"> wrapper! What I discovered while debugging in Opera DevTools:It turns out two things are colliding only in Opera:Because we named our JS bundle cbs-media-tracker.min.js (meant for tracking abrasive media flow rates, not user analytics!) and the REST route includes the word /telemetry-quote, Opera’s built-in Block Trackers heuristic engine flags our first-party script as an analytics beacon and kills the XHR/Fetch pipeline.Our container ID #cbs-abrasive-advisory-box triggers a false-positive match against -ad- / advisory in Opera’s native cosmetic filtering rules when Block Ads is enabled.My Questions for the Opera Web Compat / Dev Team:Why does Opera’s native Tracker Blocker block same-origin (same-site) first-party REST API POST requests to /wp-json/ just because the filename/endpoint contains strings like tracker or telemetry, whereas uBlock Origin in Chrome ignores first-party functional scripts?Aside from refactoring our WordPress plugin handles and renaming our DOM IDs on coreblastsolutions.com, is there a way to declare a first-party exception header or inspect exactly which internal Opera filter list rule (opera://settings/adBlockerLists) triggered the ERR_BLOCKED_BY_CLIENT abort in the Opera console?