Need a way to ensure the toolbar is visible when clicking a button using the emulator

[Olivier Tilloy]

Since revision 805 in lp:ubuntu-ui-toolkit, the default behaviour of the toolbar changed: it is initially shown, and automatically hides after a timeout of 5 seconds if not interacted with.

This broke a number of existing autopilot tests in apps. The most affected app seems to be gallery-app. This is particularly visible on desktop and/or slow configurations: autopilot sees the toolbar up, starts moving the cursor towards one of its buttons, but before it reaches it the toolbar has started automatically hiding and when the cursor reaches the position where the button was it’s no longer there.

A possible workaround is to first ensure that the toolbar is hidden, then reveal it, and then click the button (when manually revealed, the toolbar won’t autohide). This is not really clean though, doesn’t really simulate what a real user would do, and it’s error prone (those failures are race conditions, so they may surface at any time, making the tests flaky).

The proper way to fix the problem without requiring updates to the existing autopilot tests is to ensure that when open_toolbar() is called, even if it’s already open some interaction with it happens, to ensure it won’t autohide.

[Olivier Tilloy (osomon)]

I’m not sure the approach in the linked branch (revision 826) is correct. I wouldn’t expect Toolbar.click_button() to reveal the toolbar on my behalf if it isn’t up yet (the goal of the emulators is to provide primitives to ease the interaction with the widgets like a normal user would). And it would make all the existing code like this redundant:

    self.main_view.open_toolbar().click_button("…")

because open_toolbar() could then be removed.

I think what we really need is open_toolbar() to do some sort of dummy interaction with the toolbar itself even if it’s already up, to prevent it from later auto-hiding.

A first step would be to have open_toolbar() move the cursor to the toolbar’s position even if it’s already open, thus reducing the mouse move needed to access a button. This wouldn’t be enough, but I’m willing to bet it would already fix a number of issues we’re seeing on otto.

[Tim Peeters (tpeeters)]

yes, open_toolbar().click_button("_") could then be replaced by get_toolbar().click_button("_"). I kept open_toolbar() not to break the current AP apps but it would be deprecated.

So you propose that open_toolbar() would close the toolbar if it is open, and then open again? And only open it if it was closed?

You would never click a button without having the toolbar open already, so I don't see a problem with click_button() opening the toolbar if needed.

[Olivier Tilloy (osomon)]

I’m not proposing that open_toolbar close it first, I’m proposing that if it’s already open the emulator does some sort of interaction with it (details to be figured out) to ensure it won’t autohide.

Your proposal works for click_button(), but what if I want to interact differently with the toolbar. E.g., what if the toolbar contains a TextField, or some other widget? I will still want to ensure that when I call open_toolbar(), it remains open.

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:ubuntu-ui-toolkit at revision None, scheduled for release in ubuntu-ui-toolkit, milestone Unknown

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubuntu-ui-toolkit - 0.1.46+14.04.20131108.3-0ubuntu1

---------------
ubuntu-ui-toolkit (0.1.46+14.04.20131108.3-0ubuntu1) trusty; urgency=low

  [ Leo Arias ]
  * Add a check for the autopilot version on the emulator init. (LP:
    #1248570)
  * Ensure the toolbar is opened when clicking a toolbar in autopilot
    tests. (LP: #1248487)

  [ Nicolas d'Offay ]
  * Reverted API break on the selectors. (LP: #1248646)

  [ tpeeters ]
  * Ensure the toolbar is opened when clicking a toolbar in autopilot
    tests. (LP: #1248487)
  * before fixing the actual bug, the test gives me these errors: QWARN
    : tst_MainView::testNoWarnings_bug186065()
    unity::action::ActionManager::ActionManager(QObject*): Could not
    determine application identifier. HUD will not work properly.
    Provide your application identifier in $APP_ID environment variable.
    QWARN : tst_MainView::testNoWarnings_bug186065()
    file:///home/tim/dev/ubuntu-ui-
    toolkit/fix1244660/modules/Ubuntu/Components/MainView.qml:257:
    TypeError: Cannot call method 'hasOwnProperty' of null **
    (process:27191): CRITICAL **: Unable to get session bus: Operation
    was cancelled QWARN : tst_MainView::testNoWarnings_bug186065() Don't
    know how to handle 'QList<QQmlError>', use qRegisterMetaType to
    register it. PASS : tst_MainView::testNoWarnings_bug186065() PASS :
    tst_MainView::cleanupTestCase() Totals: 8 passed, 0 failed, 0
    skipped ********* Finished testing of tst_MainView ********* I get
    the same when I execute unit_x11/tst_orientation/tst_orientation:
    QWARN : tst_OrientationTest::test_defaults() Don't know how to
    handle 'QList<QQmlError>', use qRegisterMetaType to register it.
    PASS : tst_OrientationTest::test_defaults() Should I execute the
    tests in a different way?. (LP: #186065, #1244660)

  [ Robert Bruce Park ]
  * (no message)

  [ Ubuntu daily release ]
  * Automatic snapshot from revision 828
 -- Ubuntu daily release <email address hidden> Fri, 08 Nov 2013 22:02:57 +0000