Recorded keyboard "Tab" issue

[Daniel]

In trying to simulate a JavaScript alert dialog earlier, I ran into an issue with recording a "Tab" press from an input box.

Here is the scenario:

1) Type date into input1
2) Tab to next field
    a) if input1 date is older than 6 months old, javascript alert notifying user (scenario I am testing, and going to take a screenshot of in the test).
    b) if input1 date is within range, no javascript alert

When I played back the test, which had a "Handle 'Alert' Dialog", to my surprise, the test was hanging as that Alert never came up.

After some fiddling, I converted the step to code which is below:

[CodedStep(@"Keyboard (KeyPress) - Tab (1 times) on 'NewCensusEffectiveDateTextBox'")]
public void NavToPatient_CodedStep()
{
    ActiveBrowser.ContentWindow.SetFocus();
    Pages.AdminCensus.NewCensusEffectiveDateTextBox.ScrollToVisible();
    Pages.AdminCensus.NewCensusEffectiveDateTextBox.Focus();
    ActiveBrowser.Manager.Desktop.KeyBoard.KeyPress(ArtOfTest.WebAii.Win32.KeyBoard.KeysFromString("Tab"), 100, 1);
    ActiveBrowser.WaitUntilReady();
}

This is all being tested against a third party product, which I have no control over the javascript functions that result from the input box.  The input is below:

<input type=text size=10 maxlength=10 name=effective_date value="1/1/2001" onkeypress="return filterKeys(event)" onfocus='setDateItem(this, "P")' onblur="reformatDate(this)" onchange='reformatDate(this); javascript:ESOLValidateDateString(frmData.effective_date);checkUpdateCareLevel();'  >

As you can see it appears there is a lot going on here.

The issue comes with the "ActiveBrowser.ContentWindow.SetFocus();" line.  If I remove this line, the Alert will show up like normal.

What I think is occuring is, the "ActiveBrowser.ContentWindow.SetFocus();" line is not allowing the "onchange='reformatDate(this);" to run.

My question is, is the "ActiveBrowser.ContentWindow.SetFocus();" necessary as part of the default "Tab" record key action?

P.S. I know I can take care of all JavaScript Alert dialogs by using the following:

public override void OnBeforeTestStarted()
{
    Manager.DialogMonitor.AddDialog(new AlertDialog(ActiveBrowser, DialogButton.OK));
    Manager.DialogMonitor.Start();
}

..and I plan on it.  But I also want to work in taking a screenshot of the JavaScript alert and I haven't got into custom dialog handlers yet.

[Daniel]

Just a bit more on the subject.  I converted a input textbox to code and am seeing a different setup to the two steps.

With the Enter text into a textbox conver to code, we have the following:

[CodedStep(@"Enter text '01/01/2001' in 'NewCensusEffectiveDateTextBox'")]
public void NavToPatient_CodedStep()
{
    // Enter text '01/01/2001' in 'NewCensusEffectiveDateTextBox'
    Pages.AdminCensus.NewCensusEffectiveDateTextBox.ScrollToVisible(ArtOfTest.WebAii.Core.ScrollToVisibleType.ElementTopAtWindowTop);
    ActiveBrowser.Window.SetFocus();
    Pages.AdminCensus.NewCensusEffectiveDateTextBox.MouseClick();
    Manager.Desktop.KeyBoard.TypeText("01/01/2001", 25, 100);
}

With the "Tab" convert to code, we have what is below:

[CodedStep(@"Keyboard (KeyPress) - Tab (1 times) on 'NewCensusEffectiveDateTextBox'")]
public void NavToPatient_CodedStep()
{
    ActiveBrowser.ContentWindow.SetFocus();
    Pages.AdminCensus.NewCensusEffectiveDateTextBox.ScrollToVisible();
    Pages.AdminCensus.NewCensusEffectiveDateTextBox.Focus();
    ActiveBrowser.Manager.Desktop.KeyBoard.KeyPress(ArtOfTest.WebAii.Win32.KeyBoard.KeysFromString("Tab"), 100, 1);
    ActiveBrowser.WaitUntilReady();
}

The scroll to visibility is in a different order between the two, as well as the difference in "ActiveBrowser.ContentWindow.SetFocus()" in a Tab convert to code versus "ActiveBrowser.Window.SetFocus()" in the enter text in a textbox.

If I change the codebehind step for Tab to ActiveBrowser.Window.SetFocus(), the JavaScript alert shows up.  Does not work with the default ActiveBroswer.ContentWindow.SetFocus().

[Cody]

Hello,

The scroll to visibility is in a different order...

In the end this shouldn't make any difference. As long as both operations are performed. Also in a lot of cases Scroll To Visible isn't even needed. It's only needed if the target element happens to be outside the windows current viewport i.e. the window must be scrolled to make the element actively visible within the browser window.

...as well as the difference in "ActiveBrowser.ContentWindow.SetFocus()" in a Tab convert to code versus "ActiveBrowser.Window.SetFocus()"...

Again in theory this shouldn't make a different. "ActiveBrowser.Window" is the whole browser window, including title bar, menu's, navigation entry, etc. "ActiveBrowser.ContentWindow" represents the inner window where the web page content is displayed.  By definition if ContentWindow gets focus, so does "Window" due to window hierarchy dependency. The revers is not true.

1) Type date into input1
2) Tab to next field

I would like to suggest a slightly different approach. Instead of Tab to the next field, do a Mouse Desktop Click on the next input field. In general using Tab to cause a "lost focus" event to fire can be brittle and not work 100% of the time. Also if the test relies on tab order of input elements being in a certain way, once the tab order of the application changes (e.g. a new input element is inserted) the test script will break. A mouse click on the next element is more reliable.

Or you might also try using invoking the JavaScript Event "OnBlur" (i.e. lost focus) which is available through the same popup menu. This will probably be much more reliable then using the keyboard just to activate the event.

Regards,
Cody
Telerik

[Daniel]

Without using a coded DialogHandlerDelegate, even the click option doesn't work.  I recorded the same steps again using the mouse left click option, and had virtually the same results.

I'll keep working on this.  I know I can handle it using Alert Dialog Handler, and that may just be the overall answer.  Was just looking into the why.

[Cody]

Hi Daniel,

Without using a coded DialogHandlerDelegate, even the click option doesn't work.

Well I definitely agree you must have some code in there somewhere to handle the dialog for you. The questions left are:

• Where does this code live
• What does the code look like
• How will the dialog get activated (mouse click, invoke event, etc.)

I'll stand by if you need further assistance.

Regards,
Cody
Telerik

[Daniel]

Hi Cody,

At this point, we don't really need to keep going on the subject.  I'll simply handle the alert dialogs in code (like below):

public override void OnBeforeTestStarted()
{
    // custom alert handler to capture screenshot
    AlertDialog myAlertDialog = new AlertDialog(ActiveBrowser, DialogButton.OK);
    myAlertDialog.HandlerDelegate = new DialogHandlerDelegate(MyCustomAlertHandler);
    Manager.DialogMonitor.AddDialog(myAlertDialog);
    Manager.DialogMonitor.Start();
}
public void MyCustomAlertHandler(IDialog dialog)
{
    string ssPath = this.ExecutionContext.DeploymentDirectory.ToString() + @"\Data\alert.png";
    System.Drawing.Bitmap image = dialog.Window.GetBitmap();
    if (File.Exists(ssPath))
    {
        File.Delete(ssPath);
    }
    image.Save(ssPath, System.Drawing.Imaging.ImageFormat.Png);
    dialog.Window.Close();
    try
    {
        dialog.Window.WaitForVisibility(false, 50);
        Log.WriteLine("Alert Handled!");
    }
    catch
    {
        Log.WriteLine("Failed to handle alert!");
    }
}

The dialog is activated off one of the javascript events on the input textbox:

<input type=text size=10 maxlength=10 name=effective_date value="1/1/2001" onkeypress="return filterKeys(event)" onfocus='setDateItem(this, "P")' onblur="reformatDate(this)" onchange='reformatDate(this); javascript:ESOLValidateDateString(frmData.effective_date);checkUpdateCareLevel();'  >

Which one, good guess.  Third party and I haven't checked out all the code.

Like I said, no worries.  No further assistance needed at this point.