"Failed to execute 'removeChild' on 'Node'" error crashes page, likely due browser translations

[shaunanoordin]

Browser-Specific(?) Bug

Users have been reporting of an odd Failed to execute 'removeChild' on 'Node' error that crashes on certain PFE pages (Talk pages, project home pages)

• We seem to be able to replicate this error to an extent using Chrome's Translate feature
• Reports seem to anecdotally indicate that people who reported the issue may be non-English speakers, so this may reinforce the above assumption.
• Caveat: I'm not 100% sure if there aren't other triggers.

Screen.Recording.2024-04-17.at.15.33.12.mov

Replication

Replicated with macOS + Chrome 123. I haven't fully tested with other browsers, but Jim has indicated no issues with Firefox.

• In a Chrome incognito window, open a PFE project's home page, e.g. https://www.zooniverse.org/projects/ollibruuh/frog-find
• In Chrome's menu, use the Translate option. e.g. translate page to Japanese. This should translate the page fine.
• Click on "About" to navigate to the About page. Navigation should work well, and page should remain translated.
• Click on the project title again to navigate back to the home page.
• ❗ Instead of navigating back to the home page and seeing it translated, the page crashes and the error appears.

Notes:

• The replication steps above are the most consistent I've been able to trigger this bug. I may have been able to trigger it in other conditions by accident, but I'm not sure.
• ❔ I'm not sure why I've only been able to replicate this only on the project home page.
• ⚠️ I haven't been able to trigger the bug on Talk pages, which is where some of our most recent reports have been coming from.
• Whether or not you're signed in seems irrelevant.

History

• Jim discusses seeing this issue in Disk Detective previously. [Slack]
  • In Sep 2023, errors were logged on Sentry. [Slack]
  • In Aug 2023, researcher ssilverberg of Disk Detective posts on Talk informing volunteers that using browser translations can cause an error. [Talk]
  • In Jul 2023, Delilah supports a volunteer who encounters the issue on Disk Detective, and confirms it's related to Chrome translations. [Freshdesk]
• On Apr 16, a volunteer reports the issue occurring on Talk specifically. (i.e. "when I click on a discussion thread in Notes ") [Talk]

Status

Investigation has confirmed that issue exists. ⚠️ Root cause has not yet been determined. ⚠️ Full extent of bug has not yet been determined.

I'm estimating moderate-to-high impact to volunteers - the problem may "only" be affecting a small subset of users (since we're not seeing multiple reports yet), but it will make the platform nigh unusable to them.

Workaround:

• Ask affected volunteers to use a project's built-in Zooniverse translations, if possible. (Limitation: volunteer's language may not be available.)
• Ask affected volunteers to use a different browser, e.g. Firefox. (Limitation: I haven't fully tested if it's possible to crash with FF.)
• Ask affected volunteers to disable Chrome translations. (Limitation: now the volunteers can't understand the website!)

Awaiting prioritisation of dev effort.

[goplayoutside3]

I came across a React discussion about this bug related to Google Translate (likely used in Chrome's Translate feature). There could be an element on the PFE project pages to sleuth as the root cause, but because we have a couple suggested solutions to communicate to volunteers, and PFE project pages are being deprecated as soon as possible, dev work to solve this bug is pretty low priority. We'll chat in FE standup this week about it too.

[eatyourgreens]

There's a workaround, via that React discussion, which sends the errors to the console (rather than crashing the page.)

[eatyourgreens]

I opened #7096 with Dan Abramov's patch for node.removeChild and node.insertBefore. It seems to fix the issue when I try it out locally.

[eatyourgreens]

Insightful comment from the Chrome team:
https://issues.chromium.org/issues/41407169#comment10

Even if a website owner wanted to give full and exclusive control of the DOM to a VDOM library, it's not practical if you also have end-users with DOM-modifying chrome extensions (ie. Grammarly, password managers, etc) or if you have users with browsers that modify the DOM (ie. Chrome's built-in translation functionality). There's a large ecosystem dependent on DOM manipulation - that ecosystem is an unintended victim of the adoption of VDOM frameworks. I have nothing against React or VDOM (I personally use and like them), but entertaining the idea of changing chromium in response to compatibility issues that arise with React is setting a curious precident.

[eatyourgreens]

One other thought: these errors should be logged to Sentry, which will give you an idea of how frequently these crashes occur.