STR: 1. Flash latest build 2. Start a logcat and boot up the device Expected: 2. The device boots up as expected Actual: 2: The device returns E/GeckoConsole( 109): [JavaScript Error: "TypeError: self.keyboardLayouts[initType] is undefined" {file: "app://system.gaiamobile.org/js/keyboard_manager.js" line: 139}] This is reproducing on: Gecko http://hg.mozilla.org/mozilla-central/rev/b6c29e434519 Gaia 9fb5802df60a9081846d704def01df814ed8fbd4 BuildID 20130901040215 Version 26.0a1

This error is causing all of our Gaia-UI tests to fail: First failing build: http://qa-selenium.mv.mozilla.com:8080/job/b2g.unagi.mozril.gaia.master.ui/146/ (Sep 1, 2013 5:56:48 AM)

Last klnown good build: Gecko http://hg.mozilla.org/mozilla-central/rev/4ba8dda1ee31 Gaia 8b6a2452cbf0c3458581d929d4ebf77a53ea0b07 BuildID 20130831040212 Version 26.0a1 First failing build: Gecko http://hg.mozilla.org/mozilla-central/rev/b6c29e434519 Gaia 9fb5802df60a9081846d704def01df814ed8fbd4 BuildID 20130901040215 Version 26.0a1

git diff between the 2 builds: https://github.com/mozilla-b2g/gaia/compare/8b6a2452cbf0c3458581d929d4ebf77a53ea0b07...9fb5802df60a9081846d704def01df814ed8fbd4

+cc Gary. We should able to come up with a fix for this issue soon. Thanks for bringing this up.

a new build is out: Gecko http://hg.mozilla.org/mozilla-central/rev/1179318fb5aa Gaia 0457c197a382a219b1050fd2ccfddfdbbdad7a92 BuildID 20130902040202 Version 26.0a1 And it has the same issue: http://qa-selenium.mv.mozilla.com:8080/job/b2g.unagi.mozril.gaia.master.ui/149/

(In reply to Rudy Lu [:rudyl] from comment #4) > +cc Gary. > > We should able to come up with a fix for this issue soon. > Thanks for bringing this up. This needs the associated patch that landed to cause this backed out. We can't cause all of our tests to be broken.

Was this fixed by https://github.com/mozilla-b2g/gaia/commit/2acb6405c5b986a64f4386a18719b2799f5bff6e by any chance?

Actually meant to say - fixed by https://github.com/mozilla-b2g/gaia/commit/66bae2930b1263898da4e8ee5ef49ac2fabdbfd9? Trying to find out if this is already resolved or not.

We found the root cause and we fixed it on bug 893554.

Jason, No, that change cannot fix this issue. However, we have identified the root cause and should be able to land the fix to Gaia master in about 12 hours. (Right now, it is 00:26 in Taipei) If possible, I'd like to ask we don't back out that big changes about the new IME framework. If that cannot work from your point of view, then please help make sure the changes we made to gaia-ui-tests will be backed out to sync up with Gaia, see Bug 911661 for details. Thanks and sorry for any inconvenience caused.

(In reply to GaryChen [:GaryChen] from comment #9) > We found the root cause and we fixed it on bug 893554. Sorry, here is the right bug 909706.

(In reply to Rudy Lu [:rudyl] from comment #10) > Jason, > > No, that change cannot fix this issue. > However, we have identified the root cause and should be able to land the > fix to Gaia master in about 12 hours. > (Right now, it is 00:26 in Taipei) > > If possible, I'd like to ask we don't back out that big changes about the > new IME framework. > If that cannot work from your point of view, then please help make sure the > changes we made to gaia-ui-tests will be backed out to sync up with Gaia, > see Bug 911661 for details. I don't think that's feasible. When large features land, if a critical regression is found, we need to back out, make the necessary fixes, and try landing again. Otherwise, we'll quickly get many people blocked - whether that be manual testing or device automation. I don't understand what you mean by backing out gaia ui test changes to sync up with Gaia. The changes made in Gaia caused the failure in Gaia UI Tests, not the other way around, to my understanding. Note that there are cases where changes in Gaia could cause failures in Gaia UI Tests that's expected - significant UX changes, IDs, etc. In that case, I think the best course of action is to raise communication early with anyone involved with integration automation that touches on the code in question (e.g. Marionette JS, Gaia UI Tests). Then, work out a plan with the integration automation owners to ensure that the timeframe of expected failures is minimized.

(In reply to GaryChen [:GaryChen] from comment #11) > (In reply to GaryChen [:GaryChen] from comment #9) > > We found the root cause and we fixed it on bug 893554. > > Sorry, here is the right bug 909706. Okay. Added that bug as a dependency then.

bug 909706 was be fixed and patch landed in b2g master. https://github.com/mozilla-b2g/gaia/commit/9839638881e22c53ee54d7a27a7d5c5e2b2c1081 https://github.com/mozilla-b2g/gaia/commit/65abc8c4cd0138abfa58f69acd33c32e315d8d2c

(In reply to Jason Smith [:jsmith] from comment #12) > (In reply to Rudy Lu [:rudyl] > > I don't think that's feasible. When large features land, if a critical > regression is found, we need to back out, make the necessary fixes, and try > landing again. Otherwise, we'll quickly get many people blocked - whether > that be manual testing or device automation. > I understand your concern, and we have done our best to try to make all aspects that we know be able to work. However, it seems we still break ui-tests on Jenkin which is an area we have idea that we will affect. > I don't understand what you mean by backing out gaia ui test changes to sync > up with Gaia. The changes made in Gaia caused the failure in Gaia UI Tests, > not the other way around, to my understanding. Note that there are cases > where changes in Gaia could cause failures in Gaia UI Tests that's expected > - significant UX changes, IDs, etc. In that case, I think the best course of > action is to raise communication early with anyone involved with integration > automation that touches on the code in question (e.g. Marionette JS, Gaia UI > Tests). Then, work out a plan with the integration automation owners to > ensure that the timeframe of expected failures is minimized. The problem is that we change some element naming in Gaia system app, on which Gaia-ui-test would depend to find the right element and trigger the following test actions. If we revert Gaia changes that have the new naming, then the corresponding naming changes in Gaia-ui-tests should be reverted as well. I know this is not optimal, so we might need to discuss with automation team to see how we can come up with a better way. Thanks.

This is verified FIXED in today's build: Gecko: 12c7f19bacec5f2a6bf116f639752ba78ca85a86 Gaia: c6d58088f207829d96e7bb33ddacf990e90752fb