next.js: [NEXT-684] Fast-refresh for CSS files is not working in Firefox

I have this issue (13.2.4) in Safari and Chrome as well!

Issue still present 13.2.4, Edge, Chrome and FFox.

same problem with 13.0.6

I was also facing this issue with tailwindcss. I’m using Next 13.2.4 and Safari 16.4.

After some research, I managed to workaround this issue by adding following in next.config.js:

headers:
    process.env.NODE_ENV === 'development'
      ? () => [
          {
            source: '/_next/static/css/_app-client_src_app_globals_css.css',
            headers: [{ key: 'Vary', value: '*' }],
          },
        ]
      : undefined,

Vary: * Indicates that factors other than request headers influenced the generation of this response. Implies that the response is uncacheable.

This is working perfectly for me. You can read more about Vary: * on MDN.

Adding the vary header has no effect on this issue, it needs special handling in React which is something we’re looking into.

Bug still present in 13.2.3

Digging into the changes, I think this is the culprit:

Because I see the ‘cache buster’ suffix is no longer added to the stylesheet, making the browser unaware that its contents changed. If I refresh the stylesheet manually in a second tab, I do see the new class added to it.

When these labels are added it’ll never be set as stale as it’s triaged, we’re aware of it, and no further action is needed as it’s already being tracked.

So based on @laneme and @akomm’s feedback the issue can be reproduced on Firefox only. I’ll investigate that specifically. Thanks all!

Hey, you don’t have to comment saying an issue still exists in “version x” because the issue is still open it is not fixed. Thanks!

i’m not sure how related this is - But on my end (tw@3.2.7, next@13.2.3, Chrome) some elements do not appear on the first paint (like, at all) - and they would only appear if i make a classname change to a parent element and then hot reload… This happens both on the dev server and on build.

I am also getting the initial style-lacking flashes like some others mentioned

@huozhi HMR is indeed working in 13.0.8-canary.0 when using Tailwind. There’s a small issue, though: a flash of unstyled content before new styles are applied.

Just did some preliminary investigation, the defect looks to have been introduced in 13.0.5-canary.4

The canary versions prior to that do not have the issue, a few updates to the hot reloader types in that release

@laneme I observed the same thing, that the problem exists in Firefox only. I think it’s due to Firefox not respecting the cache header for CSS resources.

We are working on a proper fix for it in both React and Next.js.

I tested different next.js releases.

For me on Windows 11, tested with and in Chrome, state of fast-refresh with tailwind:

• v13.1.7-canary.6 (works ✅)
• v13.1.6 (broken ❌)
• v13.1.5 (broken ❌)
• v13.1.4 (broken ❌)
• v13.1.3 (broken ❌)
• v13.1.2 (broken ❌)
• v13.1.1 (broken ❌)
• v13.1.0 (tailwind totally broken ❌)
• v13.0.7 (works ✅)
• v13.0.6 (works ✅)
• v13.0.5 (works ✅)
• v13.0.4 (works ✅)
• v13.0.3 (works ✅)
• v13.0.2 (works ✅)
• v13.0.2 (works ✅)
• v13.0.1 (works ✅)

(disclaimer: no canary versions tested, except latest one v13.1.7-canary.6)

@shuding Here is a codesandbox to reproduce the issue even on Chrome.

https://codesandbox.io/p/sandbox/quizzical-austin-9rcihp?selection=[{"endColumn"%3A1%2C"endLineNumber"%3A10%2C"startColumn"%3A1%2C"startLineNumber"%3A10}]&file=%2Fpages%2Ftest.tsx

If appDir is set to false, tailwind updates without any issue when you save the file. But if appDir is set to true then I have to reload every time to see the update. I just want to make it clear that this is happening for me on the pages routing system. In my case, I have Sanity in the new app folder and I have to keep my site in the pages folder because the ‘as’ property is not there yet in the new routing. I hope this makes sense.

To reproduce it, try to always use custom colours for example bg-[#ffd000]

I also made a video to show the issue just in case: https://share.cleanshot.com/rWbx5WHx

Tried to upgrade to version 13.1.1 now, but it’s still broken, so I’m back at 13.0.4. 😕

Saw the Next.js 13.1 Explained! video, where he showed off tailwind with --turbo, where it seemed to work, so hoped it would be fixed now, but… nope… ☹

Same, for me it has never worked on v13. Tailwind works but JIT classes are not added until you refresh the page.

Whoever still copes with the issue, here’s the fix:

The issue is still present, but you can circumvent the issue by integrating tailwind differently. I’m not sure if this method was available before, but at least since next 13.3.1 you can integrate it via postcss as a plugin - so check your next version if it does not work. Then instead of importing the TW output css file, you import the TW input css file. The webpack loader chain this way recompiles the input file and reloads the link properly. Not need to run tailwind parallel anymore as its part of the webpack pipeline.

It has been added to the docs: https://beta.nextjs.org/docs/styling/tailwind-css

Issue exists in Next 13.2.4 and Firefox111.0.1 64bit.

@rijk Thanks! I’m aware of that as I removed it. But currently we need to fix something in React, otherwise if we add back the ?ts= query it will cause another bug (link tags with different queries will be added but old ones can’t be removed upon HMR).

Can confirm I am experiencing the same issues with 13.0.5 and tailwind as reported by @Svish. Going back to 13.0.4 is fine.

@timneutkens I think it’s valid, so the issue doesn’t get tagged as stale and ends up thrown in stale oblivion (forgotten).

Can confirm this issue is still present in 13.2.5-canary.4

@shuding just FYI everything was working fine before with this cacheBustingUrlSuffix:

same problem with 13.0.6

Same fixed by downgrading to 13.0.4. For anyone wondering like me how to downgrade a npm package, you just install the package again with @<version> and it will overwrite. So: npm install next@13.0.4

Same issue here. You can use the solution for Turbo Pack (concurrently) in the mean time.

npm install --save-dev concurrently

{ “scripts”: { “dev”: “concurrently "next dev --turbo" "tailwindcss --input input.css --output output.css --watch"”, “build”: “tailwindcss input.css --output output.css && next build” } }

https://beta.nextjs.org/docs/styling/tailwind-css

@shuding I created this https://github.com/eduardochiaro/test-sass I set up 2 pages, one under app folder, the other under pages folder. Both using same scss global file and component. To test, open homepage / and also /test page.

• http://localhost:3000/ use app folder,
• http://localhost:3000/test use pages folder.

Using next dev make a change on \src\app\Component.tsx. the change need to be a tailwind call not used before. Hot reload will trigger on http://localhost:3000/test but not on http://localhost:3000/.

Also affected by this issue. Using Firefox. Deleting .next directory and rebuilding fixes it but is a pain.

This issue kinda preventing me from using the app directory for months :c

Even though in chrome, the exact issue didnt seem to affect me, the flash of unstyled content is too much. Its more than just momemtarily

https://github.com/vercel/next.js/issues/43396#issue-1464877520

I’m also having the same issue with global css. I’m on v13.1.6

Were you able to produce this bug yourself yet? If not, might wanna take a look at windows. I noticed a lil bit of different behavior on windows versus ubuntu https://github.com/vercel/next.js/issues/43878#issuecomment-1408260051

For whatever it’s worth, I am having this issue also, and can consistently reproduce on Windows 11 with the latest version of Firefox (v109.0.1). Reloading loads the correct styles for me, contrary to what the person in the above comment mentioned.

As described by others, it works fine in Chrome and Edge.

@shuding might as well take a look back at https://github.com/vercel/next.js/issues/43878, that thread still active

I have just quickly installed chromium and I can confirm the issue doesn’t exist there.

The bug is still present in the unmodified playground you’ve provided when using FF 109.0.

added I’ve checked back next 13.1.5: the bug is not present using chromium but it is using FF.

@MattHeslington

If https://github.com/vercel/next.js/issues/43396#issuecomment-1353690564 is correct and 13.0.8-canary.0 has/had it fixed, yet it didn’t make it into the recent releases, including 13.1.X, maybe they encountered an issue with that. This is why I would approach this with doubt. It annoys me, but its beta. They have a lot things on the table. But its weird, if there is no problem why it was not simply reverted until a better solution for what the removal wanted to achieve is found.

I wonder, is there something preventing a fix from happening? Judging by the comment added with the change why it was changed it seems like “oh we just don’t need it”, but it appears we do need it to bust cache. What stops the devs from reverting this breaking change? Can we help somehow? Or is there a more important reason why it was changed, that is not explained in the comment that explains the change, hence reversion isn’t desired?

Tailwind and HRM is working on v13.0.4-canary.5 for me but I can’t get it working on anything above it.

For now I have just downgraded to 13.0.4, where it at least seems to work. Not sure what I’m missing from Next-wise from the versions above though… 🤔