Linux Chrome driver on Sauce Labs causes spurious test failures

[karlht]

[Another Webdriver/Sauce problem.]

Running the test through a local Selenium/Webdriver works fine; running it on Sauce causes the error shown in the image below:

Test script is at https://github.com/karlht/services-tools/blob/master/fxa-webdriver-tests/multi123done.py -- results on Sauce are at https://saucelabs.com/tests/aa73da25fd354712903132015e5d50ca

Between this and #1324, I'm prepared to declare Sauce tests as 'nice for a first pass at possible problems, but not definitive' -- they require local and/or manual verification too much of the time.

[vladikoff]

See theintern/intern#210

Nevermind, that's a different thing.

[vladikoff]

@shane-tomlinson This is caused by our autofocus logic in the BaseView.

Is force autofocus logic only for IE < 10? Can we disable it for other browsers?

[shane-tomlinson]

@vladikoff - the autofocus logic is for Firefox, Chrome, and IE. Browsers usually only autofocus an element if the element is in the DOM before DOMContentLoaded. You can see the default browser behavior by commending out the attemptFocus on line 245 of base.js.

• Firefox: no autofocus happens, ever.
• Chrome: only the first page has an element focused.
• Safari: sane.
• Opera: sane.
• IE11: only the first page has an element focused.

[shane-tomlinson]

@karlht - can you copy over a log so we have a record of it and can use it to debug?

[shane-tomlinson]

@karlht - do the elements need to be focused before you send off key strokes to them?

[vladikoff]

can you copy over a log so we have a record of it and can use it to debug? - do the elements need to be focused before you send off key strokes to them?

No need for the logs. I've already researched this problem over the last few days. Removing attemptFocus from BaseView gives me 100% functional pass in ChromeDriver.

Here is a more detailed description with screenshots of what happens on SauceLabs or locally in Chrome: theintern/leadfoot#6

The ChromeDriver is a lot faster than the autofocus logic and autofocus causes the typing to fail.
We need to either 1. disable the autofocusing for functional tests or 2. disable that autofocusing for Chrome. 3. remove attemptFocus, I guess this might not be an option.

[karlht]

I'm in a laptops-closed QA work-week today, but I'll get a log copied over as soon as I can.

[vladikoff]

@karlht see my above comment. Don't worry about the logs. Enjoy the work week :)

[shane-tomlinson]

The ChromeDriver is a lot faster than the autofocus logic and autofocus causes the typing to fail.
We need to either 1. disable the autofocusing for functional tests or 2. disable that autofocusing for Chrome. 3. remove attemptFocus, I guess this might not be an option.

I'm confused - what is the actual problem? Does the ChromeDriver enter in keyboard input and then we try to focus the element after some input has already been entered? Or, does the ChromeDriver enter input into the first field and move on to the second field before we have focused the first field?

Or, another theory - we give the order to autofocus on view startup. The element focus() function is called. ChromeDriver fills out the first field, and moves onto the second field. The 'focus' event of the first field fires, and we try to update the selection back into the first field.

I'm amenable to 1. I'd rather fix the problem if we can.

I want to try changing the focus function to:

    focus: function (which) {
      try {
        var focusEl = this.$(which);
        // place the cursor at the end of the input when the
        // element is focused.
        focusEl.one('focus', function () {
          // focus was lost already. wah wah.
          if (! focusEl.is(':focus')) {
             return;
          }
          try {
            this.selectionStart = this.selectionEnd = this.value.length;
          } catch (e) {
            // This can blow up on password fields in Chrome. Drop the error on
            // the ground, for whatever reason, it still behaves as we expect.
          }
        });
        focusEl.get(0).focus();
      } catch (e) {
        // IE can blow up if the element is not visible.
      }
    },

The comment in the catch statement is interesting:

       // This can blow up on password fields in Chrome. Drop the error on
       // the ground, for whatever reason, it still behaves as we expect.

Maybe it doesn't behave as expected?

[vladikoff]

This is now happening sometimes in latest stable Firefox with Selenium 2.43.1 as well: