fix: catch Google Translate DOM errors

[eatyourgreens]

Monkey-patch node.removeChild and node.insertBefore to catch crashing errors generated by Google Translate. This should make projects usable in Chrome, in other languages, until the underlying bug is fixed.

See facebook/react#11538 (comment)

Staging branch URL: None at this time (external PR contributor)

• Fixes "Failed to execute 'removeChild' on 'Node'" error crashes page, likely due browser translations #7078.

Describe your changes.

Required Manual Testing

• Does the non-logged in home page render correctly?
• Does the logged in home page render correctly?
• Does the projects page render correctly?
• Can you load project home pages?
• Can you load the classification page?
• Can you submit a classification?
• Does talk load correctly?
• Can you post a talk comment?

Review Checklist

• Does it work in all major browsers: Firefox, Chrome, Edge, Safari?
• Does it work on mobile?
• Can you npm ci and app works as expected?
• If the component is in coffeescript, is it converted to ES6? Is it free of eslint errors? Is the conversion its own commit?
• Are the tests passing locally and on GitHub Actions?

Optional

• Have you replaced any ChangeListener or PromiseRenderer components with code that updates component state?
• If changes are made to the classifier, does the dev classifier still work?
• Have you resized and compressed any image you've added?
• Have you added in flow type annotations?
• Have you followed the Springer guidelines for commit messages?

[coveralls]

coverage: 56.98%. remained the same
when pulling 23068a8 on eatyourgreens:fix-google-translate-crash
into d270c1a on zooniverse:master.

[eatyourgreens]

From Dan Abramov's original comment:

Finally, there is a workaround you can use that will fix the error. It will make your app a little bit slower, so it is up to you to try it and determine whether the tradeoff is worth it. But it's equivalent to what React would have to do if we were to fix it in React — so you wouldn't have a better solution anyway.

[shaunanoordin]

(Copy-pasting our follow up from our discussion from Slack)

Update on the "Chrome's Translate feature crashes PFE" bug , post-dev standup.

• Context: the bug is caused by Chrome Translate and React not playing nice. We have a workaround (NOTE: this PR) courtesy of Jim. (NOTE: Jim gives credit to the React team.)
• The Catch: applying the patch will fix the problem for people using Translate, but may maybe perhaps impact the performance for a larger number of people. We're not sure how to measure the performance hit. 🤷
• The Plan: we've chosen to be cautious, and won't apply the workaround PR... for now.
  • We'll keep the PR open, (NOTE: this PR) so we can apply it if/when we hear more people complain and/or if Sam/Cliff hits the "Do It Anyway" executive override button.
  • If/when we apply the workaround, we'll then monitor for people reporting issues, with an option to rollback if necessary.

(Please see the Slack thread for additional comments on performance.)

[eatyourgreens]

We're not sure how to measure the performance hit. 🤷

Here's a couple of tools you can use, not just for this PR but to measure the performance of your code in general:

• https://webpagetest.org – Web Page Test is pretty much the industry standard performance tool (it even has an O'Reilly book.) Give it a public URL and run performance tests for a variety of devices and connection speeds. The tests include Lighthouse and Core Web Vitals.
• https://pagespeed.web.dev/ – Google's page speed tools. Runs Lighthouse tests and Core Web Vitals for a URL. If tracking data is available for that URL, you'll also be shown real browser performance numbers from tracked Chrome users. If tracking data isn't available for that specific URL, you'll be shown Google's user tracking data for the origin as a whole. I think these tools might also be available inside Chrome Dev Tools.

Here's a couple of example page speed tests for live Zooniverse projects:

• Planet Hunters NGTS (PFE classifier)
• Daily Minor Planet (FEM classifier)

Here are the performance scores from Page Speed Insights for both those pages. To be honest, both Zooniverse React apps are so slow that I suspect any additional slowness introduced by Dan Abramov's patch will be negligible by comparison. The DOM size is reasonably small for both, too.

App	Mobile	Desktop	JS execution (mobile)	JS execution (desktop)	DOM size
Panoptes Front End	7%	21%	8.1s	1.8s	366
Monorepo	26%	32%	11.7s	3.9s	586

Also: kind of interesting that the new classifier is significantly slower to run on both desktop and mobile. I would have expected it to be faster.

[eatyourgreens]

if/when we hear more people complain

People generally won't complain when a site/app doesn't work (because the site didn't work, so how would they get the contact info?) However, these errors should be logged to Sentry, so you can use that to estimate how often this problem comes up.

Be wary of seeing an issue as an outlier or rarity, just because you don't often hear from people about it. If possible, use analytics and logging to find out who is struggling to use your site.