I'm facing an issue about the back function in selenium.
When I call it, it does nothing but if I call it twice, it works perfectly.
I've tried manually on my web browser and one back button is enought to go back.
Someone know why?
Thanks in advance!
The behavior might be a result of a scripted page with some code for auto-refreshing, suppressing or overriding the back button event /action.
So you might:
debug the page and stop on any JavaScript execution
and ask for a correction/change if you are in control of the page
avoid the back-button-action from Selenium-framework, that simulates browser back navigation
use instead a given button (if available)
implement this "feature" in your own framework as a workaround to click it (always) twice to ensure successful back-navigation
Related
Im testing on a site that sometimes doenst really have a good connection.
Everything works great until it decides to not work properly.
I am seperating every element with a wait.until, everything works normally until the connection gets slow and it believes the element is present and decides to use it.
public static WebElement login_btn(WebDriver driver, WebDriverWait wait) {
wait.until(ExpectedConditions.refreshed(ExpectedConditions.presenceOfElementLocated(By.id("btnEntrar"))));
wait.until(ExpectedConditions.refreshed(ExpectedConditions.elementToBeClickable(By.id("btnEntrar"))));
element = driver.findElement(By.id("btnEntrar"));
return element;
}
I cannot find a way to simulate this until the website becomes terribly slow and I get to see if it works or not. After months of trying I am unable to find out a way to completely wait for the element to be present and not receive a staleElementReferenceException or the site actually going into an error page due to me using an element. Using the site manually without these tests cannot simulate what is happening with the webdriver. Are there any hints or suggests on what I could do?
There are a few good answers you can try in this question and this question. One is to use Chrome dev tools to throttle adjust the download speed, https://stackoverflow.com/a/34728002/2386774. Another is Charles Web Debugging Proxy.
To solve this issue more simply, my suggestion is to specifically wait for the page to load completely then scrape the page. This will allow you to wait once and then you won't have to add waits everywhere. You would need to add additional waits if your page is dynamic, e.g. you click a button and it updates part of the page. In that case, add a wait when the button is clicked and you're good again. No need to add waits everywhere.
Project Context
Client requires that the users of the site (when logged in and are able to view their personal information) be forced to be logged out if they try to navigate using the browser's navigation buttons.
My Research
Searching around on SO seems to indicate that most of the problems people have is to "stop" people from hitting the browser's back button when they're logged out, like this and this. The difference is that I need to "stop" the users from navigating backwards in history (and even forward as well, though I don't see how the users can go forward in history if they can't go back in the first place) even when they are logged in, making it compulsory that they use the provided navigation.
The Solution I Have In Mind
I'm thinking of capturing the browser's event when a user hits the back button and logging them out then. However, as discussed here it seems like you can only "do it" using Javascript and not using server-side code. My qualm with this approach is that users can bypass it merely by disabling Javascript on their browsers.
My Question
So my question is - Is there a way I can capture the browser event on the server-side and log them out there? If not, what are the alternatives to achieving my objective?
I'd say that your best option is tracking the session.
You make the client send you the timestamp of when the request was processed by your server, or even simpler: a user dependent counter (which you send each time to the client), and server-side keep track of the last timestamp/counter sent.
If the user clicks the back button, he will send you an old timestamp/counter instead of the last current one, and you can then log him out server side.
This should do the trick.
In order to make sure the trick is done and making it javascript independent, I'd say you could place this value in a hidden parameter, or maybe as a hidden field form, so the user doesn't see it but it always gets sent to your server.
I hope this helps!
What I did was to create a single page, 1 html document, then use AJAX to navigate the whole site. When a user hits the back button it takes you to the index page, which is the log in page. To log in I use AJAX which I do redirect on the server side only. The only problem is when a user hits the forward button but the good thing is no JS no navigation.
If the requirement is trap browser navigation buttons and log them out - the easier alternative is never show these navigation buttons in the first place. What is the use if the user cannot use or click back and forward.
Open a new browser without a toolbar, menu bar from you webapp. When the user closes the window, trap the event and logout the session. This way - the solution would remain simple.
My 2c
Relying on javascript is not a good practice, since it is on client side and what runs on client side can always be bypassed by client.
You should instead use session timeout.
Sorry, fetch the buttons themselfe isnt possible.
Since this is a security-problem a solution (without javascript) would be:
to use encoded pages who warn on navigation out-of or into an unencoded-page. Even the mutual authentication might fit your needs.
If I understand correctly your question:
You can't avoid the user to send a request to your server, the user has full control of his/her browser unless you want to ship a custom altered version for an intranet crew (from open-source browser projects).
Without javascript the the only thing you can do is to send a specific parameter via GET when clicking in the required nav button. If the parameter is present you allow the view of the next/prev page, otherwise the user is logged out.
Obviously the user can bypass that by using the browser developer tools. But there is no way you can fully control user UI behavior at this level.
If i am right then you are talking about NO-Cache in broswer.
you can set all these like following:
response.setHeader("pragma", "no-cache");
response.setHeader("Cache-Control", "no-cache");
response.setHeader("Cache-Control", "no-store");
response.addDateHeader("Expires", -1);
response.setDateHeader("max-age", 0);
response.setIntHeader ("Expires", -1);
prevents caching at the proxy server
response.addHeader("cache-Control", "private");
And then you can define a filter who checks session on every page. When a user logs in then set an attribute in session and on logout remove it.
I have created a web form. On Click of button, database query would be fired. The Problem is that when user clicks on button twice, query would be fired 2 times. I want to prevent that. Any help?
Take a look here
Struts2 has a built in mechanism for stopping double form submission that works on the server side instead of the client. You may need to add the TokenInterceptor if its not on the defaultStack you're using.
Here is a quick tutorial
If you are happy to use jQuery you could consider using
http://jquery.malsup.com/block/
onclick or onsubmit call $.blockUI();
Some Demos for your reference
http://jquery.malsup.com/block/#demos
The belt and braces approach is to set a JavaScript flag variable when the button is clicked and block subsequent submits "onclick". Then, on the server, implement the "synchronizer token pattern" (you can just Google that term to find out about it).
UPDATE: this has just started happening again, would appreciate any help.
I am using server fbml to render an Invite Friends iframe and it was working fine up until two days ago. Basically, after submitting the form, a java action should be invoked where I get all the id's of the user's invited.
However, I now notice that an "invite by email" popup is showing up and, most importantly, my java action isn't being hit at all. When I inspect the form in firebug, I notice that the action is always empty (though all other parameters are preserved correctly).
I've tried setting email_invite=false on the multi-friend-selctor but to no avail.
My code looks like the following:
<fb:fbml>
<fb:request-form action="http://localhost:8080/myAction.do?method=someAction" method="POST" invite="false" target="_top" type="invite" content="CONTENT_GOES_HERE" >
<fb:multi-friend-selector showborder="false" actiontext="Invite your friends to use our app." target="_top" email_invite="false">
</fb:request-form>
</fb:fbml>
</script>
Any help would be greatly appreciated on this.
UPDATE: this has just started happening again, would appreciate any help.
Thanks, gearoid.
Facebook have recently added an extra step into the multi-friend selector process, which is what you're seeing. There isn't, as far as I know, any way to stop this from appearing.
However, you should still be getting the result of the selector sent to you once the user navigates away from the "invite by email" popup.
Facebook's latest update can be seen in this status post.
To prevent that popup appearing add this attribute to the multi friend selector
import_external_friends="false"
Turns out this can happen a lot of different ways.
A) You can call FB.init multiple times
B) Call FB.init with the wrong key
C) You can supply a action that doesn't map to your current application on facebook
D) You or your staff can accidentially supply the same canvas/app url for two apps.
Most of of the solutions online point at A-C. When someone accidentally creates a second dev app pointing at localhost or 127.0.0.1 as the canvas url for multiple apps you admin you will get hosed. Took me hours upon hours to think to search our other apps. So i hope this saves someone a truck load of time. Cheers
I had an incorrect appId set in the fb-root javascript. This caused the error.
I've got a very curious problem in Hibernate that I would like some opinions on. In my code if I do the following:
Go to page A
Click a link on page A to be taken to page B
Click on data item on page B
Exception thrown
I get an error telling me:
failed to lazily initialize a collection of role: XYZ, no session or session was closed
Fair enough. But when I do the same thing but add an alt+tab in the middle, everything is fine. E.g.
Go to page A
Click a link on page A to be taken to page B
Hit ALt+Tab to switch to another application
Hit ALt+Tab to switch back to the web browser
Click on data item on page B
Everything is fine.
I'm a little confused as to how switching focus from my application makes it act as I want it to. Does anyone have any light to shine on the subject? I don't think it's a locking issue as even if I do the second set of steps quicker than the first, still no error.
It's a Seam application using Hibernate 3.3.2.GA & 3.4.0.GA.
It's not really related to switching the applications; maybe your browser updates something during focus lost/gained.
The reason for your issue is this:
In the first request, you load an object and store that in the session. This object contains a collection of some kind.
In the next request, you try to do something with the collection but you forgot to call session.refresh(object), first.
What happens is that the session is automatically closed when the first request is finished. But the backed collection in your object still contains a reference to it (so that it can be loaded automatically when you access it for the first time).
are you using javascript? Maybe an event is firing when you switch back to the browser that somehow clears the bad state?
Does your page complete it's rendering? I have found that sometimes when I get errors, instead of displaying the error, the server simply quits producing output. It outputs the error to the log, but thats about it. I end up with a half completed page. View source and see if you get to the end of the body, perhaps your switching caused the server to get lazy, or your browser to terminate the connection prematurely when the error occured
My advice is to do a unit test to see if you can reproduce the error in other environment isolated from the browser ;)