Closed Bug 965131 Opened 10 years ago Closed 10 years ago

[Keyboard Manager] Keyboard should not block touch interaction of elements behind it when it starts to hide

Categories

(Firefox OS Graveyard :: Gaia::Keyboard, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: mmedeiros, Unassigned)

References

Details

I was trying to debug some intermittent failures on Travis-CI for Gaia::Calendar and found out that bug is  caused by the keyboard. If I try to click an anchor element, that is at the bottom of the screen, just after displaying the keyboard, the click event won't work as expected in some cases.

It was really hard to pin point what was the cause of the problem, since I couldn't replicate it locally, and it was only happening between 10-30% of the time on Travis-CI. - Taking screenshots also changed the test behavior (I believe the screenshot adds a delay - or maybe kills the CSS transition, don't know).

I saw that https://bugzilla.mozilla.org/show_bug.cgi?id=796452 contains some info about why the attribute `[mozpasspointerevents="true"]` was added to the keyboard `<iframe>`, but it would be really helpful to have another special attribute to disable touch interactions of all the child elements (including `<iframe>` content), even if children has `pointer-events:auto`.

Another option is to access the `iframe.contentDocument.body` from inside the `keyboard_manager.js` and toggle a class `.hide` (that would set `pointer-events:none` on the `#keyboard`) during `KeyboardManager.showKeyboard` and `KeyboardManager.hideKeyboard`. - I did a test with it and it solves my problem 100% of the time; I can submit a patch if you guys agree that it is a valid solution.

I believe this change will avoid many issues on the Marionette tests and make them easier to write as well.
Blocks: 916411
a temporary fix is to use a helper method to wait until the keyboard is hidden, using the marionette-apps plugin:

    function waitForKeyboardHide() {
      var originalAppSrc = client.executeScript(function() {
        return location.protocol +'//'+ location.hostname;
      });

      // need to go back to top most frame before being able to switch to
      // a different app!!!
      client.switchToFrame();
      client.apps.switchToApp('app://keyboard.gaiamobile.org');
      client.waitFor(function() {
        return client.executeScript(function() {
          return document.hidden;
        });
      });

      client.switchToFrame();
      client.apps.switchToApp(originalAppSrc);
    }

not that clean, but works.
I think you should accept comment #1 as a permanent solution. Manipulating the keyboard app/DOM to change its behaviour is a pretty bad practice, as an Automation engineer I would never dream of doing that for fear it will mask a real keyboard regression sometime in the future.

If you know what's happening, and in this case you do, then you can make it all work properly without hacks without any big deal.
marking as wont fix since we can disable the keyboard during marionette tests:

    marionette.client({
      prefs: {
        'dom.mozInputMethod.enabled': false,
      }
    });
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.