Bug: Browser back button from Detail to List screen misbehavior

Bug: Browser back button from Detail to List screen misbehavior

  

I used standard scaffolded List and Detail screen.

Here's the scenario:

1. In the List screen navigate to page 2 (reduce the line count to test)

2. Click on link to go to Detail screen.

3. Click Cancel button

4. Landed back on List screen on page 2 (it remember the previous page)

5. Now navigate to another different page (eg: page 1)

6. Click on link to go to Detail screen

7. Click the browser back button

8. Landed back on List screen on page 2 (while it should be on page 1).

9. Interestingly if you back on page 1 then click the link to Detail screen, then click Cancel button, then click on Detail screen again, then click on Browser back button, it will correctly landed on Page 1. Cancel button makes it remembers the page.


I know somebody will said to me don't use browser back button then.

I know that browser back button is @#$%^, but it might be a bug that can be fixed.

Is this similar as documented here

Hi Harlin,


how did you solve the problem? 

Did you implement the solution that Armando referred?


Regards,

Nuno

Hi

I have encountered the 'page not running the preparation on back button' problem. I was able to solve it in the following way: (I think I got the idea from a previous post, but I do not have the URL saved)

  1. Place an input widget somewhere on the page where it will definitely be generated (not on an if, or within a container that might have visible set to false, otherwise the widget will not be rendered)
  2. Set the input name (NeedToReload for example)
  3. Set an extended property: type:hidden
  4. Create a text variable with a default text of "NO". Set the input source to this variable
  5. Add an unescaped expression with the following JS:               

      "<script>
       $(document).ready(function() {
           if("+NeedToReload.Id+".value== 'NO'){
              "+NeedToReload.Id+".value= 'YES';
           } else {
             location.reload(true);
          }
       });

      </script>"

This will basically force the page to reload (therefore re-running the preparation) if the back button was pressed (since the variable's text will be YES because it is coming from a saved state)


Hope this helps someone!


Regards,

   - CLSJ



Nuno Rocha wrote:

Hi Harlin,


how did you solve the problem? 

Did you implement the solution that Armando referred?


Regards,

Nuno

I haven't implemented it, instead I encourage users to use Cancel/Back button instead.


Carlos Lopez S. Jacome wrote:

Hi

I have encountered the 'page not running the preparation on back button' problem. I was able to solve it in the following way: (I think I got the idea from a previous post, but I do not have the URL saved)

  1. Place an input widget somewhere on the page where it will definitely be generated (not on an if, or within a container that might have visible set to false, otherwise the widget will not be rendered)
  2. Set the input name (NeedToReload for example)
  3. Set an extended property: type:hidden
  4. Create a text variable with a default text of "NO". Set the input source to this variable
  5. Add an unescaped expression with the following JS:               

      "<script>
       $(document).ready(function() {
           if("+NeedToReload.Id+".value== 'NO'){
              "+NeedToReload.Id+".value= 'YES';
           } else {
             location.reload(true);
          }
       });

      </script>"

This will basically force the page to reload (therefore re-running the preparation) if the back button was pressed (since the variable's text will be YES because it is coming from a saved state)


Hope this helps someone!


Regards,

   - CLSJ



This methods seem to me has to be incorporated into Outsystems, so user transparently benefit from this.