Closed Bug 1022475 Opened 6 years ago Closed 6 years ago
Organizing keyboard transition management to another script
+++ This bug was initially created as a clone of Bug #1017327 +++ Let me use this bug to fix and land bug 1017327 comment 12.
User Story: (updated)
(In reply to Zac C (:zac) from bug 1017327 comment #14) > Note in comment#13 that this failed on Mac OSX, but passed on linux64 (hence > how it passed on Travis). > > I can see similar failures on Mac OSX/Gaia-Try for this pull. > > The pattern between both appears to be a timing problem, and possibly this > code is invalid now: > https://github.com/mozilla-b2g/gaia/blob/master/tests/python/gaia-ui-tests/ > gaiatest/apps/keyboard/app.py#L146 I would like to fix this too. What's the generic way of fixing it? Make sure translateY = 0 on the keyboard frame?
https://github.com/timdream/gaia/tree/input-manage-transition2 I have fix the tests in JS for it to wait for transition. Not sure how to do it in Python.
You could look up the docs, but I'll still do it for you anyway: keyboards.value_of_css_property('transform') is 'matrix(1, 0, 0, 1, 0, 0)'
Zac, thanks, I am sorry I didn't realized there was a doc.
(In reply to Zac C (:zac) from comment #3) > You could look up the docs, but I'll still do it for you anyway: > keyboards.value_of_css_property('transform') is 'matrix(1, 0, 0, 1, 0, 0)' It turns out this didn't work and Askeing simply suggests me to use |keyboards.location['y'] == 0| and it passes locally (the original didn't; I can't test it yesterday because mozdownload didn't work yesterday). I've push the fixes on the pull request and try, although I am not really sure if Try will pick up the latest force push. I will submit another try run if it didn't. https://travis-ci.org/mozilla-b2g/gaia/builds/27186258 https://tbpl.mozilla.org/?tree=Try&rev=32b008ff4cc5 (FYI the original failure was https://tbpl.mozilla.org/?rev=1cd0fb0a175a&tree=B2g-Inbound&showall=1)
Travis-CI passed but I need to rebase the branch to avoid bug 1023001.
Unit test failure due to bug 938045, should not be related. Gu tests on OSX passes... not sure why I didn't see other Gu runs for Linux builds.
I can see Gu on Linux turned green too. However for the sake of the stability between builds let me land this tomorrow instead.
Status: NEW → ASSIGNED
Comment on attachment 8436863 [details] [review] mozilla-b2g:master PR#20224 This carries over r+ from bug 1017327.
Attachment #8436863 - Flags: review+
backout for perma-red like https://travis-ci.org/mozilla-b2g/gaia/jobs/27275277#L2712 master: 83eff1438b04d1ad2f35a186eeec12201c10544d TPBL of the merge commit is still running: https://tbpl.mozilla.org/?tree=B2g-Inbound&rev=44cbd2938fcb
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The Travis-CI run of the revert commit is https://travis-ci.org/mozilla-b2g/gaia/builds/27281471
Runs of the new pull request https://tbpl.mozilla.org/?tree=Gaia-Try&rev=764a1e06a5bf https://travis-ci.org/mozilla-b2g/gaia/builds/27281875
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #12) > backout for perma-red like > https://travis-ci.org/mozilla-b2g/gaia/jobs/27275277#L2712 Looks like false alarm, merge commits behind mine does not have this error. test_a11y_unlock_to_homescreen.py sometimes fail even on TBPL, see bug 1022132. I am going to merge the pull request again after it turns green.
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) (please ni?) from comment #15) > Runs of the new pull request > > https://tbpl.mozilla.org/?tree=Gaia-Try&rev=764a1e06a5bf > > https://travis-ci.org/mozilla-b2g/gaia/builds/27281875 I am convinced that I am not at the fault here, even though UI tests fails 4 out of 10.... I hope intermittent failures got addressed soon.
You need to log in before you can comment on or make changes to this bug.