What happens if a user leaves the page while its processing via Ajax? Will the processing continue? I use Ajax to display a loading image while it executes a script that could take a long time and am worried if users leave the page, the processing of this script will stop. I want it to contiue whether or not the user is on the page. Is this possible?
I guess if the query is sent to the processing asp/php file and ajax is only waiting for the response, the query is successful.
But I think, you must add a control, like and alert asking if you would like to stay on this page or leave.
What I mean is, try writing a comment or an answer on this page and try to press the back button, an alert will appear.
With this method, you make sure the user doesn't leave before the query is complete.
Related
I have a unique situation over here. I have a button on a form which produces a popup if there are some errors in the form. [I know this is not good practice, but the developers of the product would not be changing that behavior!] The form navigates to a different page if all the required fields are correctly populated. Now, I need to write a script in order to click the "Submit" button on the form which either might produce a popup or navigate to the next page.
I have the used the click_no_wait on the "Submit" button and handled the popup using AutoIt as per Javascript Popups in Watir. Now, if all the information is valid and the form navigates to the next page, I use a delay in the script by following some of the techniques described in How to wait with Watir. I am using a Watir::wait_until() to wait in the script.
Now sometimes because of some network issues, it takes time to go to the next page (report-generation) page when the form is submitted and thus the script fails because of the timeout value specified in the wait_until.
I was wondering whether there is a way to intercept the onload event of the HTML page in Watir, since the onload event isn't fired until the entire page is loaded. By that way I could have an accurate estimate of the timeout value and not experiment with it. Thus, my script will pass 100% rather than say 98% right now.
Thanks for any help on this topic.
You could try setting up a rescue for the time out, then looping a reasonable amount of times (2 or 3?) if it encounters a timeout.
E.g.
# All your button clicking and autoit stuff here
i = 0
begin
b.wait_until{ # the thing you're waiting to happen }
rescue TheSpecificTimeOutException
# Sorry I can't remember it, the command prompt will tell you exactly
# which one
if i < 3
i += 1
retry
else
raise
end
end
I'm sure i'll have messed something up in the above, or there'll be more concise ways of doing it, but you get the idea. When it times out, give it another few tries before giving up.
I'm using TempData to show a message to the user. I put a string in the TempData and later I read the string, and if it is not empty, then I show a DIV that contain the message.
All works fine, and if the user refresh the page the message are not shown (Thats what I want). The problem is that if the user navigate to other page and then press the back button in the browser, then the message are shown again, and I do not want this.
What could I do to avoid this behaviour?
Thanks.
This is the code I use to read the TempData (Razor + VB). There is a DIV #commonMessage, with this code I put the string inside the div and show it. As I said before, it's working, but the only problem is that the TempData is still there if the user click back in the browser.
#If Not IsNothing(TempData("MessageUser")) AndAlso TempData("MessageUser") <> String.Empty Then
Dim str As String = TempData("MessageUser")
#<script type="text/javascript">
$(document).ready(function () {
$('#commonMessage').html("#str");
$('#commonMessage').delay(400).slideDown(400).delay(4000).slideUp(400);
})
</script>
End If
EDIT: Seems like the TempData are being catched, because if I Disable the cache for the action where I'm showing the message (Using the Attribute System.Web.Mvc.OutputCache(NoStore:=True, Duration:=0, VaryByParam:="*")) the problem dissapears. But It would be better I we could find a method that not involve disabling the cache...
REQUESTED EDIT: I'm very newby in ASP, so I try to clarify what i'm triying to do. When an user performs an action (edit a client, for example), I redirect the client to the client list page, and I show a message that tell to the user "The client data was update susessfully". I'm triying to do it in a way that makes the message to be show only once. Maybe the TempData is not the right way (I don't know, 'cos i'm learning yet), but the target is to show a message to an user only once (no matter if the urser refresh or if the user go to other page and then press back in the browser)... using TempData or using something more adequate to our purpose.
Essentially, you are wanting TempData to do what you want, rather than using the right tool for what you want.
TempData is, by design, intended to be used for caching data across HTTP redirections. That is what it exists for. It is not clear from your post if this is the scenario that you are using.
Ie:
Page redirection, with data in TempData, that is then displayed to the user. Refresh the page you have arrived on, and the TempData is no longer there (there has been no redirection, just a refresh).
If the user then navigates to another page, then uses the back button, the browser will have cached the html of your page and will redisplay that. That is the correct behaviour.
I also think that in your testing, you are getting it wrong. Ie, by disabling the caching, you are just knocking out TempData altogether and you will not get the correct behaviour. Ie, the message will NEVER appear, not just when you hit the back button.
Your jQuery looks inefficient. You are making it do things it doesn't need to do. You could use razor to populate your div with your message. Set the div to not display, ie:
<div id="commonMessage" style="display:none;">
Then use jQuery to show it:
$('#commonMessage').show();
Your post isn't that clear, but in summary, I would say you are seeing what you should.
Maybe you should describe, in an Edit, what you want your app to do. That way it would be easier to answer. As things stand, you have told us what happens and what you put in your view, but it is not clear what you expect.
You should also understand TempData better: it only persists between Controller actions, ie, when a redirect occurs. It stores its data in the Session store, which I believe is affected by the caching attribute you mention.
I'm using Watir 1.6.7.
I'm working on developing some regression tests for a PeopleSoft App using Watir and Cucumber. I have run into a few issues with forms in the application.
First, when entering a value into a text_field, the page refreshes when the user clicks outside the text_field. Waiting for the next text_field element to exist is problematic because it may locate the element before the page reloads, or after the page reloads as expected. Increasing the wait time never feels like a good solution, even though it "works".
The second issue is that the page refresh is not triggered until the user clicks outside the current field. In this case, that happens when the script tries to access the next text_field to be populated. One solution here would be to send a or keystroke, but I can feel the script becoming more brittle with every addition like this.
Are there any other approaches that would be less brittle, and not require 2-3 extra commands in between each text_field action?
The play-by-play looks like:
Browser navigates to page that contains the form.
Browser fills in first form field. (fix: send keystroke to cause page refresh, wait_until second field is visible again)
Browser selects the second form field to be filled out. (again, keystroke & wait_until)
Page refreshes, script fails. (resolved)
Browser selects the third form field...
The application started exceeding the 5 second sleep duration, and I did not want to increase the wait time any longer. I wanted to see what would happen if I populated the text field faster using "element.value =" rather than character by character with "element.set ".
This change completely resolved all complications. The page no longer refreshes when entering text, and no long requires a send_keys statement to use TAB or ENTER to move to another field. The form is storing all of the data entered even though there are no refreshes or state saves between fields.
Previous method:
def enter_text(element, text)
element.set text
#browser.send_keys("+{TAB}")
sleep 5
Watir:Wait.until { element.exists? }
end
New method:
def enter_text(element, text)
element.value = text
end
Firstly, there are interesting Wait methods here: How do I use Watir::Waiter::wait_until to force Chrome to wait?
Overall, I don't quite understand your problem. As I understand it your script is working. If you could be a bit clearer about your desires compared to what you already have that would help, as would some sample source code.
If you're looking for ideas on custom waiting you could check for changes in the HTML of your page, form or text field. You could check that the text field is .visible?. You could try accessing the next text_field (clicking it, or setting the value for example), then catch the exception if it can't find the text_field and retry until it doesn't break, which would solve both your problems at once.
Why would clicking outside the current field be a bad solution? Do you absolutely need the next step to be a text_field access? I haven't gotten my head around how the next field only exists when you click outside the current field, but you cause this refresh by accessing the next field.
Edit: Most welcome, and thank you for clearing that up, I think I now understand better. If you allow Watir to invoke its page wait, or force it to, then it will wait for the refresh and you can then find the new text_field. Keystrokes do not invoke ie.wait, so if you send a single keystroke, then invoke a wait then the rest of your script will be responding to the post-refresh state.
I highly recommend the OpenQA page on waiting in Watir. If what you're doing to invoke the refresh does not appear on the list of things that invoke Watir page waits then you need to invoke your own page wait... but you need to do it before the page refreshes, so the cause of the refresh should end before the end of the refresh itself.
I don't know peoplesoft's app well enough to know this, but Does the app display anything for the user while it's processing.. like some kind of little 'loading' graphic or anything that you might be able to key off of to tell when it's done?
I've seen apps that do this, and the item is just an animated gif or png and it is displayed by altering the visibility attribute of the div that contains the graphic. In that instance you can tell if the app is still loading by using the .visible? method on that element and sleeping for a while if it's still there.
for the app I'm testing (which has one of those 'icons') I created a simple method I called sleepwhileloading. all it that is does is use a one second sleep wrapped in a while loop that looks to see if the loading icon is visible. works like a charm
should input buttons that submit ajax requests be disabled after a request is made untl the response is received.
Im thinking specifically adding products to a shopping basket using a button.
Im trying to make the process as bullit proof as possible but a quite new to using ajax so dont know the best practices on these situations.
Yes, I think that is a great practice. But, it would also help to give the user a "processing" (or some other phrase) notice while you've disabled the button.
Disabling input is a very useful UI element to prevent the user from doing something bad, but I would caution against relying on it too much.
You should probably also do some server side checking to make sure you aren't receiving a duplicate request. This will shield you from browser bugs/non js-browsers etc.
If you want to make it as bullet proof as possible, then you need to show an animation right before you kick off the AJAX request, and handle both success and failure of that request.
As far as preventing an additional request, that depends on your specific action. In your case, updating a cart, it could go both ways. If I "click to add item to cart" once, but there are other items on the page that I could also add to my cart, let me click on the other "Add to Cart" button...right?
for example:
user submit a comment , I add the comment in the page by javascript , then do the ajax. if ajax post failed ,tell user that something wrong happend.
in this way , it can improve user experience . and the probability of ajax failed is not low. but I didn't seen which site is using this technology , so is this method possible?
Actually, I'd say that stackoverflow uses this technique :
Make sure you are using firebug, and have the console displayed on the bottom of your browser scree
Click on (for instance) the arrow to upvote
you will see the arrow immediatly becomes orange, to indicate you have upvoted)
but looking at firebug's console, you will see the Ajax request starts only after the arrow has changed color -- or, at least, it is not finised yet when the arrow has changed color.
Considering the probably of the Ajax request failing is pretty low, changing the arrow immediatly indicates the user his vote has been taken into account... Even if it's not true before a couple milliseconds ;-)
You can add the comment via Javascript but you've also pointed out exactly why you shouldn't: what if it fails? Do you then remove the content?
In my opinion, adding it to the page implies to the user that it has worked. I would leave the comment in a form field until the AJAX submit succeeds. If that fails you can tell the user and they can try to submit again or whatever.
Of course, there is no functional reason why you couldn't do this.
Yes there is nothing stopping you doing this.
You add the comment in an element you create in javascript post the data and get the response code back form the ajax post.