Framework hosting : Navigation between pages is always hard reload

[victorvierna]

EDIT: Better naming for the bug

App Directory: Navigation between pages is always hard reload Next.js Router.push() reloads page automatically on firebase

[REQUIRED] Environment info

Integration: Enabled web frameworks Packages Version: firebase: ^9.22.0 firebase-admin: ^11.8.0 react: 18.2.0 next: ^13.4.3 Firebase CLI version: 12.4.4 Operating System: Ubuntu 22.04

fIrebase.json

"hosting": { "source": ".", "ignore": [ "firebase.json", "**/.*", "**/node_modules/**" ], "frameworksBackend": { "region": "europe-west1" }, "rewrites": [ { "source": "**", "destination": "/index.html" } ] }

firebaserc

{ "projects": { "default": "XXXX" } }

[REQUIRED] Test case

[REQUIRED] Steps to reproduce

I will attempt to create a minimal project if necessary. My Next.js application does not have any unusual features.

[REQUIRED] Expected behavior

Successful deployment of a Next.js 13 application. Dynamic routes function as intended. Deployment process is smooth and without issues.

[REQUIRED] Actual behavior

Comand line deploy --debug shows no errors but I am facing some issues: Only the run.app cloud run works as expected, but the web.app (and my custom domain) won't fully work:

• Dynamic routes don't function properly or consistently; the route loads indefinitely or redirects to '/'.
• React context seems to reset entirely when navigating through the application. This issue doesn't occur on run.app. The root cause might be a momentarily change in the authentication state or another bug.
• 404 Errors on manifest files and cache if using next-pwa to make it a PWA. Indeed I also had https://github.com/firebase/firebase-tools/issues/6135. e.g. workbox-7c2a5a06.js:1 Uncaught (in promise) bad-precaching-response: bad-precaching-response :: [{"url":"https://xxx.io/_next/app-build-manifest.json","status":404}]

In the cloud functions logs I can see the 404 errors and 304 e.g 2023-07-17 12:44:29.030 GET304 719 B12 msChrome 114 https://XXX-XXX-ew.a.run.app/firebase-messaging-sw.js GET404 3.25 KB36 msWhatsApp/2.23.12.78 A https://fh-14db9a1xxx891---xxx-xx-ew.a.run.app/xxxx.io/booking GET404 4.06 KB3.6 sChrome 114 https://fh-14db9a1d1xx---xxxx-xxx-ew.a.run.app/_next/static/css/8c71518ccbccb8e4.css GET404 4.01 KB2 sChrome 114 https://fh-14db9a1d16a5e891---xxx-xxx-ew.a.run.app/_next/static/chunks/webpack-1ef83629ce8faadf.js At first I also got memory limit errors so I increased to 512

The key questions I have are:

Why are both run.app and web.app necessary, and how do they handle dynamic routes through the cloud function? This isn't clear from the documentation. Could I redirect my custom domain to the cloud.run? I previously faced the 404 Error associated with the pinTags issue, which was resolved by re-enabling pinTags. However, could this have any lingering effects?

[victorvierna]

After updating "next" to version "^13.4.7", removing rewrites, and excluding i18n from the next.config, it seems that the issue with dynamic routes has been resolved. However, I am still unable to find a solution for the continuous context reloading. As I navigate through the app, the console displays 'Navigated to xxx', and the entire app context reloads. This issue is evident from the logs and observations made using the React Chrome extension, which ultimately renders the app inoperable. Interestingly, this problem doesn't occur when using XXXXew.a.run.app on Cloud Run. There, the user experience is seamless: it's fast, devoid of unnecessary reloads, and offers image optimization and dynamic links.

[victorvierna]

Hi again. I am writing to you in hopes of resolving an issue that is significantly impacting the launch timeline of my startup. My app undergoes a complete reset as I navigate through it, which is demonstrated by the 'navigated to' message shown in the console. This problem leads to the 'currentUser' in Firebase Auth momentarily displaying as null, triggering a reloading of all contexts and associated data repeatedly.

Although it initially seemed as if 'currentUser' was losing its value, my analysis suggests that it's more of a full application component tree reload akin to a hard refresh. Subsequently, Firebase Auth reads cookies and automatically logs in the user again. Notably, this issue doesn't manifest when accessing run.cloud.

I have already attempted numerous resolutions, including adjustments to Firebase hosting rules, adding 'allUsers' to both Cloud Run and Cloud Function, as well as conducting network debugging in both run and custom domain environments. Despite these efforts, the problem persists.

In summary, my experience with Cloud Run mimics a Single Page Application (SPA) operation, devoid of reloads and with multiple sequential (waterfall) calls as observed in the Chrome network tool. Examples of these calls include:

page-d09f757993bfe7de.js
/_next/static/chunks/app/booking
iframe.js
/__/auth
firestore.googleapis.com/google.firestore.v1.Firestore/Listen

More info: info.md

Please do not hesitate to request further information should you require it. This problem doesn't occur in vercel nor cloud run.

[RajendraAVerma]

I have same problem. When deployed to firebase. Each time page refresh when navigating through Link. this was not the case before. Did anyone have solution? firebase-tools version : 12.4.6 next version : 13.4.12

[victorvierna]

I have same problem. When deployed to firebase. Each time page refresh when navigating through Link. this was not the case before. Did anyone have solution? firebase-tools version : 12.4.6 next version : 13.4.12

Hi! I've been trying to find a workaround, but haven't had any luck so far. I've reached out to other communities for help, but it seems like a bug within Firebase. We may need to wait or consider switching platforms. Just to note, the latest version they claim to support is 13.4.7, but this issue appears in all versions. Let's collaborate to find a solution. Have you noticed any errors in the Cloud Run logs or the Cloud Run's hosting integration tab? I believe the Firebase hosting cache configuration might be causing the issue.

[victorvierna]

More info...

I've attempted to resolve the error displayed in the integrations tab of Cloud Run. The error might be related to the current issue we're facing:

Latest deployment: FAILED - Resource [xxx] failed with error: resource is in failed state "Ready:False", message: Revision 'xx-00023-n4z' is not ready and cannot serve traffic. Image 'europe-west1-docker.pkg.dev/xxxxx/gcf-artifacts/xxx:version_1' not found.

I performed a static deployment of our application by first utilizing next build, then configuring firebase init without specific awareness of frameworks or Next.js. As a result:

• Web page navigation no longer mandates a hard reload.

• However, its not a valid solution: be aware that dynamic links and certain non-static functionalities are not operational. Next.js documentation on Static Deployment.

[JW709]

My team is facing the same issue. When navigating through the footer the app no longer does a hard reload but all context data is lost.

We are also having issues with our image service (cloudinary) displaying images (in production) and issues with cookies not being set.

[victorvierna]

I have found a netlify pull request that addresses what I believe is the issue here, please have a look devs :) https://github.com/netlify/next-runtime/pull/1855

[victorvierna]

Hi! @alexastrum Firstly, thank you for the work you do on Firebase; it's an essential tool for my startup.

I wanted to follow up on this issue as it has been open for over a month now. It's causing some critical problems with my Next.js deployment on Firebase hosting, which are impacting my startup's launch timeline. I understand that everyone has different priorities and tasks to tackle, but this issue seems to be affecting multiple users.

Could you please update us on the current status of this issue? I would really appreciate some information on the following:

• Is this issue considered a priority?
• Is there an estimated timeframe for a fix?
• Workarrounds? I don't know how deploying to cloud run with docker would compare in terms of scalability, cost, and performance to Firebase Hosting's web framework integrations.

Your attention to this matter will greatly assist my decision-making process concerning my infrastructure choices.

Thank you for your time and consideration.

[DadaSantana]

I am also facing the same problem. My application runs locally and in the development environment without any problems, but when I host it on Firebase, using the firebase deploy command, the Link component forcefully reloads the page.

Waiting for the problem to be resolved!

[ian-sayles]

I also found this issue yesterday when I deployed to Firebase hosting, like everyone else, works fine in development but link forces full reload of the page when live on Firebase.

Does anyone know if this can be or will be fixed and if so when it will likely be solved.

[jpenna]

I'm having the same problem. It works as expected locally, but makes a hard reload in production. The URL only changes the query string, but Firebase forces a hard reload.

The exact same application deployed on Vercel works as a charm. This is definitely Firebase related.

[jpenna]

After some digging, I found out there is a content sent back from Vercil that isn't returned from Firebase.

I'm using router.push("/schedule") and router.push("/schedule?id=some_id") to hide and show a modal with data for id. When I do any of these call in the Vercel server, the first request triggered by rotuer.push returns the following for the GET request. When I do a request from Firebase, the first request doesn't return anything in the payload. I overrode the payload returned for Vercel's request and turns out it reloads the page, the same as Firebase does.

Why isn't Firebase returning a payload like Vercel does?

1:HL["/_next/static/media/c9a5bc6a7c948fb0-s.p.woff2",{"as":"font","type":"font/woff2"}]
2:HL["/_next/static/css/a4a230810479edc5.css",{"as":"style"}]
3:HL["/_next/static/css/d43bd402decd3305.css",{"as":"style"}]
0:["8wPqgXvrvp5Xtyp3g0bdW",[[["",{"children":["schedule",{"children":["__PAGE__",{}]}]},"$undefined","$undefined",true],"$L4",[[["$","link","0",{"rel":"stylesheet","href":"/_next/static/css/a4a230810479edc5.css","precedence":"next"}],["$","link","1",{"rel":"stylesheet","href":"/_next/static/css/d43bd402decd3305.css","precedence":"next"}]],"$L5"]]]]
6:HL["/_next/static/css/6f721b45a8ecbf27.css",{"as":"style"}]
7:I{"id":33865,"chunks":["189:static/chunks/32c2d985-bc08111968bf7129.js","614:static/chunks/cd6b49a6-30ad1900878cfb82.js","408:static/chunks/408-739b30a99f24e465.js","144:static/chunks/144-b40204aa6b46cbca.js","818:static/chunks/818-768f147f0761e026.js","366:static/chunks/366-5a598473182eb654.js","59:static/chunks/59-17d367b9ff09693c.js","17:static/chunks/17-d3d5cc5d6277d7a4.js","185:static/chunks/app/layout-59295a271a8242ee.js"],"name":"","async":false}
8:I{"id":74156,"chunks":["189:static/chunks/32c2d985-bc08111968bf7129.js","614:static/chunks/cd6b49a6-30ad1900878cfb82.js","408:static/chunks/408-739b30a99f24e465.js","144:static/chunks/144-b40204aa6b46cbca.js","818:static/chunks/818-768f147f0761e026.js","366:static/chunks/366-5a598473182eb654.js","59:static/chunks/59-17d367b9ff09693c.js","17:static/chunks/17-d3d5cc5d6277d7a4.js","185:static/chunks/app/layout-59295a271a8242ee.js"],"name":"","async":false}
9:"$Sreact.suspense"
a:I{"id":33472,"chunks":["272:static/chunks/webpack-010a6484fd2e719a.js","764:static/chunks/fdad5abf-ce928b91379c3fe2.js","197:static/chunks/197-01a74e31b1cc1e56.js"],"name":"default","async":false}
b:I{"id":8451,"chunks":["601:static/chunks/app/error-b957f2d639539525.js"],"name":"","async":false}
c:I{"id":8144,"chunks":["144:static/chunks/144-b40204aa6b46cbca.js","555:static/chunks/app/loading-b401eb367dbda2d6.js"],"name":"Image","async":false}
d:I{"id":52574,"chunks":["272:static/chunks/webpack-010a6484fd2e719a.js","764:static/chunks/fdad5abf-ce928b91379c3fe2.js","197:static/chunks/197-01a74e31b1cc1e56.js"],"name":"default","async":false}
e:I{"id":46701,"chunks":["272:static/chunks/webpack-010a6484fd2e719a.js","764:static/chunks/fdad5abf-ce928b91379c3fe2.js","197:static/chunks/197-01a74e31b1cc1e56.js"],"name":"default","async":false}
f:I{"id":39528,"chunks":["189:static/chunks/32c2d985-bc08111968bf7129.js","614:static/chunks/cd6b49a6-30ad1900878cfb82.js","982:static/chunks/7f15cb9d-e1da4f635add1cc6.js","408:static/chunks/408-739b30a99f24e465.js","144:static/chunks/144-b40204aa6b46cbca.js","818:static/chunks/818-768f147f0761e026.js","679:static/chunks/679-1565cffb8d0b045b.js","366:static/chunks/366-5a598473182eb654.js","325:static/chunks/325-dec6b3fb9a035d91.js","17:static/chunks/17-d3d5cc5d6277d7a4.js","681:static/chunks/app/schedule/page-1b8d574fc27b271a.js"],"name":"","async":false}
10:I{"id":38400,"chunks":["189:static/chunks/32c2d985-bc08111968bf7129.js","614:static/chunks/cd6b49a6-30ad1900878cfb82.js","408:static/chunks/408-739b30a99f24e465.js","144:static/chunks/144-b40204aa6b46cbca.js","818:static/chunks/818-768f147f0761e026.js","366:static/chunks/366-5a598473182eb654.js","59:static/chunks/59-17d367b9ff09693c.js","17:static/chunks/17-d3d5cc5d6277d7a4.js","185:static/chunks/app/layout-59295a271a8242ee.js"],"name":"","async":false}
4:[["$","html",null,{"lang":"ptBR","className":"scroll-smooth","children":["$","body",null,{"className":"__className_e66fe9 selection:bg-orange-200 [--header:3.5rem]","children":["$","$L7",null,{"children":[["$","$L8",null,{}],["$","$9",null,{"fallback":["$","div",null,{"className":"loading_ldsRipple__dIW6a loading_violet___EvMi","style":{"width":80,"height":80},"children":[["$","div",null,{"style":{"borderWidth":"4px"}}],["$","div",null,{"style":{"borderWidth":"4px"}}]]}],"children":["$","$La",null,{"parallelRouterKey":"children","segmentPath":["children"],"error":"$b","errorStyles":[],"loading":["$","div",null,{"className":"flex flex-col justify-center items-center min-h-[50vh]","children":[["$","div",null,{"className":"loading_ldsRipple__dIW6a loading_violet___EvMi","style":{"width":80,"height":80},"children":[["$","div",null,{"style":{"borderWidth":"4px"}}],["$","div",null,{"style":{"borderWidth":"4px"}}]]}],["$","$Lc",null,{"src":{"src":"/_next/static/media/contentia_borda.672497c1.png","height":594,"width":2413,"blurDataURL":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAgAAAACCAMAAABSSm3fAAAAD1BMVEUCAgIDAwAJCQLJk4GnYsU545hPAAAABXRSTlMnGjE8P24SmTsAAAAJcEhZcwAAFxEAABcRAcom8z8AAAAZSURBVHicBcEBAQAACAIg1P5vDmxB4y6qHgDyABi4hzeuAAAAAElFTkSuQmCC","blurWidth":8,"blurHeight":2},"alt":"Contentia logo","className":"p-4 pb-0 text-center w-[25rem] max-w-full mx-auto","priority":true}]]}],"loadingStyles":[],"hasLoading":true,"template":["$","$Ld",null,{}],"templateStyles":"$undefined","notFound":"$undefined","notFoundStyles":"$undefined","childProp":{"current":["$","$La",null,{"parallelRouterKey":"children","segmentPath":["children","schedule","children"],"error":"$undefined","errorStyles":"$undefined","loading":"$undefined","loadingStyles":"$undefined","hasLoading":false,"template":["$","$Ld",null,{}],"templateStyles":"$undefined","notFound":"$undefined","notFoundStyles":"$undefined","childProp":{"current":[["$","$Le",null,{"propsForComponent":{"params":{}},"Component":"$f"}],null],"segment":"__PAGE__"},"styles":[["$","link","0",{"rel":"stylesheet","href":"/_next/static/css/6f721b45a8ecbf27.css","precedence":"next"}]]}],"segment":"schedule"},"styles":[]}]}],["$","$L10",null,{}]]}]}]}],null]
5:[["$","meta","0",{"charSet":"utf-8"}],["$","title","1",{"children":"Contentia"}],["$","meta","2",{"name":"description","content":"Facilite sua produção de conteúdo!"}],["$","meta","3",{"name":"viewport","content":"width=device-width, initial-scale=1"}],["$","link","4",{"rel":"icon","href":"/favicon.ico","type":"image/x-icon","sizes":"any"}],["$","meta","5",{"name":"next-size-adjust"}]]

[Bobbiedan10]

I am also experiencing the same issue using the app directory and what I'm trying to achieve really isn't technical. I'm just making the page smooth scroll to a section in the page using an id "#". I tried several different strategies in order to combat the problem and none of them worked.

• using Link from next/link
• using the regular anchor tag works to an extent but not completely for the intended use
• creating a custom button component and using useRouter()

All of them resulted in a hard reload in production in firebase hosting but the cloud run link works as intended. I attempted pointing firebase hosting to the cloud run service in the firebase.json file and there was no change.

[victorvierna]

Unfortunately, it seems that Firebase support is still lacking for this issue. For those who are facing the same problem, I've successfully implemented a workaround using Docker deployment on Google Cloud Run. You can find more details on how to do this in the Next.js documentation: Deploying with Docker.

[Alexcsmbz]

Hi there I have absolutely the same problem, and my startup is also delayed And yes, the problem is related to the firebase hosting cache, because I noticed that there was one font in the previous build, I changed this font to another, deployed the build, found a problem with page reloading and only one page still draws the old font, although it was used in the previous build unfortunately, I have no idea how to solve this, except using another platform :( thank you for your advice

[Bobbiedan10]

I am also experiencing the same issue using the app directory and what I'm trying to achieve really isn't technical. I'm just making the page smooth scroll to a section in the page using an id "#". I tried several different strategies in order to combat the problem and none of them worked.

• using Link from next/link
• using the regular anchor tag works to an extent but not completely for the intended use
• creating a custom button component and using useRouter()

All of them resulted in a hard reload in production in firebase hosting but the cloud run link works as intended. I attempted pointing firebase hosting to the cloud run service in the firebase.json file and there was no change.

Update

Hey guys i was able to fix my issue. If when building its de-opting to client side rendering I believe is the cause for the issue. Also, if you guys are using the hook "useSearchParams" its the reason for de-opting to client side rendering which I used while adding Google Analytics to my project. I found an article while trying to fix my open graph meta tag issues and it solved the reload issue as well. Article here

Using export const dynamic = 'force-dynamic' in my root layout.tsx did the trick for me and all my pages were uploaded as server files in the build process. Let me know if this helps.

[peetya]

@Bobbiedan10 you saved my nerves, finally it works :) Many thanks!

[cmyker]

Having the same issue under 13.5.3

[cmyker]

Ok, so for those who is seeking for a solution take a look at this repo: https://github.com/vercel/next.js/tree/canary/examples/with-firebase-hosting it redirects all non-static files to ssr cloud function and no static HTML is served from hosting, but it works as expected just like under normal nodejs env, and worked for me as well, and in many ways mitigated by hosting cache Since firebase tools "framework aware" stuff is unusable for next.js this is the only realistic way to deploy it to firebase HEAR ME FIREBASE TOOLS DEVELOPERS @alexastrum PLEASE! YOUR "FRAMEWORK AWARE" IS UNUSABLE FOR ANYTHING BEYOND ONE PAGE APP, FOR REAL LIFE APPLICATIONS IT IS USELESS!!!!! PLEASE DO SOMETHING ABOUT IT FINALLY!

[alexastrum]

Sorry for the delayed response. I haven't been on this project for a while. The team released a few significant updates for https://github.com/FirebaseExtended/firebase-framework-tools that might have fixed this issue. Hope it helps.

[ian-sayles]

Don't think it's fixed for its still doing it on my project.

[VictorBaudot]

the issue is still here with everything on latest version.

[harsh-persona3]

I can also confirm this issue still persists

[karpolan]

For Next.js with SSG (next.config.* { output: "export" }) the only working solution, at least for now, is to disable webframeworks

Run: firebase experiments:disable webframeworks to disable "firebase magic"

Then run: firebase init hosting, choose out as "public" folder, and DO NOT override 404.html and index.html pages

After that, you can deploy a static website using: firebase deploy --only hosting

Have fun :)

[lancedw]

I am also having this issue. Router.push does a full reload causing all states to be lost

[pm0u]

Doesn't happen to me on all router.push() I can't figure out what the difference is that is causing some to not do this. But it does happen for me on Next 14 / app router and makes this almost useless. Unfortunately, output: 'export' is not feasible for my project.

It seems like pages that work respond with Content-Type: text/x-component vs pages that do not work respond with Content-Type: text/html

• Happens for router.push() as well as <Link /> navigations

ok, the ones that were not triggering a client side refresh were WIP pages that returned a fragment <></> in place of actual content. So the URL bar changes but obviously nothing changes within the page (in the context of a layout child) - changes in the parent layout do render (eg highlighting current route).

The local emulator actually behaves worse in that it refreshes for any of these navigations

[jamesdaniels]

Unfortunately we're constrained by the design of Firebase Hosting here. The way the CDN is configured does not allow conditional rewrites and NextJS switches content-types based off a custom header. Work around would be to disable caching on those routes or get tricksy with a service worker.

I'm hoping we'll have a solution in Firebase App Hosting soon.

[AnthonyDitocco]

Any update on a solution, looks like this was opened over a year ago?? Just discovered this hard reload and reset context on route changes, after finishing my app and getting it hosted. Would like to stay hosted on Firebase but this makes it unusable.

[pm0u]

The solution is Firebase App Hosting which is not yet fully released.

[victorvierna]

@AnthonyDitocco I know... you can host it using Firebase app hosting as @pm0u suggested or just deploy your app with docker to cloud run.