Closed Bug 1014820 Opened 9 years ago Closed 9 years ago

[Calendar] remove the waitForKeyboardHide from marionette tests

Categories

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

x86
All
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
2.0 S3 (6june)

People

(Reporter: mmedeiros, Assigned: mmedeiros)

References

Details

Attachments

(1 file)

there is an ongoing discussion about marionette-apps switchToApp (Bug 1003795) and it seems that they will remove any `client.apps.switchToApp('app://keyboard.gaiamobile.org')` calls.

since waitForKeyboardHide is a temporary solution, I think we should just go ahead and disable the keyboard altogether during the calendar app tests.

:asuth said that we probably need `{ prefs: { 'dom.mozInputMethod.enabled': false }`, `settings: { 'keyboard.ftu.enabled': false }` and `'focusmanager.testmode': true`.
See Also: → 1003795
So I was trying to awkwardly cram some stuff in IRC there.  More explicitly, I think the following should stop the keyboard from bothering you and avoid other test wrinkles.  (The testmode :mcav found very important and other sources have indicated this is also key for focus-related issues.)

  var profileSettings = {
    prefs: {
      // Disable the keyboard for now; this can be re-enabled when we have
      // implemented transition/animation acceleration.  While there are a set
      // of edge-cases that the keyboard can cause, we have no tests for this
      // area yet.
      'dom.mozInputMethod.enabled': false,
      // Do not require the B2G-desktop app window to have focus (as per the
      // system window manager) in order for it to do focus-related things.
      'focusmanager.testmode': true,
    },
    settings: {
      // Explicitly disable the FTU (first-run) series of cards
      'ftu.manifestURL': '',
      // We also wouldn't want the keyboard FTU, although we've disabled the
      // keyboard.
      'keyboard.ftu.enabled': false,
    }
  };
  marionette.client(profileSettings);
This sounds great actually.
just FYI that you don't need the following setting anymore, since that functionality has been completely removed from Gaia codebase.
 
'keyboard.ftu.enabled': false
(In reply to Rudy Lu [:rudyl] from comment #3)
> just FYI that you don't need the following setting anymore, since that
> functionality has been completely removed from Gaia codebase.

Even better!  Thanks!
while trying to check if my fix for the toggle_calendar_test.js could fail on Travis I encountered a really weird error:

  1) toggle calendar "before each" hook:

  NoSuchElement: (7) Unable to locate element: iframe[src*="homescreen.gaiamobile.org"]

  Remote Stack:
  <none>
  at Error.MarionetteError (/home/travis/build/millermedeiros/gaia/node_modules/marionette-client/lib/marionette/error.js:67:13)
  at Object.Client._handleCallback (/home/travis/build/millermedeiros/gaia/node_modules/marionette-client/lib/marionette/client.js:476:19)
  at /home/travis/build/millermedeiros/gaia/node_modules/marionette-client/lib/marionette/client.js:510:21
  at TcpSync.send (/home/travis/build/millermedeiros/gaia/node_modules/marionette-client/lib/marionette/drivers/tcp-sync.js:100:10)
  at Object.send (/home/travis/build/millermedeiros/gaia/node_modules/marionette-client/lib/marionette/client.js:457:36)
  at Object.Client._sendCommand (/home/travis/build/millermedeiros/gaia/node_modules/marionette-client/lib/marionette/client.js:503:19)
  at Object._findElement (/home/travis/build/millermedeiros/gaia/node_modules/marionette-client/lib/marionette/client.js:1303:19)
  at Object.findElement (/home/travis/build/millermedeiros/gaia/node_modules/marionette-client/lib/marionette/client.js:1352:32)
  at /home/travis/build/millermedeiros/gaia/node_modules/marionette-apps/lib/launch.js:50:21
  at modifiedTest (/home/travis/build/millermedeiros/gaia/node_modules/marionette-client/lib/marionette/client.js:646:22)
  at Object.Client.waitForSync (/home/travis/build/millermedeiros/gaia/node_modules/marionette-client/lib/marionette/client.js:671:9)
  at Object.Client.waitFor (/home/travis/build/millermedeiros/gaia/node_modules/marionette-client/lib/marionette/client.js:650:60)
  at launch (/home/travis/build/millermedeiros/gaia/node_modules/marionette-apps/lib/launch.js:49:10)
  at Object.Calendar.launch (/home/travis/build/millermedeiros/gaia/apps/calendar/test/marionette/lib/calendar.js:39:17)
  at Context.<anonymous> (/home/travis/build/millermedeiros/gaia/apps/calendar/test/marionette/toggle_calendar_test.js:12:9)
  at callFn (/home/travis/build/millermedeiros/gaia/node_modules/mocha/lib/runnable.js:223:21)
  at Hook.Runnable.run (/home/travis/build/millermedeiros/gaia/node_modules/mocha/lib/runnable.js:216:7)
  at next (/home/travis/build/millermedeiros/gaia/node_modules/mocha/lib/runner.js:258:10)
  at /home/travis/build/millermedeiros/gaia/node_modules/mocha/lib/runner.js:270:7
  at done (/home/travis/build/millermedeiros/gaia/node_modules/mocha/lib/runnable.js:185:5)
  at /home/travis/build/millermedeiros/gaia/node_modules/mocha/lib/runnable.js:199:9
  at Object.executeHook (/home/travis/build/millermedeiros/gaia/node_modules/marionette-client/lib/marionette/client.js:369:18)
  at process._tickCallback (node.js:415:13)


and this error is exactly on the waitForKeyboardHide code and is really hard to replicate. so I'm bumping the priority and marking this as blocker.

BTW, if I add the `settings.ftu.manifestURL = ''` to the `marionette.client()` call it gets stuck on the lock screen (B2G desktop on mac) and we don't even need that on the calendar app anyway.

Thanks for all the help!
Assignee: nobody → mmedeiros
Blocks: 1007519
Target Milestone: --- → 2.0 S4 (20june)
executed all calendar tests more than 20+ on Travis and seems pretty stable (each run should call `createEvent` ~30 times).
Attachment #8434542 - Flags: review?(gaye)
Attachment #8434542 - Flags: review?(gaye) → review+
landed on master: https://github.com/mozilla-b2g/gaia/commit/3cb10b777530d063a9b32f07241d4230c1f18096
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: 2.0 S4 (20june) → 2.0 S3 (6june)
You need to log in before you can comment on or make changes to this bug.