v3 site has hydration issues on Ubuntu #9379
Comments
johnnyreilly
added
bug
|
I don't see any of those hydration errors on my side 
Tried on Chrome, Firefox, Safari, no issue found. Maybe it's related to a local browser extension or something on your computer? I'm surprised Lighthouse reports it though. |
Josh-Cena
changed the title
Josh-Cena
changed the title
|
Lighthouse isn't running on my machine - it's on GitHub actions. So it's not a "my machine" only issue. It was actually the lighthouse report that I first noticed - then I thought I'd have a look on my own machine and found it there too. I run Ubuntu locally - but I assume the OS isn't necessarily relevant? |
|
BTW when testing, are you opening devtools before navigating? I didn't see them locally until I opened devtools prior to entering the URL in the browser. Also, it only seems to be the blog section that's affected |
|
Interesting - cracked open my work computer (Mac OS) and there's no issue there: 
Also I took a look at the Lighthouse GitHub Action; it runs on Ubuntu also: https://github.com/treosh/lighthouse-ci-action/blob/7f5e1fde07d17cbb1c47873c81441f53c0f72fcf/.github/workflows/main.yml#L5 It looks like this might be an Ubuntu / Linux specific issue. (I haven't tested on Windows - don't know if it surfaces there as well) |
slorber
added
status: needs more information
|
I don't know but that seems hard to reproduce currently 😅 If you are able to reproduce it locally, that would be interesting to compare the DOM html you get with/without JS, and see how they differ. I have been careful to fix all the hydrations issues we had for v3. Those issues existed before in v2 (but silently ignored). They are now logged to the console due to a new React 18 |
|
I can reproduce locally super easily on my home Ubuntu machine. My guess is any Ubuntu machine would do the job. So you'd like the originally served HTML and what the DOM html looks like after it starts? Is there a best way to surface the DOM html? Devtools and copy outerhtml? |
|
As a first test, I tried comparing the supposedly working hydration on my Mac (no errors) and found that non-hydrated and hydrated already look pretty different. But that's appears to be fine. How did you manage to fix the existing hydration issues @slorber? Doesn't look like there's much to go on looking at facebook/react#26224 |
|
By the looks of it, there's 2 parameters sent to onRecoverableError: (
error: mixed,
errorInfo: {digest?: ?string, componentStack?: ?string},
) => void,I wonder if we could expose that extra information here: docusaurus/packages/docusaurus/src/client/clientEntry.tsx Lines 40 to 42 in 35441b3 So we've got more to go on? The error itself doesn't provide any information about where the issue comes from. Essentially I'm wondering if we can |
|
I've raised a mini PR to add the |
Unfortunately I don't have one 😅 Afaik our github actions use ubuntu. I was thinking of upgrading my Argos/Playwright visual tests to also ensure there's no console error on all pages of the site and catch such errors, will see how to do that.
I guess you can use the browser with/without JS enabled, and use innerHTML or outerHTML after applying a html formatter/normalizer like Prettier (otherwise it would be hard to compare.
Not surprised, differences are expected because we do some updates just after hydrating. What would be interesting to check is if there are blog-specific changes.
Oh sorry, totally forgot about this but I actually added a FYI there are some reports that I only get in |
|
I'm seeing the issue above - this is the stack trace: |
|
Yes I also have it in dev mode, on all pages (not just blog pages). As I said above, after inspecting the code I'm unable to troubleshoot this navbar item error that only happens in dev, and not in prod. I'm not sure it is related to your problem (only affecting the blog pages). |
removing navbar items has revealed a similar issue in the blog section! The issue here is coming from a common pattern in the codebase; something passing <Comp
className={clsx(
{
navbar__item: !mobile && !isDropdownItem,
'menu__list-item': mobile,
},
className,
)}
dangerouslySetInnerHTML={{__html: value}}
/><BlogPostItemContainer className={clsx(containerClassName, className)}>
Is it possible that the issue here is happening in prod and that the issue is the string of |
|
With the new
Not actually that helpful. {
"componentStack": "\n at div\n at G (http://localhost:3000/assets/js/main.78700692.js:2:624664)\n at Bt (http://localhost:3000/assets/js/main.78700692.js:2:661953)\n at nav\n at qt (http://localhost:3000/assets/js/main.78700692.js:2:663366)\n at sn\n at q (http://localhost:3000/assets/js/main.78700692.js:2:623699)\n at p (http://localhost:3000/assets/js/main.78700692.js:2:264647)\n at r (http://localhost:3000/assets/js/main.78700692.js:2:264973)\n at http://localhost:3000/assets/js/main.78700692.js:2:672280\n at g (http://localhost:3000/assets/js/main.78700692.js:2:275178)\n at b (http://localhost:3000/assets/js/main.78700692.js:2:275363)\n at y (http://localhost:3000/assets/js/main.78700692.js:2:262590)\n at v (http://localhost:3000/assets/js/main.78700692.js:2:262676)\n at l (http://localhost:3000/assets/js/main.78700692.js:2:277407)\n at b (http://localhost:3000/assets/js/main.78700692.js:2:258340)\n at f (http://localhost:3000/assets/js/main.78700692.js:2:259271)\n at http://localhost:3000/assets/js/main.78700692.js:2:276403\n at En (http://localhost:3000/assets/js/main.78700692.js:2:672394)\n at Nn (http://localhost:3000/assets/js/main.78700692.js:2:673299)\n at Ln\n at v (http://localhost:3000/assets/js/ccc49370.aa459f07.js:1:21579)\n at g (http://localhost:3000/assets/js/ccc49370.aa459f07.js:1:33004)\n at g (http://localhost:3000/assets/js/main.78700692.js:2:275178)\n at l (http://localhost:3000/assets/js/ccc49370.aa459f07.js:1:59429)\n at h (http://localhost:3000/assets/js/ccc49370.aa459f07.js:1:33429)\n at c (http://localhost:3000/assets/js/main.78700692.js:2:373197)\n at n (http://localhost:3000/assets/js/main.78700692.js:2:208520)\n at t (http://localhost:3000/assets/js/main.78700692.js:2:218284)\n at t (http://localhost:3000/assets/js/main.78700692.js:2:219232)\n at t (http://localhost:3000/assets/js/main.78700692.js:2:218284)\n at M (http://localhost:3000/assets/js/main.78700692.js:2:288684)\n at z (http://localhost:3000/assets/js/main.78700692.js:2:290015)\n at g (http://localhost:3000/assets/js/main.78700692.js:2:285165)\n at i (http://localhost:3000/assets/js/main.78700692.js:2:284800)\n at p (http://localhost:3000/assets/js/main.78700692.js:2:363422)\n at b (http://localhost:3000/assets/js/main.78700692.js:2:365297)\n at Q (http://localhost:3000/assets/js/main.78700692.js:2:292784)\n at t (http://localhost:3000/assets/js/main.78700692.js:2:216498)\n at t (http://localhost:3000/assets/js/main.78700692.js:2:211808)\n at t (http://localhost:3000/assets/js/main.78700692.js:2:199606)",
"digest": null
} |
As far as I remember, I tried to debug those during the React 18 update and still got errors in dev even after hardcoding a static value for the className. I concluded it might be a React bug. Are you seeing a mismatch in practice, or is this only your supposition that there must be one? If you see a mismatch, please give me your exact navbar item definition, and what's the JSX/className on server vs client. In any case it's surprising if we all get different behaviors, and even more surprising if some hydration errors are logged in We also had this clsx edge case, not sure it's related but in case: #9098 |
|
I just tried again locally on the Using the current code, I couldn't see anything that produces a mismatch (nothing reads from browser APIs), and by logging the className I didn't see any mismatch at runtime either. This one produces an hydration error, but only in dev: <Comp className="" dangerouslySetInnerHTML={{__html: ''}} />However this one doesn't produce an hydration error, in both dev/prod: <Comp className="some-class" dangerouslySetInnerHTML={{__html: ''}} />This really looks like a React bug to me 😅 it seems to only appear when we use |
I'm not sure - I'm doing a |
|
the frusting thing is that the issue in the blogs section is still there when I do a standard |
For me console logs are still displayed correctly 🤔 but you can try to disable locally the
Yes, this is frustrating and I still have no idea how to fix that, or if it's even a bug in Docusaurus in the first place. I also wonder if others see those errors or if it's just you. Just asked on Discord to see if we can get more feedback: https://discord.com/channels/398180168688074762/398180168688074765/1161957671352676423 |
So because it shows up in the lighthouse GitHub action results that don't run on my machine I'm pretty sure it's not just me. My guess is that anyone who uses Docusaurus v3 and had lighthouse set up would probably see this |
|
I've raised #9393 which points lighthouse to the Docusaurus blog - if my theory is correct, the issue should show up in the lighthouse report on that PR for the |
|
In #9395 (comment) it looks like it's not just the blog but actually any Docusaurus page has errors, do you also see that locally? Particularly on docs? |
|
Yes, this pops up here aswell: |
|
yup seems to be a general issue - this is what I get at https://docusaurus.io/
|
slorber
changed the title
|
@lebalz are you using Ubuntu as well? I will need your help here because I'm using BrowserStack to test this and so far I couldn't reproduce using various combinations of OS/browsers. Can you try various browsers in incognito mode on Ubuntu and report the exact OS/Browser versions that can reproduce these hydration errors? And check multiple pages (home, docs, blog?) A clear report like this would help me a lot: # Ubuntu v22.04
## Firefox v119
- [/](https://docusaurus.io/): ✅
- [/docs](https://docusaurus.io/docs): ❌ (React error 418)
- [/blog](https://docusaurus.io/blog): ❌ (React error 418)
## Chrome v118
- [/](https://docusaurus.io/): ✅
- [/docs](https://docusaurus.io/docs): ❌ (React error 418)
- [/blog](https://docusaurus.io/blog): ❌ (React error 418) |
|
I've done some testing - it seems to be Ubuntu / Chrome specific. Interestingly Edge (which is very similar to Chrome) seems fine. Ubuntu v22.04Firefox 118.0.2 (64-bit)Chrome Version 118.0.5993.88 (Official Build) (64-bit)
Edge Version 118.0.2088.61 (Official build) (64-bit) |
|
ok, could it be somehow content-related? I can reproduce it only on the following blog post, but consistently on each browser in win 11 Windows 11 (22H2, Build Version 22621.2428)Firefox v119.0
Edge v118.0
Edge v118.0 (Guest Mode)
Chrome v118.0
Brave v1.59.120 (Chromium: 118.0.5993.88)
|
|
Thanks for the infos ! @lebalz yes https://docusaurus.io/blog/releases/2.4 definitively has an hydration problem, it's a quite specific case due to using an embedded iframe with a query-string. I can reproduce it and will see how to fix it. Do you have any problem on other posts that do not contain an iframe? For example this one? I think what you see is what I see, and the problem is indeed specific to Chrome/Ubuntu, so it's probably not worth it investigating more on your case. @johnnyreilly are you using guest mode on Chrome and still getting errors? Do you see any issue on these pages?
|
|
@johnnyreilly to be honest I'm not sure how I will be able to fix this issue 😅 This Docusaurus page that just prints "Hello" is still producing a lighthouse console error 🤷♂️ so I guess you get it too https://deploy-preview-9446--docusaurus-2.netlify.app/
I'll try to see if there's something in Docusaurus core, but this quite surprising 😅 And the |
I initially said "no" but I forgot I'm on a Mac right now. At work. Can check later.
I don't think that my extensions should be a cause. I turned them off and nothing changed. Significantly though, the issues show up in Lighthouse and there's no extensions there I guess? |
|
Did you see my comments on #9447 ? I'm happy to help you get Docusaurus running on Azure Static Web Apps and plug in Lighthouse there. |
|
Damn, I spent the day on this to figure out the problem is not Ubuntu but mobile viewport. If you hydrate a page on small device (like Lighthouse does) you get the error. This should be fixed now: https://deploy-preview-9446--docusaurus-2.netlify.app/ |
slorber
removed
the
status: needs more information
|
Good work on the mobile viewport stuff! I'll test on my home machine when I get a moment. The one thing that's in the back of my mind is that I have seen this on Ubuntu in desktop view - will let you know what I find |
|
It might be good to run lighthouse in desktop and mobile view regardless. There's tips here on how to do it |
|
Thanks, I'm not satisfied with our current setup, noted to also test on desktop here: #9449 |
|
Good catch and thanks for the big effort 💪 |
|
I still see the error on the mobile view @slorber - is the change live? Browsing at https://docusaurus.io/ and I've done a hard refresh
|
|
Not live yet, deploy failed like often due to our weird i18n setup If it's ok in the deploy preview it should be soon in prod |
|
@slorber hello, I just updated Centrifugo doc site to Docusaurus v3 and getting similar console errors in production build. I am using v3.0.0 - here is a branch with update, centrifugal/centrifugal.dev#45 (has screenshot with errors I observed). Looking at discussion it seems to be fixed in v3.0.0 - but still sth causes all these errors. For now I rolled back to using v2. |
|
@FZambia those errors are likely due to your own site code. Remove your React code, third party plugins, and if error persist then it's our fault, but I doubt it it. Or you can provide a minimal repro. Those errors are not a big deal. With React 18 we only log them while they were there but kind of hidden before in v2. It's likely that your v2 site already has hydration issues, that are simply unreported |
This advice helped me, thanks! In my case this was due to the following plugin in plugins: [
[
require.resolve("@easyops-cn/docusaurus-search-local"),
{
hashed: true,
},
],Removing it fixed all the errors. |
|
I was facing this issue serving static build with Caddy. My issue was that I was always serving index.html which wouldn't match what React would render for each other page on the client, obviously! Just writing this to give a tip on how to debug this:
Maybe this obvious for some, but might be a good hint for others 🍻 |
That's a common issue with hosts that do not serve static deployments correctly by default. You can also use devtools to throttle the network (or even block JS execution) and see that it first renders your homepage, and then it gets "fixed" by the local JS. |
Have you read the Contributing Guidelines on issues?
Prerequisites
npm run clearoryarn clearcommand.rm -rf node_modules yarn.lock package-lock.jsonand re-installing packages.Description
MIgrating my blog over to docusaurus v3 I noticed
"Minified React error #418; visit https://reactjs.org/docs/error-decoder.html?invariant=418 for the full message or use the non-minified dev environment for full errors and additional helpful warnings."in the console.Translated, this error means:
Hydration failed because the initial UI does not match what was rendered on the server.You can see it on the Docusaurus site as well as on my own.
You can see a repro of the error at either of the URLs below; simply pop open the devtools console and navigate there:
Steps to reproduce
See description
Expected behavior
No errors in console
Actual behavior
Errors in console
The same error appears present on the docusaurus site itself:
I run lighthouse in github actions on my blog - it shows up there too:
https://storage.googleapis.com/lighthouse-infrastructure.appspot.com/reports/1696186829813-4063.report.html
Your environment
Self-service
The text was updated successfully, but these errors were encountered: