Play Framework: clear Flash scope when going back - scala

I'm using scala 2.11.8 and Play Framework 2.3. I am submitting a form and managing the result through a controller. The controller returns a Redirect to a page flashing a certain message, either a success or an error message:
Redirect(routes.MyController.page).flashing("success" -> "All went well")
I then manage this message using javascript, so it can be seen in a modal:
#flash.get("success").map { message =>
<script type="text/javascript">
modalSuccess('#message');
</script>
}
All goes well, the modal is shown. Next I navigate to another page and use the Back arrow to go back and the modal is shown again. This is, of course, very weird for the user: he has just clicked back, it makes no sense that he sees a "All went well" message.
Previously, I passed these messages as parametres to the pages and returned a 200 OK:
Ok(views.html.page(message = "All went well"))
But the exact same thing happened because the request was sent again. I switched to Flash to solve this, but I can't seem to prevent it from showing when returning to the previous page.
Should I clear the Flash scope, or should it clear by itself, once the redirect is executed?

When you click back, by default the browser will serve the page out of its cache, it won't reissue the request, and that is what is happening here, it has nothing to do with Play.
There is no standard for how the browser back button behaves, in particular with regards to caching, so solving it isn't straight forward because all the browsers behave differently. This SO question/answer covers it fairly comprehensively:
How to control web page caching, across all browsers?
But be aware of the drawbacks, if you tell the browser it must never cache pages, you can end up giving users a poor experience, for example, if they are filling out a form, and they accidentally navigate away, and then click back so they can continue filling out the form, if you force the browser now to cache the page they will lose everything that they entered into the form.
Also, what if the reason they are clicking back is that they want to see the rendered model again? When users click back, they expect to see the page that they were just on, just as it was. If you change that, you're breaking their expectations. I wouldn't be happy if that happened to me - I hate it when I click back and I get a different page, you're probably going to upset your users if you do it.

Related

Mobile form on website is not sending on the first click of "submit"

this is kind of a weird issue I'm having with a site's form when viewed on an iPhone5. When somebody fills in the information and tries hitting submit, it refreshes the page with all of the content still on the page but none of the tasks triggering. No errors or warnings are shown. When the user clicks submit again, the form works as intended.. so the first click doesn't seem to be working.
I don't own an iPhone5, but I tried this on both Safari and on my DROID4 (which both worked fine).
The site is built with DotNetNuke version 6, ASP.net, the forms are a module called DynamicForms, though I don't know if that information is needed.
Any help is greatly appreciated.
Your best bet would be to get in touch with the good folks at Data Springs, the creators of the Dynamic Forms module. They provide really good support.
I'm not sure what triggers you have, but that sounds like the browser for the device isn't actually doing the event. As for a potential work around, in your skin but this:
$(function () {
$(".SubmitButtonAnchor").click(function () {
if(window.confirm(location.href)) {
window.location = "http://bing.com";
}
});
});
The above example should anchor to your input button and do the following:
When you Submit it will prompt you of the page it is attempting to navigate to.
The ability to say "Yes" or "No".
Then navigate to the page.
This should bypass some issues you may be experiencing currently, I'd still let them know that it isn't working as intended.

Facebook - click on a like button does not increase the like count

After searching the internet and doing my own research on this subject I still can not find the answer to my problem, so here it is.
When I click the like button (to like my website http://openarchitecture.cz) then the like count is not being increased.
Debugging the FB javascript code on client-side (in Chrome) and examining the ajax response
send back from FB servers after the click on "Like" button, revealed that FB is instructing the Like button to be "disconnected", resulting in the behaviour described below.
The term "disconnected" is a strict FB term (in a sense of a javascript code), it means that on client-side there will be used a "plugin" that will perform certain operations leading to "inactivity" of like button. Technically, when the plugin "disconnect" is beeing recognized as part of the ajax response, there is an array of predefind actions (functions) that will be followed and called sequentially.
Now for the reproducibility of the problem.
Go to http://developers.facebook.com/docs/reference/plugins/like and fill the "URL to Like" field with http://openarchitecture.cz
url.
Click "Get code", then click "Ok" on the pop-up and finally click "Like" button on the right.
The like count should increase. Instead a pop-up shows up for (aprox.) 1 sec.
then the popup disappears. Now I am in the same state as before I click the
like button, i.e. like count is not increased.
I have found similar questions here on SO, but none of them seems to finally
resolve the issue.
The related questions here on SO are:
1. http://facebook.stackoverflow.com/questions/5195183/facebook-like-button-flashing-on-then-off/12958474#12958474
2. Facebook Like button does not work on one website?
One of the suggestions was that this migth actually be a FB bug. I found a (very recently created) bug, reported in FB bug tracking system. The bug is located here:
http://developers.facebook.com/bugs/268340209965207?browse=search_512b8e0bed9724580954683
The bug has however "Low" priority an so far it does not seem to be resolved (it might even be returned as not a FB issue, I am not sure if this possibility is still open).
So for all interested in this.
Is this a real FB bug ?
How have you dealt with this ?
Could it be that my site is for some reason on FB spam/black/"whatever nasty" list ?
Well. This will end up like the other posts, i.e. no lesson learned here.
[The term "page" used later in this post represents the http://openarchitecture.cz page]
I just tried today to like the page again via the FB generated like button (on http://developers.facebook.com/docs/reference/plugins/like/ ) and the result is now ok. So the like count gets increased after clicking the like button.
The difference that I observed when checking the request exchange to FB servers is that this time the communication has been done (by default. i.e. using the XFBML version of the like button) over iframe, not direct ajax call (as was in the past for XFBML).
I dont know what was the cause (I tried the pure iframe version of like button before) but the response going back as a result of the mentioned iframe request is now correct, ie. FB sends back response instructing javascript in client browser to use "connect" plugin not "disconnect" plug-in.
One more thing. One month ago I have created a FB profile (http://www.facebook.com/pages/Openarchitecture/125515934292877) of the page and have done some updates to this profile. So maybe FB decided that the page (being referenced from FB profile) has now earned the provilige to be "liked".
Like I said at the beginning. Problem solved, but no lesson learned.
For me, the problem (Like popup disappearing after a second; "Plugin","disconnect" response) was happening when the Like button URL redirected to another URL.
The fix was to add og:type, og:url, and og:title (required per https://developers.facebook.com/docs/reference/opengraph/object-type/website), then running the URL through the Facebook debugger to clear the cache (https://developers.facebook.com/tools/debug).
More at https://stackoverflow.com/a/16597060/2391566 .

Facebook Like button doesn't show up anymore

I implemented the like-button on the page http://www.racket-center.de on every subpage of this site. I noticed that it didn't show up on every page so I tried different implementation-versions (html5, iframe etc) but it didn't work. If I remember correctly the more I tried the less pages the button appeared on.
Now the button doesn't show up anymore – not even within the wizard at http://developers.facebook.com/docs/reference/plugins/like/ You can try it yourself: if you enter the URL of the site + then change another option to get the wizard checking the url the like-button will disappear.
I tried to debug via the linter and fixed some minor warnings it complained (e.g. adjusting the og:image-size to fit 200x200px) but that didn't bring back the button.
I guess the page is kind of blacklisted but I don't know + if it was blacklisted I don't know why.
Does anybody have a clue what might be going on here or kind point me to any resource about fb's blacklists?
Would be nice to get some help.
Thx,
Michael

Tab Content Does Not Refresh After First Click of Like Button

I've implemented a very simple "like guard" for a facebook tab, and am running into an issue with my test users. Multiple testers are reporting that when they open a tab and click the "like" button, they do not always get a page refresh (so the like guard does not disappear until they do a manual reload). This is using facebook's like button at the top of the page, not one I've coded up myself.
As a sanity check, I enabled some simple logging on my server and have been able to recreate the issue - I hit "like" or "unlike" but there seems to be no request made to my index.php page, so definitely no refresh happening.
I'm aware of this old bug https://developers.facebook.com/bugs/228778937218386 but this one seems different. For starters, after the first click of the "like" button, if I just continue clicking unlike/like/.... then the refresh happens automatically, as expected. What's especially weird is that if I reload the page after the first failed refresh, the refreshes start working again as expected, ie the first update to my like status triggers a page refresh.
Some possibly (?) relevant info:
My Tab is part of a test page, and is unpublished
I am only using http hosting for the tab content, since my https isn't set up yet
So far I've just tested with other admins - so maybe user role affects this?
Curious to see if anyone has run into this issue before.
Finally settled this problem, sharing in case others run into the same issue:
My confusion was caused by where I created/assigned my testers. I made a dummy community page to host the tab I was building and I added all my testers to the test community page. I realized that the only users not getting the weird refresh problems were those testers who I had also added as admin/testers for the app itself. Apparently, adding them as testers to your community page is not enough, and rather than giving you some kind of warning when they view your tabs, testers just get this buggy refresh behavior.

google analytics receiving data vs. redirecting that causes NS_BINDING_ABORTED

Okay so first off, sorry if the title doesn't make much sense...I'm not sure how else to summarize it!
So here's the issue:
I am using jQuery to attach a click event to my form's submit button. The jQuery click event triggers some GA code to track a virtual page view so I can use it as a step in a Goal funnel.
But what happens is that there's no delay between the GA code executing and the submit, so I'm concerned that GA isn't actually getting the data.
When I look at what's happening in firebug or httpfox (browser addons that look at the requests/response) vs. charles proxy (external sniffer, separate from browser) I am seeing two different things.
With firebug/httpfox I see the GET request to GA but status of 0 and it is showing up as
(Aborted) NS_BINDING_ABORTED
...though it does show bytes having been sent etc.. just nothing for response.
But with charles proxy, I am seeing the same GET request with a status of 200 and the 1x1 pixel response.
So my theory here is that GA is receiving the data, but that the browser is moving on before it gets the actual response - which I'm okay with, as long as GA is getting the data, I'm okay with this. But it is just my theory and I don't know...
I know I can write the code to simply delay the execution of the submit by 500ms or whatever as insurance, but I don't wanna have to do that if it's not necessary..
And I know if nothing else I can just see if the data is showing up in GA but GA has a 24-48 hour delay on data so it is hard to QA.
Does anybody know or have any suggestions from experience...has anybody else experienced this "abort" thing and can say one way or the other if it is necessary to delay the submit or whatever?
HTTPFox is not a real sniffer. It just tries to mimic one. So the data you see on it is not always what is really happening in the background. Charles should get you a better picture. If you're seeing the 200 code in Charles. So the chances are that the hit is going through.
The bad news is that when you fire hits at the time the page unloads. (Outbound clicks, insite link clicks, form submissions, window.unload, etc) they won't go through every now and then. This happens because the Google Analytics JS Call basically appends a GIF to the page. And it returns after that. Than the browser will load the gif. When the code returns the browser is free to go, and if it goes away from the page it will cancel any pending requests that it may have, including that small GIF image. So the browser might haven't sent the tracking code, or might have sent it, but the TCP connection didn't go through and the browser would need to resend the package, but he's not willing to do it anymore.
So if accuracy is a need for you, you should add a 200-500 ms delay to it. But remember that Google analytics is not an Accuracy Tool, and if some events don't go through it won't probably affect the final outcome of your analysis.
According to the informatin on this page: Sending Data to Google Analytics there is a possibility that your data is not really being sent (the bad news, as Eduardo said). Transcribing the most important information of that page, related to your doubts:
Many browsers stop executing JavaScript as soon as the page starts
unloading, which means your analytics.js commands to send hits may
never run.
An example of this is when you want to send an event to Google
Analytics to record that a user clicked on a form's submit button. In
most cases, clicking the submit button will immediately start loading
the next page, and any ga('send', ...) commands will not run.
The solution to this is to intercept the event to stop the page from
unloading. You can then send your hit to Google Analytics as usual,
and once the hit is done being sent, you can resubmit the form
programmatically.