Cache error with filtered list and back button

[troester]

Very ugly:
If a list is filtered the "Back" button in form and details (or browser back) is throwing a cache error,
e.g. in Chrome

Confirm Form Resubmission​

This webpage requires data that you entered earlier in order to be properly displayed. You can send this data again, but by doing so you will repeat any action this page previously performed​

Reload this webpage.​

Press the reload button to resubmit the data needed to load the page.​

Error code: ERR_CACHE_MISS​

then on reload you get an alert:

The page that your're looking for used informatione that you entered....Do you want to continue?​

No matter if list's advanced "disable caching " is yes or no
Joomla caching is off
no https
list not ajaxfied
Tested with multiple sites on multiple servers with multiple browsers

It's ok if the list is ajaxfied.
(Edit: can this be somehow related to http://www.fabrikar.com/forums/index.php?threads/defect-report-list-details-ajaxify-links.38116/ ?)

If I redo this commit

https://github.com/Fabrik/fabrik/commit/080c6d65ca96366e0ead33fcbc112ac39135e482​

fixed: goback js code, was simply using the http referrer, but this didnt work if you had two back buttons on sequential pages. As we were only using this for https testing, Ive added that check into the code​

the Fabrik Back button is working
but this doesn't solve the browser back.

If going back once more with browser back (instead of reloading the page) it's displaying the filtered list again.
So it seems something is wrong with the history in case of filtered non-ajaxfied lists.

 

[troester]

Still an issue.
See also
http://www.fabrikar.com/forums/index.php?threads/cache-error-on-filtered-list.38730/

 

[troester]

Still an issue.
http://www.fabrikar.com/forums/inde...h-expired-document-on-form-back-button.39241/
Commit was https://github.com/Fabrik/fabrik/commit/080c6d65ca96366e0ead33fcbc112ac39135e482

 

[troester]

Any comment on this one?
It's really an annoying issue.

 

[cheesegrits]

We'll need to get Rob in on this one. It's an artifact of handling things like filtering and navigation as a POST of a form, rather than a GET link. And I'm just not entirely sure what we can do about it.

Raise the issue on our next Skype get together.

-- hugh

 

[troester]

Still an ugly issue.

I assume it's a not (only) a Fabrik problem, I'm pretty sure I've seen this on other Joomla pages, too.

But what was the reason for this commit?
https://github.com/Fabrik/fabrik/commit/080c6d65ca96366e0ead33fcbc112ac39135e482

With the old code at least the Fabrik "Back" button is working (still not the browser back).

 

[rob]

this wont be fixed - its just too much of a change. Its working in the new library code, but thats seperate to anything we'd be adding to fabrik3
Sorry really can't remember what that commit was about

 

[troester]

public static function goBackAction()
{
jimport('joomla.environment.browser');
+    $uri = JUri::getInstance();
-    if (JBrowser::getInstance()->isBrowser('msie'))
+    if ($uri->getScheme() === 'https')
{
$gobackaction = 'onclick="parent.location=\'' . JArrayHelper::getValue($_SERVER, 'HTTP_REFERER') . '\'"';
}
else
{
-    // $gobackaction = 'onclick=\'history.back();\'';
-    $gobackaction = 'onclick="parent.location=\'' . JArrayHelper::getValue($_SERVER, 'HTTP_REFERER') . '\'"';
+    $gobackaction = 'onclick=\'history.back();\'';
}
return $gobackaction;

It's working with ...parent.location..., but history.back() is failing.

https://github.com/Fabrik/fabrik/commit/080c6d65ca96366e0ead33fcbc112ac39135e482

 

[lcollong]

Hi,

I'm experiencing the same problem (also described on the others threads mentioned by Troester). Is there something new apart doing the mod in the source code or using ajaxified list ?

 

[von Horst]

fix or workaround to this issue would be nice

 

[troester]

I've added a pull request https://github.com/Fabrik/fabrik/pull/1497
to redo the commit mentioned.

 

[cheesegrits]

Have you tried it with https, just out of interest?

-- hugh

 

[troester]

https is ok

 

[lcollong]

Not for me.

Hello,

I did a test on a pure https site and it behave the same. Without filtering, the back button (or brower back function) after displaying a record for editing shows back the list without errors. But, if the list is filtered, the back function shows the error.

 

[troester]

back function shows the error

Browser back is failing (it's always doing history.back()) but the Fabrik form "Back" button is working on my https site (doing parent.location)

Can you check in your file \components\com_fabrik\helpers\parent.php (line 1662 in recent GitHub, some lines before in older versions) if it's doing

        if ($uri->getScheme() === 'https')
        {
            $gobackaction = 'onclick="parent.location=\'' . JArrayHelper::getValue($_SERVER, 'HTTP_REFERER') . '\'"';
        }
        else
        {
            $gobackaction = 'onclick=\'history.back();\'';
        }

 

[cheesegrits]

troester's response is what I meant, the form Back button. The browser's back button is always going to fail, without using AJAX. Since we wrote this code, browsers have started blocking going "back" to pages which submitted a form with the POST method. And our filters submit a form with the POSt method. But changing the way they work at this point would be a nightmare. :/

OK, I'll go ahead and merge that PR, and when we run across the usage case it was fixing, we'll find another workaround.

-- hugh

 

[cheesegrits]

Merged.

 

[lcollong]

Indeed. The back button is working.
I do have the exact code Troester mentioned starting at line 1684 (goBackAction).
Does it mean the button will work on http site with this merge ?
BTW what does PR stand for ? ;-)

 

[troester]

PR = pull request (in GitHub).
Yes, with this merge the form back button (not the browser back) should do on http sites, too.
Not sure what will break after the merge. It seems nobody can remember why the code was changed in the old commit.

 

[lcollong]

Thanks all !