So I have some tests in Selenium using the InternetExplorerDriver implementation of IWebDriver. Many of my objects respond to IWebElement.Click() well and consistently. I have anchors that click reliably for instance. I am writing some new stuff for clicking on a td. That is the element where the event handler is called says Mr Developer of the application under test.
The thing is it SEEMS to only fire click event and present the resultant hidden div when I am debugging the code but not when simply running it. There is not error thrown when the click is attempted.
I know that this is not a timing issue because there is something slow that is happening right before this test which allows the page to fully load.
Any other thoughts? Thanks.
Sorry folks for wasting your time. Operator error.
Related
So this is similar to Click() method will not always work but there are several vital differences:
Not a timing issue because I repeatedly try to click it until success
No exception is thrown, just nothing happens
Using a JS click on the same element works - executor.executeScript("arguments[0].click();", element);
Using button.SendKeys(Keys.Return) instead works.
Displayed: true and Enabled: true
Only button.Click() doesn't work. I've stopped the application at a breakpoint and am testing it via the Immediate Window right now. I can see how Click() has no effect and doesn't throw an exception, but javascript click() and SendKeys() work.
Some additional info:
I'm using InternetExplorerDriver on IE11
I'm running the tests on Windows Server 2012 through Remote Desktop
It happens only intermittently. I remember switching Alt+Tab while the tests are running whenever it's happened but I don't know if this is the reason.
Any idea what is happening?
Edit: I noticed at one point that the first click pushes down the button (visibly) but it doesn't get click. The second click succeeds, however. Earlier Click() did not succeed, no matter how many times I executed it.
Edit 2: OK, now I've nailed it - if I click on the browser window, then I click to Visual Studio, then the first Click() doesn't work. Subsequent clicks all work, even if VS is still focused. Switching from VS to notepad and then to VS does not trigger it, only switching to IE and then back to VS.
It's as if it's not the problem that IE doesn't have focus, it's about having it and then losing it, then the next Click() will fail.
In my case the contol was partially overlapped with another div, and the webDriver clicked in the middle of control but hitted the div. Could you please check maybe it is your case.
I am using Selenium Web Driver and encountered following exception while trying to click a proper element in web browser: Unable to locate element.
XPaths are 100% correct.
The strange thing is it is working ok when:
In debug mode.
After clicking Continue in VS when exception appears.
When i am moving mouse manually on the screen.
I would be grateful for any help.
EDIT: Thread.Sleep doesnt help. I am trying to click decrease Year button in web calendar. It works first time, but freezes the second time. But the object is still there. So i dont understand how it can be not visible.
The driver is trying to locate the element before it loaded. Try waiting for it before clicking.
wait.Until(ExpectedConditions.ElementIsVisible(By.XPath(path))).Click();
There are a few things you can try:
1-try a selector by ID instead of the xpath. Maybe new elements are being rendered and making the xpath didn't find the element.
2-implement a retry pattern
3-use thread sleep to let the page being full rendered.
I was wondering if there is any way to return the path that Visual Studio takes when running through a program. For example, without setting breakpoints, is it possible to know exactly what happens when I click a button on a web app I created? Like if I clicked a button that had an action, is there some kind of info that Visual Studio can spit out that tells me what happened? (which functions in which files were used, etc. Essentially the "code path").
To add on to my question, I'd like to use something like this to help debug an issue. I want to know exactly what is happening when I perform some kind of action (button click in my example). If I know every "code path" I can better address the issue I'm having.
If I understand correctly your question, you're looking for Environment.StackTrace
The StackTrace property lists method calls in reverse chronological order, that is, the most recent method call is described first, and one line of stack trace information is listed for each method call on the stack. However, the StackTrace property might not report as many method calls as expected due to code transformations that occur during optimization.
Something else you can do is adding debug log entries to know what's is going on. It may be more useful since you could add extra custom data.
Not sure if you already have a log framework on your project. If you don't have any log4net could be a good option
Converting my comment to an answer so there is an answer that addresses the original question:
Use a performance profiler, which is designed to observe execution paths (typically to help you find bottlenecks, etc., but it will work fine for your purposes too). A good performance profiler will let you dig down and see, for any method, what methods it calls, how frequently, etc.
You can print out a call stack results to the output window in Visual Studio. You will still need to use breakpoints but the ones that doesn't stop the application. To do that:
Find the place in your code when you would like to get the stack printed out. For instance at the end of button clicked handler.
Place a break point there.
Right click the breakpoint. From the context menu select "When Hit..." option.
In the window that will show up select "Print a message:" checkbox. It will enable a textbox. In the textbox type in: $CALLSTACK.
Check the "Continue execution" checkbox if you don't want to stop the execution while printing the results.
I don't remember if the "When Hit..." option is available in the Express edition of Visual Studio.
There are also some other data you can print out without breaking execution, e.g.: previous function, process id, etc. The details are actually available in the "When Hit..." window.
I did some research on this before asking the question and since I might be asking it incorrectly, I might not have done the right searches here first.
What I am trying to accomplish is when I start to debug or run an application in Visual Studio, is to have the IDE show me what methods are executing when I do something in the GUI/application.
For instance if I click a button in the GUI labelled "Search", I want to see the chain of events/methods that execute for this process. This I am not sure of. I hope I have asked the question correctly. Thank you for your time.
Have a try with IntelliTrace.
Make sure IntelliTrace is enabled and call information is selected;
Launch your GUI application, and perform what action you want;
In IntelliTrace window, click Break All. If IntelliTrace window is not displayed, click Debug -> Windows -> IntelliTrace Event;
Expand the event you are interested, for example, 'Clicked Search', and click Call View link;
You can see call stack you are interested.
There are two ways to approach this:
If you have no idea where the code you are looking for is, then simply start your program with a Profiler such as JetBrains dotTrace. Then, get ready to push the button, click "Start Profiling", click the button, and then as soon as the operation is finished, click "Get Snapshot". Now, use dotTrace's Call Tree to see which methods called which. I use this technique all the time for just this purpose!
In this view, you can use the arrows key to navigate the method-calls tree.
If you have a general idea of which class[/es] get invoked when you hit the button on the GUI, but don't know exactly which methods are called, you can use OzCode's "Add Breakpoint to Every Method" on a class, so that even if you don't know the exact method that's about to be called, whenever the class is accessed, you'll break into the debugger and be able to explore.
Due Diligence Disclaimer: I am a co-creator of OzCode.
You can use the Runtime Flow tool (commercial, developed by me) to see the chain of events/methods in a .NET application for GUI actions.
I'm just starting out with MonoMac in Xamarin Studio, and I've run into the strangest problem:
I a window with an NSButton and a NSTextField on it. By this point I've cut out the event handler on the button, so it doesn't DO anything, except highlight when I click it. The button creation code looks like this:
nsButton = new NSButton(new System.Drawing.RectangleF(0, 0, 100, 100));
nsButton.BezelStyle = NSBezelStyle.RoundRect;
nsButton.Font = NSFont.SystemFontOfSize(
NSFont.SystemFontSizeForControlSize(NSControlSize.Regular));
nsButton.StringValue = text;
...and then it gets added to the window like so:
nsView.AddSubview(control.Handle as NSView);
(because in this part of the code, control.Handle is typed as object, and nsView is the main view on the window).
All runs and works fine at first. But, if I click repeatedly on that button, eventually the window just closes. No error, no exception, and the app itself doesn't quit; menus continue to respond and cheerfully log messages when I use them. But the window is simply -- gone.
It's extremely repeatable: it happens after 21 clicks. If I add an event handler that updates the NSTextField (e.g. hello.Caption="Foo";), then it happens after 19 clicks. It doesn't matter whether I click fast or slow; it's always the same number of clicks. Note that there is no code in the project to close the window, and the window doesn't even have a close box; I know of no legitimate way to close it short of quitting the app.
I am baffled here, and don't know how to debug this further. Does Xamarin have some sort of evaluation limit that closes your windows after so-many events? Is it a framework bug? Any insight will be greatly appreciated.
But, if I click repeatedly on that button, eventually the window just
closes. No error, no exception, and the app itself doesn't quit; menus
continue to respond and cheerfully log messages when I use them. But
the window is simply -- gone.
This "disappearing without a trace" sometimes occurs when an application crashes in native code badly enough. This can occur due to bugs in the binding code or mistakes made in calling the native APIs that corrupt internal cocoa state. I believe you are using MonoMac, and that this particular issue has been fixed in Xamarin.Mac.
You can sometimes get more information from the output window or by attaching lldb to your process.
This turned out to be the same issue as this one, in a slightly different guise.
In short, I wasn't keeping a reference to the NSWindow object, but instead was letting it go out of scope. So the GUI window would stick around for a while, but eventually (after some number of events or other code creating behind-the-scenes garbage) it is noticed and disposed of by the garbage collector. The window is then torn down.
It's all perfectly reasonable once you think of it, and happens under both Xamarin and MonoMac (just at slightly different times).
The simple solution, of course, is to retain a reference to the window until you're truly done with it. Problem solved!
(And yes, I feel a bit sheepish, but hopefully this question will get found by future Mac C# developers, and save them some grief.)