Last couple of days I have been trying to figure out the ways to handle a few issues with Selenium and IE Such as this
Today, I wanted to run all the Selenium tests against IE9 but in the middle of the test, due to a JavaScript error the debugger popped up and all the tests started failing. Just an extra bit of information I tried using
options.UnexpectedAlertBehavior = InternetExplorerUnexpectedAlertBehavior.Dismiss;
which was not able to dismiss that debugger window.
I know I can manually do it by unchecking the debugger as follows. But, this is not a feasible solution since these tests can be executed in a lot of different machines.
Is there a way to do these programatically with DesireCapability or Options? Or at least any commands for commandline?
Related
I can not run any program.
As per the instruction I went to vscode dev.
Open up my repository to run a test program.
However, unfortunately, I can not run any of my programs.
I have checked the doctrine which said that only chrome and edge are supported.
But I can not run my program on the terminal window because it tells the code can only run on environments such as codespaces, and local vs code.
What do I miss so that the problem is occurring?
As VSCode(.dev) issue 166506 illustrates, you cannot access terminal from your browser probably because that menu entry was hidden/removed on purpose.
With VSCode 1.75 (Jan. 2023), it will be restored with an explanation.
I'm guessing we intentionally suppressed it because terminals can't run in the web, but participants were simply confused that it wasn't there without connecting its absence to the fact that vscode.dev was a browser application.
Additionally, RemoteHub contributes a welcome view for the terminal which is one of the primary ways we explain that users must continue working elsewhere to run or debug code, and the fact that the terminal is completely suppressed means one less opportunity for users to organically learn the limitations of vscode.dev through our welcome views.
The message is the one you saw:
Terminal are not available in the web editor.
To use the terminal, you will need to continue in an environment that can run code, like a codespace or local VS Code.
You can develop remotely, but you need to execute locally.
I have the following bug in a program:
An MDI MFC program closes silently on Windows 7 (terminates the process without prompting to save changes and without displaying any "crash" dialog) when the user performs this operation : Click a context menu item.
But this happens only on that PC, at least, for the moment. No other PC has encountered that problem. However the bug can always be reproduced following the same steps but only on that PC.
I want to know the reason but probably the customer won't allow me to install many programs to debug, so I need to be able to log when the program terminates, or print the stack in Release version but I'm quite lost.
I had faced a similar bug before and eventually I fixed it logging line by line and changing the problematic part, but I guess there are much better ways to find bug reasons than this.
I have tried on my development PC to create minidumps on Release mode but if there is no exception thrown on that PC, (I haven't confirmed that yet, though...) maybe it's pointless.
Also used an available class on codeproject (Stackwalker) but I don't manage to print all the function calls. Only on simple console programs, but not on MDI or even SDI.
Any ideas on how to find out the reason? Thanks in advance.
my selenium webdriver - ruby test builds locally and identifies all the elements on firefox. However, it fails on the server. Strange thing is that the step it is failing on comes up 4 times in the test. And it passes the first 3 times and fails on the 4th time. How can I troubleshoot this issue? what could be the possible cause of failure?
Not as simple as it sounds, I could resolve this issue by adding some time waits in the test script, especially around the steps which required actions on a child window. Since my test involved lots of child windows, modal windows, flash messages etc., It took me a lot of time to identify the exact step where the script failed.
The server that I was running the test has a headless browser and therefore few actions(pop up window actions) take longer than usual.
I'm running a test script from batch file.
Because it is test, the programs are expected to fail once in a while. It is file as long as error code is returned so I can continue and mark specific test as failed.
However there is very annoying behavior of executable files under Microsoft Windows - if something fails it pop-ups window like:
This application has failed to start because foo.dll was not found, Re-installing the application may fix the problem
<OK>
Or even better:
The instruction at "..." referenced to memory at "..." ..
Click on OK to terminate the program
Click on CANCEL to debug the program
The result is known - the script execution blocks till somebody presses "Ok" button. And when we talk about automatic scripts that may run automatically at night in some headless virtual machine, it may be very problematic.
Is there a simple way to prevent such behavior and just make an application to exit with failure code - without changing the code of the program itself?
Is this possible at all?
The answer is following: You need to disable WER.
Simplest description for this I found at http://www.noktec.be/archives/259
Simply (ON XP): Right Click on My Computer > Advanced > Error Reporting > Disable
Voila - programs crash silently!
This does not solves problem when DLL is missing, but this is much rare case and this is good enough for me.
You can suppress AV's and such from showing a dialog box by running your application, or the script (the script engine, like cscript.exe), under a debugger.
Use Gflags.exe, or modify the registry directly, and set Image File Execution Options for the image in question. See this article for details on how to use the appropriate registry keys. You can set it up using a debugger commandline like "C:\Debuggers\ntsd.exe -g -G -c'command'", where you can pass commands to ignore certain types of exceptions in the -c"commmand" argument. This will effectively give you a tool to suppress interactive dialogs as a result of exceptions like AV, and will let the process continue (presumably to immediate end after the exception has occured).
This article explains the commands you can use to control exceptions and events from withing the debugger.
The -g and -G flags make sure that the process won't break into the debugger automatically during process start and end respectively. You'll have to play with the various exception suppression options to make sure that you 'eat' all possible first and second chance exceptiosn that might cause the process to break into the debugger.
Also, if you can tolerate a process being broken into the debugger (as against being stuck showing a dialog box), perhaps that would be a better option overall. You can evaluate each debug break in batch mode at a later time and decide which bugs you care to fix.
It is possible. We used to use IBM's Rational Robot product which could monitor the screen for specific items and, if found, send keystrokes to windows and other sorts of things.
We actually used it for fully automated unit and system testing, much like you're trying to do.
Now I thought that Robot has been through quite a few name changes so it may be hard to find but there it is, right on IBM's web page and with a free downloadable trial for you. It's not cheap, clocking in at a smidgeon under USD5,000 but it was worth it for us.
There's also TestComplete where you could get a licence for just unedr USD1,000 - it touts "Black-box testing - Functional testing of any Windows application" as one of its features and also has a downloadable demo to see if it's suitable before purchase.
However, you may be able to find another product to do the same sort of thing.
I initially thought of Expect but the ActiveState one seems to concentrate on console applications which leads me to believe it may not do graphics well.
The only other option I can suggest is to write your own program in VBScript. I've done this before to automate the starting of many processes (log on to work VPN, start mail, log in and so on) so I could be fully set up with one mouseclick instead of having to start everything manually.
You can use AppActivate to bring a window to the foreground and SendKeys to send arbitrary keypresses to it after that. It's possible you may be able to cobble together something from that if you want a cheaper solution.
I have a web application, which in the course of a normal interaction, hangs IE. By "IE being hung", I mean that IE doesn't respond anymore and using 100% of the CPU. The only to get out of this state is to kill the IE process. About the app:
It loads only one page in the browser, communicates with a server with Ajax queries, and updates the DOM.
I can reproduce this with both IE6 and IE7, but not Firefox or Safari.
I am wondering if anyone has seen this already, and if there are a few known cases that can get IE into this hung / using 100% of the CPU state.
Use WinDbg, http://www.microsoft.com/whdc/devtools/debugging/
Attach it to the IE process that has the problem.
The .symfix+ command will set your symbol path to point to the Microsoft symbol server and cache the debug symbols locally.
The !runaway command will enumerate all the stacks in the process and tell you which one is going berserk.
If you're lucky, you may see something recognizable, such as a regex replacement at the top of the stack. Or perhaps the layout engine has gone into an infinite loop. Both of these have happened to me in the past.
If the callstack doesn't make sense, use 'g' to make the process go, wait a few seconds, hit Ctrl+Break, then try !runaway again.
Once you've got the symbols locally, you can also use SysInternals' Process Explorer to look at a process's stacks. Configure the Symbols option in Process Explorer to point to your local symbol cache, something like c:\Program Files\Debugging Tools for Windows\sym.
Try attaching the script debugger (via Visual Studio, in my case), and see what is causing it.
Most likely it's a javascript running an infinite loop, or just looping too fast for what needs to be done per ajax request.
Have you tried tracing the problem? If the problem also happens in IE8 you could use console.log commands and their awesome new debugger/dev tool that's built in. Otherwise use the old dev toolbar for IE or alerts. Try to reduce the problem and then file a bug (and paste the code here please).