I am running a Coded UI test that clicks a hyperlink, for example, "Home" then goes off and does a few different things on the web page, then tries to click the exact same "Home" link and an error is thrown saying
The web page could not be accessed. If the page is refreshing, please
wait until the page refreshes and then perform actions on it.
Now I get this when I am stepping through the test, so I know at the point this link is trying to be clicked the page is not refreshing. Digging through the UITest error logs I see this line every time before the browser refresh error is thrown:
E, 6468, 13, 2013/10/18, 15:08:47.406, 271797587803, QTAgent32_40.exe,
IEDOM : EnsureValid failed for html node: A, 52
I have compared the uitest mappings for this link and the properties are all identical, also the page html is identical.
I am running in IE10, KB2879017. VS2012 4 RC.
Any idea's what's causing this to happen?
NOTE: WaitForControlReady() does nothing to stop this from happening. Also a hard coded Playback.Wait() doesn't help here either.
Failing line of code, this works the first time, but not the second time it is executed in a test.
this.UIWindow.UIDocument.UIHomeHyperlink.WaitForControlReady();
Mouse.Click(this.UIWindow.UIDocument.UIHomeHyperlink);
Remember that the search properties being used for the UIHomeHyperlink mapped control are the exact same the second time these lines are executed. Mouse.Click() execution is when the "Web page not available" error is thrown in VS2012.
After some brainstorming and trial and error testing, came to the conclusion that mapped controls are holding onto properties after being found on a page. For some reason those properties weren't matching up exactly with the page properties on the second time around.
So a "solution" to this problem was to force a new up of the entire mapped UI___Window each time we enter the page. Coded UI prevents this in the designer file by checking if the control is null every time, if it is then the control is new'ed up. If not, then Coded UI uses the same control and it's properties from when it was first defined/discovered. Hope this helps anyone else that was having problems with this error.
There also seems to be a bug in CodedUI when calling .GetParent() twice on the same object tree, which causes this exception to be thrown. We worked around it by determining the parent in another way.
On another workstation (W7) another exception was thrown when calling .GetParent() twice, something about that the IE version should be more than IE10 on 64bit versions of Windows, which was clearly nonsense, since the computer had IE11 installed.
Related
I'm having an issue with WPF's WebBrowser control. It's crashing with the titular error when I'm changing tabs - I think I know why (explained below), but I can't think of a way around it. I'm looking for either ideas on how I might reorganize the code to work correctly, or alternatives on what I'm using to achieve my goal.
The setup of the program is this: There are multiple tabs, containing Borders/Grids/etc. On one of these tabs, there is a Grid which has "Widgets", each containing a WebBrowser. These browsers are loading various locally-hosted pages with information for the user. To make the widgets look good, some code runs in the LoadCompleted event of the browser.
brow = new WebBrowser();
brow.LoadCompleted += wb_LoadCompleted;
(The wb_LoadCompleted function isn't important: the program will crash as it's being called, not during its execution.)
Also, when the user changes tabs, these Widgets have a Dispose function that's called.
brow.LoadCompleted -= wb_LoadCompleted;
brow.Source = null;
Now if the user opens the tab with these Widgets, then after the pages begin loading, but before they finish loading and call that event, the user switches tabs again, the program will crash once it attempts to call the wb_LoadCompleted event. I think this is happening because of the error described here. The handlers have been disposed because the tab changed, but the thread wants to call the handlers. In Visual Studio, if I place a break on the wb_LoadCompleted method, it'll be on that breakpoint when the error is thrown, so I think the program still knows what code it should be running, it just doesn't have permission to.
So far I've been unable to find a workaround or solution. Beyond code fix attempts, I've tried using different browser controls (Awesemonium, and a few others); while they work without this error, but they also balloon the size of our program distribution by 30 meg. That nearly doubles the size, and it's not feasible for us to do so. Any alternative browser control that works would be great, but it needs to be ~10 meg max.
I can also share some other code if you let me know what you need to see; however, I'd imagine this is more of a timing/placement/ordering issue than current code issue, if that makes sense.
e; Adding the full error text:
Managed Debugging Assistant 'FatalExecutionEngineError' has detected a problem in -programpath-
Additional information: The runtime has encountered a fatal error. The address of the error was at 0x6bd5e4ad, on thread 0xa54. The error code is 0x80131623. This error may be a bug in the CLR or in the unsafe or non-verifiable portions of user code. Common sources of this bug include user marshaling errors for COM-interop or PInvoke, which may corrupt the stack.
I've got a very bizarre situation. It appears that, when I load a webpage to my browser,
multiple threads (at least 2) are starting up. The app loads and runs fine on a
Windows XP box, but when I try to run it on my Windows 8 laptop it would seem that
more than one startup event is taking place and causing all kinds of collisions. This
is happening with both Firefox and IE.
To verify this behaviour, I placed a static int within a class, checked it to see if its
value is greater than zero, throw an exception if it is, then increment the int.
Of course, the exception is thrown.
What's very weird about this is that there is no multi-threading/multi-tasking involved
within my app.
When I "touch" the DLL for the webpage (rebuild it), it renders the webpage properly,
but the source for the webpage ("right click" > "View Page Source") has the source
for the unhandled exception webpage, with the message for the exception that my code
throws when the thread count is greater than zero.
I've tried creating a new project, then linking the code to it (Add Item ... Ad As Link),
then building it. It didn't do any good.
The Win XP system has IIS 6 with .NET 4.0, and the Win 8 laptop has IIS 7 with .NET 4.0.
Language is C#.
The truth is that I'm pretty much clueless about IIS.
I hope someone smarter than I am (which isn't saying much) has an idea as to what
is going on.
It appears that, when I load a webpage to my browser, multiple threads (at least 2) are starting up
Maybe onetime initializations. I doubt that every request causes an additional two threads to stay around.
it would seem that more than one startup event is taking place
That's normal This event fires for each instance of HttpApplication being created. This is basically a design error in ASP.NET. They thought that pooling HttpApplication instances and assigning one of them for each request was a good idea. It would have been better to have a singleton per AppDomain. Write this yourself. Like that:
class MyGlobalAppState { ... }
static Lazy<MyGlobalAppState> state = new Lazy<...>(StateFactory);
Be aware, that Lazy<T> stores any exception and just rethrows it. This causes your app to be permanently broken in case StateFactory throws. It will never recover without pool restart. This is a design error in Lazy<T>. Find a way to deal with that.
but the source for the webpage ("right click" > "View Page Source") has the source for the unhandled exception webpage
Some browsers re-GET the page to view the source. This can be annoying or handy.
It is hard to tell what is causing this behavior but as others suggested try to use Fiddler or any other http tracing tool to see what requests are sent.
Also, Win XP should be running IIS5.x while Win8 should be running IIS8.
By default IIS8 AppPool should be running with the integrated pipeline, which may behave differently. I would try changing the AppPool to use the Classic pipeline to see if it makes a difference.
I have a web application I am developing that seems to crash completely at random when clicking links on any page. When this happens, I'm told 'An unhandled win32 exception occured in iexplore.exe'. When I try to debug, it says one is already attached.
What could this be relating to? I know without code it will be hard, but this seems like a very strange error to occur at random.
I have had this happen to me before and the problem usually had to do with styling on html elements that IE just couldn't handle. A good test would be to run the app in Mozilla and Chrome to see if they crash. For me, 4/5 times it had to do with the overflow attribute on a div. For some reason, ie is quirky when it comes to scrolling. To find it, after you have tested in the other browsers, start taking blocks out one piece at a time and see if you get the error. If you don't get the error, then the problem is in that block, otherwise put it back in and take the next block out. Keep going until you find it.
It appears like something is stopping my errors from displaying normally an in ASP.NET site.
Scenario 1 - I have an admin screen that has most of its content inside an updatepanel. When the user's session times out. You click a button and nothing happens. It doesn't redirect you to the home page and it doesn't give you an error message.
Scenario 2 - I have some sort of data issue throwing an error - its happening on the staging environment otherwise I'd just debug the code normally. But instead of showing me the error you get the javascript type exclamation mark down the bottom and you need to quickly click on it to bring up a pop up dialog. In IE this happens. In FF there is no error message at all being shown.
My error in this instance is Sys.WebForms.PageRequestManagerServerErrorException: Sequence contains no elements. It then refers to a ScriptResource.axd... so based on this error message I'm having trouble working out what the problem is as I can't reproduce this on my dev environment. I believe its usually related to a linq statement referencing something with no elements but am not sure where the error is occurring or why. But am also wondering why this error appears to be being caught and not displayed look good old fashioned exceptions :)
So not sure if its an updatepanel issue or a scriptmanager related quirk. I imagine I'm using the wrong keywords to google as I can't find anyone else really complaining about the same thing :(
Thanks for any help!
For your first scenario, it seems as though you may need to check via a javascript ajax call whether the user's session is still active, and if not then redirect to the login page.
For the second scenario, I would suggest logging all exceptions on the server using a tool like ELMAH, which will give you a simple UI to view exception details.
I am working on a system that after completing a record edit and returning control to the calling AJAX script, I refresh the calling page by calling a custom server extension. The odd behavior I am experiencing is after control is returned to the calling script, when the code hits window.navigate or document.location, it attempts to navigate to the url in a new window (which is not the desired behavior). Additionally, the custom server extension is never called - the url appears in the address bar, but then does nothing.
Does anyone have any idea what might be going on? I am running IIS 5.1 on XP sp3 and have tried to get it to work in IE 8 and IE 7, to no avail. Any help would be greatly appreciated.
Okay, my tech lead is apparently a much better Googler than I am.
http://www.faqts.com/knowledge_base/view.phtml/aid/13307/fid/53
Long story short: the page I am calling from is modal and only has an HTML rendering dll loaded. So we changed the return value of the modal page we called from a scalar value to an object with data and now I get to go repopulate the fields manually in the modal calling page.