Bug - 'wb-auto-' error in the console since the Share This was removed starting at version v15.3.0

[canasa21]

Describe the bug

We've noticed that during our testing, and this only applies while navigating from the breadcrumb trail, a message in the console begins to appear as follows. I've scanned our entire site of 5000 plus files and 'wb-auto' is not being used.

This error message starts to appear from v.15.3.0 and up - with the removal of the Share This code. v15.2.2 is the last version that worked for us. We've tested with Edge and Chrome and the message appears in both.

We are currently on v.14.6.0 and I tested all versions including the latest.

Error
wb.getId: ID 'wb-auto-6' isn't supposed to be hardcoded in the page. Please remove it or change its prefix to something different than 'wb-auto-'

(anonymous) @ wet-boew.min.js:8
getId @ wet-boew.min.js:8
(anonymous) @ theme.min.js:7
(anonymous) @ theme.min.js:7

Update

The 'wb-auto-8' is accompanying the GCWeb menu.

To Reproduce

Steps to reproduce the behaviour:

1. Requires that v.15.3.0 and above it part of your solution
2. Go to home page
3. Inspect and open the console
4. Navigate to a deeper level in the site
5. Use the breadcrumbs to make your way back to the home page
6. Observe the console for any errors

Current behaviour

When navigating the site using the breadcrumbs the error begins to display in the console.

Expected behaviour

Any version before 15.3.0 does not generate this error.

Screenshots and/or logs

Desktop (please complete the following information):

• OS: Windows 11 Enterprise
• Browser: Chrome
• Version: 130.0.6723.70
• Browser: Edge
• Version: 130.0.2849.56

Additional context

We were able to generate this error from our localhost and our development server (Azure app service/Windows.NET).

[EricDunsworth]

The WET PR that introduced that console error is wet-boew/wet-boew#9776.

As for what's going on...

• The logic triggering the console error basically checks if any wb-auto-* IDs already exist in the DOM the very first time WET's .getId() method is called. If it finds anything, it complains and tries recovering.
  • The point is to avoid ID conflicts and discourage anyone from deliberately hardcoding those IDs into static pages.
• I was unable to reproduce by following the reproduction steps on GCWeb and Canada.ca (both are currently using GCWeb 15.8.0 - which in turn uses WET 4.0.82 as a dependency).
• Based on the OP's screenshot, this issue seems to affect CNSC's site (but can't be seen in action since it's currently on GCWeb 15.2.2 + WET 4.0.81):
  • Looks like that site uses WET + Gatsby/React.js.
  • I suspect what's happening is that when navigating between pages, React.js is keeping certain parts of the previous page's DOM "as-is" and WET's JavaScript is getting reloaded from scratch. End result is that WET thinks it's being loaded for the first time, detects old auto IDs in the "polluted" DOM carried-over from a previous page, then freaks out (as it should).
  • AFAIK WET/GCWeb aren't officially compatible with React.js. It's previously been discussed in wet-toolkit integration with React Redux  wet-boew#8150.
  • IMO this isn't a WET bug. The logic is detecting and trying to recover from an issue that has always existed. Although the console error might be overkill in this case...

@Garneauma @duboisp Thoughts?

Maybe there'd be value in making the console error only appear if React.js doesn't exist in the page? As for the recovery logic, IMO it should always run no matter what.