Reload-blindout after facet filter change occasionally hangs when using browser's "back" button (species search)
10536
Reporter: ahahn
Assignee: jcuadra
Type: Bug
Summary: Reload-blindout after facet filter change occasionally hangs when using browser's "back" button (species search)
Environment: Firefox 8.0, Win 7
Priority: Trivial
Resolution: Fixed
Status: Closed
Created: 2011-12-16 10:21:28.112
Updated: 2013-08-29 14:44:52.926
Resolved: 2013-01-31 15:03:38.197
Description: After setting a number of facet filters and watching their effect, a user may use the "back" button of the browser rather than removing individual facets again in order to go back to a previous filter result. Doing so, the status of the filtered data is indeed rolled back, but the semi-opaque "blind that displays while a facet value is applied keeps hanging in, so that no page entries can be selected. It disappears on page reload, though.
]]>
Author: kbraak@gbif.org
Created: 2013-01-03 16:29:51.52
Updated: 2013-01-03 16:30:29.337
I can only reproduce this issue in Firefox, not in Chrome.
To reproduce this issue:
1) Enter http://staging.gbif.org:8080/portal-web-dynamic/species/search?q=Grapsus&STATUS=SYNONYM&DATASET_KEY=d7dddbf4-2cf0-4f39-9b2a-bb099caae36c into Firefox
2) Click Higher Taxon filter "Decapoda"
3) Click the "Back" button. Notice the Checklist and Higher Taxon checkboxes are disabled. GBIF Backbone checkbox is checked, that's fine. The Animalia checkbox, however, is checked which it shouldn't be.
After my tests, I suspect Firefox is doing something wrong, automatically disabling checkboxes. There is no code in the freemarker template responsible for disabling checkboxes (see facets.ftl), that's why I suspect it is the browser's fault. A pattern also emerges which is really strange:
If I repeat 2) and 3) first choosing "Animalia", then "The Catalogue of.." under checklists is wrongly selected. There are exactly 3 filters separating these filters.
If I repeat 2) and 3) first choosing "Anthropoda", then "English Wikip.." under checklists is wrongly selected. There are exactly 3 filters separating these filters.
If I repeat 2) and 3) first choosing "Malacostraca", then "Interim Regis.." under checklists is wrongly selected. There are exactly 3 filters separating these filters.
If I repeat 2) and 3) first choosing "Grapsidae", then "Arthropoda" is wrongly selected. There are exactly 3 filters separating these filters.
If I repeat 2) and 3) first choosing "Grapsus", then "Malacostraca" is wrongly selected. There are exactly 3 filters separating these filters.
Author: mdoering@gbif.org
Comment: In addition to the hanging problem we have also other trouble with the back button on Safari and apparently also Opera. When doing the above and hitting back the checkboxes and also the results page stays the same, not removing the last added higher taxon group filter (and showing the wrong, filtered resultset).
Created: 2013-01-07 11:47:09.074
Updated: 2013-01-07 11:47:09.074
Author: kbraak@gbif.org
Created: 2013-01-09 17:15:23.31
Updated: 2013-01-09 17:20:26.03
Thanks for the great find and commit Fede.
Status across browsers after the commit:
Chrome: Working
Safari: Working
Firefox: Working for Fede / Not working for me with Firefox 18.0 Mac OS X - the spinning icon freezes. [~mdoering@gbif.org] Can you please try in Firefox with steps 1-3 in the issue description?
Opera: Not working, the Back button has no effect.
Author: jcuadra@gbif.org
Comment: In Firefox 16.0.2, under Mac 10.5.8, it does not work. The spinning icon freezes when the BACK button is hit.
Created: 2013-01-14 16:51:59.179
Updated: 2013-01-14 16:51:59.179
Author: jcuadra@gbif.org
Created: 2013-01-23 16:56:00.776
Updated: 2013-01-23 16:57:16.65
I would like to provide an update and if somebody could give me a helping push here, as Im stuck right now.
I've tried to create an struts Interceptor which sole purpose is to clear the cache and might solve Firefox's problem. This interceptor would be only applied to search pages (species, occurrences, datasets) I did it and it solved the Firefox issue. but now I get a new problem with Chrome argg
once I do the 2nd search, and I press the BACK button on Chrome, I get a
{code:title=Error|borderStyle=solid}
This webpage has a redirect loop
The webpage at https://cas.gbif.org//login?service=http%3A%2F%2Flocalhost%3A8080%2Fspecies%2Fsearch%3Fq%3DGrapsus%26STATUS%3DSYNONYM%26DATASET_KEY%3Dd7dddbf4-2cf0-4f39-9b2a-bb099caae36c&gateway=true
has resulted in too many redirects.
Clearing your cookies for this site or allowing third-party cookies may fix the problem.
If not, it is possibly a server configuration issue and not a problem with your computer.
{code}
What it happens is that when I press BACK, it does not go straight to the last search, but instead it calls again the CAS proxy and then CAS should redirect to the page. This is when I get the "redirect loop" problem. This does not happen on Safari or Firefox, and I am not sure why. Also, if I log into CAS and do the same procedure in Chrome, it works!
so basically it doesnt work when doing a BACK request, on Chrome, when not logged in.
Any ideas or anything worth trying? If I remove all cache headers, then works in Safari, Chrome but not Firefox.
Author: mdoering@gbif.org
Created: 2013-01-24 11:04:28.397
Updated: 2013-01-24 11:11:17.223
Jose, where is the code for the interceptor and how do you ??clear the cache?? ?
The CAS redirect URL should not have been executed by the browsers back button directly, but is likely to be executed through CAS filters. Can you trace exactly which calls are done from where?
Author: jcuadra@gbif.org
Created: 2013-01-24 11:12:12.578
Updated: 2013-01-24 11:12:12.578
Here's the interceptor
{code}
public class ClearCacheInterceptor extends AbstractInterceptor {
@Override
public String intercept(final ActionInvocation invocation) throws Exception {
HttpServletResponse response =
(HttpServletResponse) invocation.getInvocationContext().get(StrutsStatics.HTTP_RESPONSE);
response.setHeader("Cache-Control", "no-store, no-cache, must-revalidate, max-age=0");
response.setHeader("Pragma", "no-cache");
return invocation.invoke();
}
}
{code}
The *no-store* value is seemingly the one giving trouble on Chrome. Once I remove it, Chrome works, but not Firefox.
Author: mdoering@gbif.org
Created: 2013-01-24 11:18:31.347
Updated: 2013-01-24 11:18:31.347
Maybe related to our use of javascript?
http://stackoverflow.com/questions/6784663/implemented-post-redirect-get-now-cant-use-back-button
??
If you're trying to do it in Javascript, location.replace(url) navigates to a new URL while replacing the current URL in the browsing history.
??
Wanna try adding the new URL manually to the browser history?
https://developer.mozilla.org/en-US/docs/DOM/Manipulating_the_browser_history
Author: jcuadra@gbif.org
Created: 2013-01-24 17:52:53.371
Updated: 2013-01-24 17:52:53.371
Markus, do you know of an easy way to tell CAS to keep the original HTTP HEADERS from the original request? From the snippets, Im gonna show the response headers after each request URL.
http://localhost:8080/species/search?q=Grapsus&STATUS=SYNONYM&DATASET_KEY=d7dddbf4-2cf0-4f39-9b2a-bb099caae36c
{code}
Cache-Control:no-cache, no-store, must-revalidate, max-age=0
Content-Type:text/html;charset=UTF-8
Expires:0
Pragma:no-cache
Server:Jetty(8.1.8.v20121106)
Transfer-Encoding:chunked
{code}
https://cas.gbif.org//login?service=http%3A%2F%2Flocalhost%3A8080%2Fspecies%2Fsearch%3Fq%3DGrapsus%26STATUS%3DSYNONYM%26DATASET_KEY%3Dd7dddbf4-2cf0-4f39-9b2a-bb099caae36c&gateway=true
{code}
Cache-Control:no-cache
Cache-Control:no-store
Connection:close
Content-Length:0
Content-Type:text/plain; charset=UTF-8
Date:Thu, 24 Jan 2013 16:14:28 GMT
Expires:Thu, 01 Jan 1970 00:00:00 GMT
Location:http://localhost:8080/species/search?q=Grapsus&STATUS=SYNONYM&DATASET_KEY=d7dddbf4-2cf0-4f39-9b2a-bb099caae36c
Pragma:no-cache
Server:Apache/2.2.15 (CentOS)
{code}
http://localhost:8080/species/search?q=Grapsus&STATUS=SYNONYM&DATASET_KEY=d7dddbf4-2cf0-4f39-9b2a-bb099caae36c
{code}
Content-Length:0
Expires:Thu, 01 Jan 1970 00:00:00 GMT
Location:https://cas.gbif.org//login?service=http%3A%2F%2Flocalhost%3A8080%2Fspecies%2Fsearch%3Fq%3DGrapsus%26STATUS%3DSYNONYM%26DATASET_KEY%3Dd7dddbf4-2cf0-4f39-9b2a-bb099caae36c&gateway=true
Server:Jetty(8.1.8.v20121106)
Set-Cookie:JSESSIONID=upaqwsvl43fiytj67cs88h1k;Path=/
{code}
Author: jcuadra@gbif.org
Created: 2013-01-31 12:28:50.025
Updated: 2013-01-31 12:28:50.025
Finally, I've made a fix that has not meant adding any interceptor. Just a simple javascript addition to the species search (which seems to be the only one having this BACK button trouble)
Details here
https://code.google.com/p/gbif-portal/source/detail?r=1334
I have been testing this on safari, firefox, chrome and all work fine. If nobody raises more issues, I can close this jira issue.
[~kbraak@gbif.org]