Homepage crashes Firefox

[Noah]

The homepage seems to make Firefox crash, giving the "A webpage is slowing your browser down" error message

[Chris Zhou]

I think there are some performance issues that can result in responsive layout (especially on the height) for specific cloud layouts. I updated the home page to use a fixed height layout and reduced the interval. I don't think these are the real underlying reasons for the issue though, but hope it helps. Thanks for reporting and let me know if the issue still persists or if you are able to isolate the root cause!

[David Beitey]

The issue is that D3/wordcloud triggers a data access request for HTML5 canvas image data, seen when privacy.resistFingerprinting in Firefox is enabled (may come up in other circumstances by default now too). The wordcloud code needs to read data in order to position words on the canvas. In your screenshot @eeue56, there's an icon on the address bar for this, the picture icon:

Clicking the icon and then clicking 'Allow Data Access' will mean this code can successfully place words and you should see your word clouds start rendering okay.

The 'web page slowing down your browser' warning is because the homepage keeps re-rendering the cloud, thus continually trying to recompute where words are being placed each time. Being unable to read the canvas data means words can't be placed and so on, stacking more and more rendered every time the timer runs: https://github.com/chrisrzhou/react-wordcloud/blob/main/docs/hero.tsx#L23-L26

So perhaps @chrisrzhou the homagepage could more gracefully handle this situation of having no permission on the homepage (e.g. don't keep trying to re-render if the first one failed or if a test access to canvas data isn't [yet] allowed).

The line of code being blocked from accessing canvas data is https://github.com/chrisrzhou/react-wordcloud/blob/main/src/optimized-d3-cloud.js#L130 though I imagine all similar lines accessing canvas data would cause the same issue if reached. I haven't gone and tested how Firefox handles failed access, whether it throws an exception that can be caught etc, but if it does, then the code in optimized-d3-cloud.js could handle it and gracefully abort continually trying to place words. The code does eventually give up after MAX_LAYOUT_ATTEMPTS, but it could be caught on the first failure to access canvas data.

[Chris Zhou]

@davidjb, just confirmed the issue by setting privacy.resistFingerprinting to true in Firefox. This affects all wordcloud instances, not just the homepage as you mentioned. Should the check be handled within the library or should we ask users to handle this on their end? If the latter is a better design choice for the library, then I can probably just update the documentation site to handle this.

I'm not sure how other canvas-based libraries will approach this problem (if they will handle this internally or have users deal with the problem).

[Chris Zhou]

Did a bit of digging and the issue is accessing canvas data in general and isn't isolated in just optimized-d3-cloud. The source code of d3-cloud will also affect this.

My rough plan is to:

• Keep the source code the way it is since this problem is more generic to data access with canvas itself.
• Handle the homepage and doc examples more gracefully (after some retries, I'll render a info message to ask users to grant allow data access for canvas data).
• Make a mention in faq.mdx about this bug.

I need to find out how to obtain this event in a general way since it maybe browser specific. If anyone has ideas or knowledge in this area, please let me know!

[Chris Zhou]

Found a solution to do this that is compatible on most browsers: https://github.com/chrisrzhou/react-wordcloud/blob/main/docs/react-wordcloud.tsx#L12-L15

Since the docs use a wrapped version of the source code, this was a good entry point to update it and warn the users. The slight drawback is it won't trigger the image icon in the URL bar as a shortcut to change the browser configuration, but we'll going to offload that responsibility for users in their custom browsers to address.

Added an FAQ about it since this question was raised here and I expect more people to come across it:
https://github.com/chrisrzhou/react-wordcloud/blob/main/docs/faq.mdx#browser-based

Thanks @davidjb for digging into it, and let me know if this solution works. I don't think adding logic to the source code makes sense since that is accounting for user/browser configuration.

[David Beitey]

@chrisrzhou Nice workaround with the performance API. I was wondering that if you were to trigger the canvas access warning from this code with a very basic trigger, then you'd get the best of both worlds -- the visual <p> tag is a helpful indicator to the user and then the image icon will prompt and facilitate the user allowing access whilst avoiding a browser crash.