[Awaiting Checklist] [Due for payment 2025-08-29] [$250] Chat - App back button from "Hmm Not Here" page navigates to Reports with error message

[jponikarchuk]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: v9.1.51-6
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from TestRail: N/a
Email or phone of affected tester (no customers): Slottwo1 1982t@gmail.com
Issue reported by: Applause Internal Team
Device used: Redminote 10s android 13
App Component: Chat Report View

Action Performed:

1. Go to https://staging.new.expensify.com/home
2. Open a chat
3. Send the link - https://staging.new.expensify.com/edit/submit/description/8371724703650691128/2774337950294908/?backTo=%2Fsearch%2Fview%2F7406454132531793%2F%3FbackTo%3D%252Fsearch%253Fq%253Dtype%25253Aexpense%252520status%25253Aall%252520sortBy%25253Adate%252520sortOrder%25253Adesc%%%
4. Tap on the link
5. In hmm not here page, tap device back button
6. Note user directed to correct conversation page
7. Again from hmm not here page, tap app's back button
8. Note user directed to reports page showing oops something went wrong message
9. Go to troubleshoot - clear cache
10. Tap reports
11. Reports default page shown briefly and updated to oops something went wrong page

Expected Result:

Pressing either the device back button or the app’s back button on the "Hmm Not Here" page should consistently navigate the user back to the previous the conversation page.

The Reports page should load correctly without showing the "Oops, something went wrong" message after clearing cache.

Actual Result:

After tapping the link in chat, the "Hmm Not Here" page opens.

Pressing the device back button on the "Hmm Not Here" page correctly directs the user back to the conversation page.

Pressing the app’s back button on the "Hmm Not Here" page directs the user to the Reports page showing an "Oops, something went wrong" error message.

Clearing cache and tapping Reports briefly shows the default Reports page before updating to the error message page.

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

1.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021927407930524949861
• Upwork Job ID: 1927407930524949861
• Last Price Increase: 2025-07-22
• Automatic offers:
• huult | Contributor | 108213611

Issue Owner

Current Issue Owner: @garrettmknight

[melvin-bot]

Triggered auto assignment to @garrettmknight (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~021927407930524949861

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @sobitneupane (External)

[Malkiel0]

Proposition technique pour le problème #62821 d'Expensify

Cause probable
Après analyse, je soupçonne que ce problème est lié à une incohérence dans la gestion de l'historique de navigation entre le bouton retour natif du dispositif et le bouton retour personnalisé de l'application.

La cause probable est une mauvaise gestion du paramètre backTo dans l'URL ou une incohérence dans la pile de navigation (navigation stack) lorsque l'utilisateur navigue via un lien profond (deep link) contenant des paramètres de redirection complexes.

Solution proposée
Je propose d'implémenter les modifications suivantes :

Analyser et normaliser la gestion du bouton retour personnalisé :
Identifier le composant responsable du bouton retour de l'application
Assurer que ce composant utilise la même logique de navigation que le gestionnaire de bouton retour du dispositif
Corriger la gestion des URL complexes avec paramètres backTo :
Implémenter une fonction de parsing d'URL robuste qui extrait correctement les paramètres de redirection imbriqués
Normaliser le traitement des URLs avec des paramètres backTo multiples ou imbriqués
Synchroniser l'historique de navigation :
S'assurer que l'historique de navigation React Native et l'historique du bouton retour personnalisé sont synchronisés
Ajouter une validation des routes de destination avant la navigation pour éviter les erreurs
Implémenter une validation des états de navigation :
Vérifier que la route de destination est valide avant d'y naviguer
Ajouter une gestion de secours (fallback) pour rediriger vers une page sécurisée en cas d'erreur de navigation
Implémentation technique détaillée

Examiner et modifier le gestionnaire de navigation :

// Localiser le gestionnaire de navigation personnalisé pour le bouton retour
// Probablement dans un fichier comme src/libs/Navigation.js ou un composant Header

/**
 * Gestionnaire amélioré pour le bouton retour de l'application
 * Analyse avec précision les paramètres de l'URL pour assurer une navigation cohérente
 * @param {Object} route - La route actuelle
 * @param {Object} navigation - L'objet de navigation
 * @returns {void}
 */
const handleAppBackButton = (route, navigation) => {
    // Récupérer les paramètres de l'URL actuelle
    const currentParams = route.params || {};
    
    // Analyse approfondie du paramètre backTo s'il existe
    if (currentParams.backTo) {
        try {
            // Décoder l'URL de retour qui pourrait contenir des paramètres imbriqués
            const decodedBackTo = decodeURIComponent(currentParams.backTo);
            
            // Analyser l'URL pour extraire le chemin et les paramètres
            const { path, queryParams } = parseBackToUrl(decodedBackTo);
            
            // Vérifier si la route de destination est valide
            if (isValidRoute(path)) {
                // Naviguer vers la route de retour avec les paramètres appropriés
                navigation.navigate(path, queryParams);
                return;
            }
        } catch (error) {
            // Journaliser l'erreur pour le débogage
            console.error('Erreur lors de la navigation de retour:', error);
        }
    }
    
    // Comportement de secours : revenir à l'écran précédent dans la pile de navigation
    // Cette logique devrait correspondre au comportement du bouton retour du dispositif
    navigation.goBack();
};

Améliorer le parsing des URL avec paramètres backTo imbriqués :

/**
 * Parse une URL avec des paramètres backTo potentiellement imbriqués
 * Supporte les redirections multiples (backTo dans backTo)
 * @param {string} url - L'URL à analyser
 * @returns {Object} Un objet contenant le chemin et les paramètres de requête
 */
const parseBackToUrl = (url) => {
    // Extraire le chemin principal et les paramètres de requête
    let [path, queryString] = url.split('?');
    
    // Retirer les barres obliques initiales et finales pour normaliser
    path = path.replace(/^\/+|\/+$/g, '');
    
    // Convertir les paramètres de requête en objet
    const queryParams = {};
    if (queryString) {
        const searchParams = new URLSearchParams(queryString);
        searchParams.forEach((value, key) => {
            // Traitement spécial pour les paramètres backTo imbriqués
            if (key === 'backTo') {
                queryParams[key] = decodeURIComponent(value);
            } else {
                queryParams[key] = value;
            }
        });
    }
    
    return { path, queryParams };
};

Ajouter une validation des routes pour éviter les erreurs :

/**
 * Vérifie si une route est valide avant de tenter d'y naviguer
 * @param {string} routeName - Le nom de la route à vérifier
 * @returns {boolean} Vrai si la route est valide
 */
const isValidRoute = (routeName) => {
    // Liste des routes valides dans l'application
    const validRoutes = [
        'Home', 
        'Report', 
        'ReportDetails',
        'Search',
        'chat',
        // Ajouter toutes les routes valides ici
    ];
    
    // Convertir le nom de la route en un format standard
    const standardizedRouteName = routeName
        .replace(/^\/+|\/+$/g, '')  // Supprimer les barres obliques
        .split('/')[0];  // Prendre le premier segment
    
    // Vérifier si la route est dans la liste des routes valides
    return validRoutes.includes(standardizedRouteName);
};

Corriger le comportement spécifique sur la page "Hmm Not Here" :

/**
 * Composant de la page "Hmm Not Here"
 * Assure une gestion cohérente de la navigation pour les boutons de retour
 */
class NotFoundPage extends React.Component {
    componentDidMount() {
        // Configuration du gestionnaire de retour pour Android
        if (Platform.OS === 'android') {
            BackHandler.addEventListener('hardwareBackPress', this.handleBackPress);
        }
        
        // Stocker la route de retour correcte dans l'état local
        this.storeCorrectBackRoute();
    }
    
    componentWillUnmount() {
        if (Platform.OS === 'android') {
            BackHandler.removeEventListener('hardwareBackPress', this.handleBackPress);
        }
    }
    
    /**
     * Extrait et stocke la route de retour correcte à partir des paramètres d'URL
     */
    storeCorrectBackRoute = () => {
        const { route } = this.props;
        const currentParams = route.params || {};
        
        // Stocker la destination de retour correcte pour une utilisation ultérieure
        if (currentParams.backTo) {
            try {
                const decodedBackTo = decodeURIComponent(currentParams.backTo);
                this.correctBackRoute = parseBackToUrl(decodedBackTo);
            } catch (e) {
                console.error('Erreur lors du parsing de backTo:', e);
                this.correctBackRoute = null;
            }
        }
    }
    
    /**
     * Gestionnaire pour le bouton retour matériel
     * @returns {boolean} Vrai si l'événement est traité
     */
    handleBackPress = () => {
        this.navigateBack();
        return true; // Empêche la propagation de l'événement
    }
    
    /**
     * Fonction de navigation commune utilisée par les boutons retour
     * de l'application et du dispositif
     */
    navigateBack = () => {
        const { navigation } = this.props;
        
        // Si nous avons une route de retour correcte, l'utiliser
        if (this.correctBackRoute && isValidRoute(this.correctBackRoute.path)) {
            navigation.navigate(
                this.correctBackRoute.path,
                this.correctBackRoute.queryParams
            );
        } else {
            // Comportement par défaut: retour à la conversation ou à l'écran précédent
            navigation.goBack();
        }
    }
    
    /**
     * Gestionnaire pour le bouton retour de l'application
     * Utilise la même logique que le bouton retour du dispositif
     */
    handleAppBackButton = () => {
        this.navigateBack();
    }
    
    render() {
        return (
            <View style={styles.container}>
                <Header
                    title="Hmm Not Here"
                    onBackPress={this.handleAppBackButton} // Utiliser notre gestionnaire personnalisé
                />
                <View style={styles.content}>
                    {/* Contenu de la page "Hmm Not Here" */}
                    <Text>Cette page n'existe pas.</Text>
                </View>
            </View>
        );
    }
}

[sobitneupane]

Thanks for the proposal @Malkiel0

Could you please take a moment to go through our contributing guidelines and update your proposal using the provided template?

[LorenzoBloedow]

The link is redirecting to that page because of the malformed backTo query parameter in the URL given in the repro steps. It's not being properly encoded:

The first call to decodeURIComponent is the regular URL from Expensify and the other one is the URL given in step 3 (modified for dev env).

So the question we need answered by the QA team to be able to properly fix this bug is where did that URL come from?
When we know that, we'll be able to fix the code that generates that URL (which I'm assuming is being returned by Expensify and not handcrafted).

What I could likely propose at the moment is how to fix the report page "remembering" the error page from the malformed URL.
But if we could know where this URL came from it'd be a much better proposal because it would fix the two root problems being shown here.

@sobitneupane I can't directly communicate with the QA team, if possible could you please ask where the URL came from? Thank you :)