Push Notifications not opening destination page when clicked

[danny-support-flutterflow]

Has your issue been reported?

• I have searched the existing issues and confirm it has not been reported.
• I give permission for members of the FlutterFlow team to access and test my project for the sole purpose of investigating this issue.

Current Behavior

When a push notification is received by an application that is paused and not in view, if the user clicks on the notification, the app opens to the home page and does not navigate to the page that the push notification is supposed to open.

Expected Behavior

Once a notification is clicked, it is supposed to open the destination page if it was set when triggering the push notification.

Steps to Reproduce

To reproduce the issue in a new project, follow these steps:

1. Open the FlutterFlow project at the provided link.
2. On a mobile device, click 'login user 2', then minimize the app without completely closing it.
3. On a test mode or the notification triggering device, click 'login user 1'.
4. In the list of users, click 'Danny 2'. This action should trigger a notification and send it to the mobile device.

Reproducible from Blank

• The steps to reproduce above start from a blank project.

Bug Report Code (Required)

IT4KiM/qx5BgobhG0LrUdMJVgjgRNmY5a7swltV9ewkbJbbzG7l/TMnOVBJuOLC0TWNLfFmWmnkKwN3emvDuU8YCFAecR75bwc1ITzzJUkKub4yTBau8Om5/DdFQfx2i58CJsxV5KrJhW1I+61+UCfKvVj3rJr74DHoROvm1OZCK2SrDX1iXc2URm05KZDPz

Context

Users should be navigated to the page specified in the push notification metadata. However, this doesn't happen when the application is in a paused state and not in view. It only occurs when the application is fully closed and not in memory.

Visual documentation

Additional Info

No response

Environment

- FlutterFlow version: v4.1.34+ released April 16, 2024
- Platform: Android
- Browser name and version: Chrome, Version 123.0.6312.123 (Official Build) (arm64)
- Operating system and version affected: Android 13

[byrondowns]

This is a big issue for us, not having push notifications open the correct page makes our app have poor UX

Surely this is key for everyone that uses push notifications

Can someone please progress?

[rzambroni]

Hey @byrondowns, i sent this to the team so they can take a look. We will update the status here once it is fixed.

Thanks!

[byrondowns]

Hey @byrondowns, i sent this to the team so they can take a look. We will update the status here once it is fixed.

Thanks!

Thank you @rzambroni !

[byrondowns]

@sbis04 hi, have you reviewed this issue yet?

[vinayakagw]

Any update on this yet?

[byrondowns]

Can we please get an update? This is a major issue for us

[Leonardo-Faria-Oliveira]

I'm having this issue too, is there any update?

[flp88]

Addressing this issue is crucial for all users who rely on initial page parameter in push notifications. It's important to ensure that when a push notification is sent, the user is directed to the correct path. This is vital for maintaining a high-quality user experience for my app.

Please, fix this issue ASAP.

[taggxyz]

Any update on this?

The latest version of my app cannot go live without this being fixed as I am introducing messaging functionality. A notification saying 'New message in your inbox' and only opening the homepage when you click it is pointless for me.

[byrondowns]

@leighajarett Can we please get a response from the flutterflow team on this issue? I understand there are many priorities to balance, however, this is a critical issue and we have had no real response from the FF team. Where does this sit in Flutterflow's priorities?

Very disappointing being a Pro subscriber and getting no comms on a significant bug confirmed months ago

[vinayakagw]

Hello hello flutterflow team? Instead of releasing shiny new features, please first fix these bugs that affect the actual user facing functionalities of any application.

[James5943314556]

I am having the same issue

[mikemcclelland]

Same. Agree that this is a critical issue.

[byrondowns]

Any update on this @mmearly ?

[carmenchargely]

This is also affecting us. Are there any updates on this bug reported?

[taggxyz]

@leighajarett Thats great to hear! Any idea of when this might be fixed? We’ve all been trying to find workarounds for over 7 months now as it is crucial to the user experience so any rough timelines would be super useful!

[leighajarett]

I am not sure - we have been working on this for months and tried numerous fixes, we thought it was resolved a few times. So it's hard for me to say

[taggxyz]

bump

[taggxyz]

bump

[taggxyz]

bump

[taggxyz]

is this fixed yet?

[lkhulusi]

Jumping in here. @leighajarett are you able to provide some transparency on this issue? Has the underlying cause been identified yet? Is there a severity level you can share with us so we know how high of a priority this is?

Any kind of information that will help manage expectations and help us make informed decisions on how to move our projects and businesses forward would be greatly appreciated. Maybe a commitment to provide updates weekly, even if the update is "no update" would help.

Thank you for everything you and the team are doing!

[byrondowns]

^^ This would be really valuable for us. This issue has caused a lot of friction internally.

It's also prevented me from recommending FlutterFlow to other developers. Having transparency across would at least show maturity of FF as an organisation that can support their customers build production ready apps

[nathankrishnan]

We're currently investigating this and will share an update here this week.

[mmearly]

@taggxyz @Phillewis63 @byrondowns @Jensoulus @max-h-silverman @lkhulusi

Hi everyone. As promised, here are some details to fill everyone in on what is happening here:

The technical problem:

Push notifications can specify a specific page that the app should open to. When the app is started from a cold boot, it always first goes to the root page as specified by the router. This is generally the home page if a user is logged in. Even though in general clicking on a push notification with a defined target page appears to take you to the intended destination, the root page still runs in the background. The bug that was being encountered here was that if the root page has an On Page Load action chain, it still will be run to completion even though we do not appear to be on that page anymore. So if the root page has an On Page Load action that includes navigation, the act of clicking (when the app is not already running) on a push notification that is defined with a different target page will cause both the app's home page and the target page to load, which results in the navigation from the root's On Page Load running, effectively overriding the destination specified by the push notification.

This problem only affects users with push notifications enabled on projects whose home pages have On Page Load chains with navigation actions.

The technical solution:

We are introducing a new global property, Current Route, that can be used to conditionally perform your navigation logic only if the current page is what you expect it to be.

Each page corresponds to a route; this is how we are internally able to keep track of which page to show. This variable will hold the route of the page that is currently being displayed. You can see the route name for a given page by clicking on the page in the page selector, then expanding the Route Settings section in the properties panel on the right. Route names always start with /, then are followed by some text, for example /home or /login. The initial backslash gets added automatically and should not be typed into the Route: text field here.

What this means from a practical perspective for resolving this bug is that the navigation action in your root page's On Page Load chain needs to be wrapped in a conditional that prevents the action from running if the current route is not the root or the home page. For the overwhelming majority of cases, the condition that will need to be added is Current Route Path == '/' OR Current Route Path == '/(yourHomePageRouteName)'. Please see this video to see an example of how to do this.

This functionality will be included in the next weekly production release, which is scheduled for Tuesday January 21 Wednesday January 22. Note that you will need to manually insert the conditional to achieve the desired behavior, as specified in the video. I will post another comment on this thread on Tuesday once the release is ready.

Why did this take so long?

At first glance, we were not able to reproduce this issue and several deductions needed to be made to figure out why certain users were observing this issue. The issue is not present in our internal debug builds. We eventually found that the bug is only observed in projects explicitly built with the --release flag, for reasons still not really understood. It was also later found that the timing of how long it takes to reach the navigation action on the inactive page impacts the bug, which meant that a simple blank project could not reproduce the bug unless a delay was explicitly added before the navigation action. This is in contrast to users' projects experiencing the bug, which generally have more complex logic in the On Page Load trigger before the navigation action (and thus, it takes longer to reach the navigation action).

There were many internal discussions as to how to resolve this issue. This led to several exploratory approaches that were investigated before we discovered the root cause of the bug. After we were able to reproduce the bug, we needed time to determine an elegant solution. We finally landed on the current solution that everyone on our team is happy with.

To be clear, this is an explanation of events, not an attempt to make excuses. In this situation we could have done a much better job providing regular updates about the issue. Thank you again for your understanding and we will strive to do better in the future. Let us know if you have any questions.

[taggxyz]

@mmearly Thank you for such a thorough response - can’t wait for this to go live! 🙌

[leighajarett]

Quick note that this release is actually expected to go out tomorrow, the 22nd 🙂

[Phillewis63]

It's been working great since Sunday. The user even gets the notification if they are in the app now

[mmearly]

Hi again everyone, the release including the current route path variable is now out -- you should now be able to wrap your undesired onPageLoad navigation in a conditional checking this to resolve this bug. Here's that video again showing how to do this. Let us know if you run into any issues.

[Rodriq]

@mmearly just to further understand the way things work better.
If say I had enabled the Skip On Page Load when Inactive on my entry page, that wouldn't have been able to handle the issue?

[byrondowns]

@mmearly thanks for the detailed response here, really appreciate it.

However, after making the changes, it appears i still have this issue. In fact now the routing doesn't work regardless of wether the app is open in background or not

This is the behaviour in getting when a push notification is clicked (iOS):

1. If app is open in background -> No routing changes (user stays on whatever page they were on)

2. If app is not open in background -> User gets sent to the correct page, then shortly after this they get sent to the default page. (note: This used to work properly, before new these new changes where implemented)

My default page that gets loaded is called "page_router", i've added the logic where I think it makes sense. Maybe i've made a mistake somewhere? Can you please advise?

Attached screenshots of config for reference

Update: When app is open on background there is no changes to routing (user stays on whatever page they were on), originally i thought they were getting sent to the default page, but that doesn't appear to be the case

[mmearly]

@byrondowns This generally looks right to me, but let's try it without /home check. If that doesn't work, can you post a bug report code so I can take a closer look at your project?

Is the behavior for case 2 (if the app is not open in the background) affected at all by having / not having this condition?

[mmearly]

@Rodriq In theory yes, it should have been able to, but some users here said otherwise, which we couldn't reproduce, and since the current route path was a feature we had wanted to release anyway, it made sense to just do this

[byrondowns]

@mmearly I removed /home check and confirm behaviour is still the same, that is:

If app is open in background -> No routing changes (user stays on whatever page they were on)

If app is not open in background -> User gets sent to the correct page, then shortly after this they get sent to the default page. (note: This used to work properly, before new these new changes where implemented)

Expected behaviour for both: User gets sent to the page specified by initial_page_name value

Here is bug report code (generated from page_router page):

IT4shvHlvM9Oj7xE0JP5be57/SY7NW5+ROcKscp/bxIgGIDzPOw+ZPWkZRJCTdTgYX9iJESmmkcG/sLTvuztUPA4PSmZfbpfws1qFgvKZGamQZOBO5bhWGslAcdjG2qB5p+rkSJ7IutpW0Ie2UOqJu+/UjPXQa7NImdISq/LZO4=

[taggxyz]

@mmearly I too am facing the same issues as @byrondowns - unfortunately this hasn't solved the issue for me either.

[mmearly]

@byrondowns Would it be okay if I sent some test notifications on this project to try to diagnose the issue?

@taggxyz Could you also send a bug report code and would it be okay for me to send some test notifications on this project too?

[Unity2Blender]

Thanks for this new Current Route Property.

[byrondowns]

@mmearly go for it. Just please don't send test notifications to all users, as this is a live app with real users on it.

Sending to test users is fine, lmk if you want discuss/test/brainstorm over a call. Email is byron@knit.homes

[bdonovan858]

@mmearly I'm experiencing a similar issue to @byrondowns. I too have a "routing_page" which is the default login page. My issue persists with both push notifications and deep links. For example, if a user shares a listing, and the recipient user opens the link, they'll be initially navigated to the listing page, however, if they hit the back button on the listing page (a navigate back action, navigate to root page on failure), they get stuck on the routing screen. The routing conditional logic only navigates them to the home page if "/routing_page" OR "/" are true.

Is there perhaps a different route associated with "navigate back, navigate to root page on failure"?

[mmearly]

@bdonovan858 A couple questions:

• Can you confirm when you say 'if "/routing_page" OR "/" are true', you mean that you are checking that Current Route Path == "/routing_page" OR Current Route Path == "/"? If you are checking "/routing_page" == true OR "/" == true, that will always be false.
• Can you double check that /routing_page is the name of the route and not just the name of the page? You can check the route by going into the Route Settings on the right-side property pannel.
• What behavior do you get if you don't include this condition?

[bdonovan858]

@mmearly, thanks for getting back to me, and sorry for not being more clear in my first note. To answer your questions:

1. Correct, I mean that I am checking that Current Route Path == "/routing" OR Current Route Path == "/" are true (screenshot attached), not just "/routing" OR "/" are true.

2. I misspoke in my last message, the page is called routing, not routing_page. Nonetheless, I can confirm that "/routing" is the name of the route not just the page (screenshot attached)

3. If I don't include this condition, when a user receives a deep link or push notification to a specific listing page and they click the link/notification, the app initially opens the correct listing page. However, about ~1000ms later, the app redirects them to the routing page, which then executes logic that usually sends them to the home page (but can vary depending upon the user's stage in onboarding).

Note, my routing page executes correctly when not opening from a deep link (just a normal cold reboot/initialization) so my thought was that when accessing the listing page via a deep link or push notification, pressing 'Navigate Back' (with the 'Navigate to Root Page on Failure' toggle enabled) might be triggering a different route path than expected?

Thanks for your help.