Handling browser errors?

[chris]

I've searched through the forums and google and couldn't find any solution to this, hopefully someone can help.

We're working on testing web content which is to be used within an iPad application.  In order to allow the web content to interact with iOS native content our developers have implemented a custom protocol (i.e. "foo://), which when the native application encounters this it does a particular task described after the protocol. 

My issue here is that I can use the test framework to test the web content in Safari until it encounters this custom protocol.  When it encounters it, Safari displays a browser error of 'Safari can't open "foo://bar/" because Microsoft Windows doesn't recognize Internet addresses starting with "foo:".'  I can't proceed past this, any attempt at accessing the url to trap it just shows the previous page's url, and any attempt to navigate elsewhere afterwards fails with a timeout.

Is there any means to trap the url with the special protocol so I can do something with it, and/or any means to get the framework to tell the browser to navigate elsewhere after it encounters one?

I've put together some sample code to illustrate the problem:

 

Settings testSettings = new Settings();
testSettings.Web.Browser = BrowserExecutionType.Safari;
testSettings.ClientReadyTimeout = 60000;
testSettings.UnexpectedDialogAction = UnexpectedDialogAction.DoNotHandle;

Manager mgr = new Manager(testSettings);
mgr.LaunchNewBrowser(BrowserType.Safari, true);

mgr.ActiveBrowser.NavigateTo("http://www.google.com");
System.Threading.Thread.Sleep(5000);
mgr.ActiveBrowser.NavigateTo("foo://bar");
System.Threading.Thread.Sleep(5000);
mgr.ActiveBrowser.NavigateTo("http://www.bing.com");

Safari will not navigate to bing.com and the test will timeout.

[chris]

so, considering the timeliness of responses to other posts and no response to this one for a couple of days can I assume that this question is too hard to answer and will be buried in the forum neglected?

[Cody]

Hello,

I can think of two possible solutions to this:

1) The first is fairly obvious and simplistic. In your code sample you have a hard coded line to navigate to "foo://bar". Obviously you can replace this line of code with something else so that Safari doesn't attempt to navigate to "foo://bar". My question on this however, since the test is running in Safari and it won't accept "foo://bar" what should happen? What is the right code replacement?

2) Take advantage of our HTTP Proxy to intercept all HTTP traffic flowing between the browser and the web server. You have the option of intercepting such navigation traffic and modify it as needed.

P.S. No, it actually means we're slightly overloaded and haven't had the chance to address this one yet (but I will admit it's tougher than our average request). Keep in mind we target forum posts to be answered within 72 hours on business days.

Greetings,
Cody
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.

[chris]

Hey thanks for responding.  It really is appreciated.

As for the code snippet, that isn't actual code we're using. It was there to demonstrate what the browser does in that situation and that the framework can't seem to resume after it encounters it.  The protocol is actually coming from the web server and as I stated, is intentional.  I fully anticipate that Safari displays this message.  What I'm trying to figure out is how to get the framework to either trap the response from the server (which you may have presented a solution, more on that) or get the framework to resume normal operations in the event the browser does throw such an error (i.e. navigate away to a different page).

I'll take a look at using the proxy to trap the response, but in the meantime can you tell me if (using the code sample I provided earlier) there is a way to get the framework to resume (i.e. navigate to bing.com) after the browser encounters such an error?

[chris]

So I'm looking at implementing the http proxy as you linked to it, however I'm getting a null reference exception when it tries to add the response listener.  What's missing from this code to get it working?

Settings testSettings = new Settings();
testSettings.Web.UseHttpProxy = true;

Manager mgr = new Manager(testSettings);
mgr.LaunchNewBrowser(BrowserType.Safari, true);
ResponseListenerInfo responseListener = new ResponseListenerInfo(CheckSignIn);
mgr.Http.AddBeforeResponseListener(responseListener); // <-- throws null reference error

and here's the code for CheckSignIn:

private void CheckSignIn(object sender, HttpResponseEventArgs e)
{
      if (e.Response.Content.ToString().Contains("sbapp"))
      {
           signInSuccess = true;
      }
}

[Cody]

Hello,

You only forgot to start the Manager:

Settings testSettings = new Settings();
testSettings.Web.UseHttpProxy = true;

Manager mgr = new Manager(testSettings);
mgr.Start();
mgr.LaunchNewBrowser(BrowserType.Safari, true);
ResponseListenerInfo responseListener = new ResponseListenerInfo(CheckSignIn);
mgr.Http.AddBeforeResponseListener(responseListener);
mgr.ActiveBrowser.NavigateTo("http://www.telerik.com");

All the best,
Cody
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.

[chris]

OK, bypassed that little issue.  thanks.  However, I seem to have another issue regarding the proxy.

We use a proxy configuration script to access our test web servers.  When I run my test with the framework's proxy turned on, it strips out the existing proxy information from the browser (safari) which causes it not to be able to connect to the server.  Is there a way to have the framework's proxy keep the existing settings in the browser while the test is running or even specify additional settings for the framework proxy to use? 

[Cody]

Hello,

We do not have any experience with proxy scripts. We'll need to research this a bit more.

What is supposed to happen is when UseHttpProxy is turned on, our ArtOfTest.WebAii.HttpProxy.exe proxy agent fires up and will daisy chain to the current proxy settings (i.e. change the proxy to point to us, then forward the packets to the original proxy settings). For now my only thought is to manually configure the proxy settings instead of using your script. Let me know if that works.

Greetings,
Cody
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.

[chris]

I tried entering the proxy information, including exceptions, manually as per your suggestion and played around a bit and think I've narrowed down my problem but I need help working around it.

So I've verified the following:
- changed wininet's proxy information from a script to manually entered proxy server and exceptions.  I verified that I was able to successfully use the browser to hit our web servers.
- I installed fiddler and verified that I can hit our test servers manually through the browser when it is used as a proxy

I closed fiddler and all open browsers then tried to run my test with the framework's proxy enabled.  Safari was unable to hit our test server.  However, if I:
- stopped the test
- closed all browsers
- restarted test
- paused the execution of the test after the browser gets launched
- went into wininet's proxy dialog box and entered the urls to our test server into the exceptions textbox
- refreshed the page safari was attempting to load
- resumed the test
then it all magically started working.

For a comparison, I took a look at wininet's proxy settings when fiddler was the proxy and compared them to the settings when the framework's proxy was enabled, everything looks to be the same except for the listening port.

So it looks like I either need some means to change the framework's proxy listening port, or some means to add urls to the exception list.  Are either of these possible?

[edit] ignore the part about the listening port, I was able to verify that it was not the issue.

[chris]

hmmm...ok adding the proxy exceptions during test execution didn't have the desired result either.  the request I was attempting to trap never got caught because it was bypassing the framework's proxy.

From what I gathered in someone else's thread, the framework proxy is essentially the fiddler core.  So I guess my question is now, why will safari not connect to our web server when using the framework's proxy, but will connect when using Fiddler as a proxy?

[Cody]

Hi,

I discussed this problem at length with my expert on our proxy. We both are stumped as to a possible solution. We cannot explain why our proxy isn't working as expected while Fiddler works just fine. Yes we are using Fiddler Core as the core of our proxy.

Can you send us a copy of your proxy script for us to study and try and learn something from it?

All the best,
Cody
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.

[chris]

yes, I can send it, but due to security concerns would not want to post it on the forums.  Is there an email address I can send it to?

[Cody]

Hello,

Yes, send it to [e-mail]. Please reference ticket 500143 so that the email gets properly directed to me.

All the best,
Cody
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.

[chris]

I emailed it this morning.

I also realized that there's one more piece to the puzzle which may or may not be important.  We use host file entries to point to our test servers.

Chris

[Cody]

Hi,

Thanks for the additional information. I added an entry to my hosts file, then created a test and it ran just fine as expected, including using Silverlight. So I don't think your entries in your hosts file matters.

As one last experiment, what happens if you tell your tests to use the IP address in the NavigateTo steps instead of the friendly URI names i.e. change from http:\\www.myserver.com\mypage.aspx to http:\\192.168.8.51\mypage.aspx. Does this make a difference?

That's all we have to suggest. If this doesn't work then it appears to us there's simply no way we can get our proxy to work in your environment with your proxy script.

All the best,
Cody
the Telerik team

Check out Telerik Trainer, the state of the art learning tool for Telerik products.