Description: After tapping back arrow in built-in keyboard, the back arrow in Keyboard settings becomes an “X” instead of a “<” and it returns the user to Built-in Keyboard instead of Settings. Repro Steps: 1) Updated Buri to Build ID: 20131204004003 2) Launch Settings App 3) Navigate to Keyboards 4) Tap Built-In Keyboards 5) Tap on the Back button 6) After user is returned to Keyboards observe back arrow and tap it and observe. Actual: Back button is now a “x” and when tapped brings user to Built-In keyboards instead of Settings portion. Expected: Back button is a “<” and when tapped brings user to Settings portion. Environmental Variables Device: Buri v1.3 Mozilla RIL Build ID: 20131205040201 Gecko: http://hg.mozilla.org/mozilla-central/rev/725c36b5de1a Gaia: 1dd0e5c644b4c677a4e8fa02e50d52136db489d9 Platform Version: 28.0a1 Firmware Version: 20131115 Notes: Repro frequency: 5/5, 100% Attached: logcat

Issue does not reproduce on v1.2 Environmental Variables Device: Buri v1.2 COM RIL Build ID: 20131204004003 Gecko: http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/758f3fb32dda Gaia: 8d762f3376318fd6be390432db750ae4904c9ab6 Platform Version: 26.0 RIL Version: 01.02.00.019.102 Firmware Version: v1.2_20131115

William - Was there any intentional UX changes here made? What's the impact of this bug?

Hi, Jason, The bug related to bug 914093. As peter mentioned, the UI should displays settings page after tapping "<" But I don't know who changed the V1.3 user flow. I will contact UX or Rudy to double check it later because I am out of office. Keep needinfo to remind myself. The bug impacts the user flow and user needs to use home button/card view to exit keyboard settings page. Many thanks.

Hi, all, I think it is a V1.3 bug of keyboard setting page. The first time I saw the "<" icon but the "<" icon became "X" icon after FxOS went back to the same keyboard settings page. Attaching the screenshot. Please fix it. Thanks.

Triage: this is a regression. There is a similar bug but I cannot remember the bug number. We need to identify the regressed bug and back that out (to maybe fix both bugs)

This issue occurs all the way back to the first working Buri 1.3 Build ID: 20130919040201 Gaia 0dedb5b3789afc638a0c7c67652937fcb30e77d2 SourceStamp 803189f35921 BuildID 20130919040201 Version 27.0a1

With bisection I can verify this bug is introduced by bug 942140 and fixed by bug 946250.

Okay - if you verified this, then that's good enough here. We don't need to do qawanted then.

Hello Tim - During the bug bash today we still see this bug on Buri using the mozilla central build: Gaia 8952898bbc98dd31e25b647203791cf129867ff1 SourceStamp 1ad9af3a2ab8 BuildID 20131212040203 Version 29.0a1 The duped bug, however, does appear to be fixed on Mozilla central.

(In reply to Sarah Parsons from comment #7) > This issue occurs all the way back to the first working Buri 1.3 Build ID: > 20130919040201 > > Gaia 0dedb5b3789afc638a0c7c67652937fcb30e77d2 > SourceStamp 803189f35921 > BuildID 20130919040201 > Version 27.0a1 Can go farther back in the regression range? I'm looking for a regression range down to a day.

This happens on all 1.3 builds because it originally occurred on 1.2. It was fixed on 1.2 but not on 1.3 See bug 914093 for reference.

Yeah, I saw that too today. I suspect we are seeing different bugs with the same behavior. Thanks for reopening the issue.

Will bisect again.

OK. I didn't bisect correctly the first time and it doesn't make sense to do so again. The "regression" here is actually caused by the desired behavior implemented in bug 942140. We used the same MozActivity call to go back to settings as well as invoking settings as a dialog, so the behavior will always be the same (replace the "back" button with "x"). I will provide a fix the that by tweak the activity call a bit.

Comment on attachment 8347864 [details] mozilla-b2g:master PR#14685 Arthur, could you review the Settings app part of the patch? Feel free to redirect to Kaze if you don't have time to do it. Rudy, could you help on Keyboard app part? Thanks. It's sad that these interactions are not covered by integration tests -- I can only manually make sure I didn't regress bug 942140 or bug 946250. We should schedule test-writing cycles for Settings.next (or, we could even do it now if we don't plan to change DOM structure much).

Comment on attachment 8347864 [details] mozilla-b2g:master PR#14685 r=me for the settings part. Thanks!

Comment on attachment 8347864 [details] mozilla-b2g:master PR#14685 r+ for keyboard app part. Thanks.

master: https://github.com/mozilla-b2g/gaia/commit/de298a34c9673098665d44ce361f402f6c2b8a16

I verified this patch. It works. Many thanks! * The tested build: - Gaia: e2f0e09e980b1cb3275a0bb033931cb48f9d521c - Gecko: http://hg.mozilla.org/mozilla-central/rev/862cb6a1cc88 - BuildID 20131218040201 - Version 29.0a1

Uplifted de298a34c9673098665d44ce361f402f6c2b8a16 to: v1.3: c1845bc43db6340d162034f8656e66a137ed1523

The timer makes me sad...please try this, window.addEventListener('visibilitychange', function() { setTimeout(function() {window.close();}); });

I found a bug after we merged the patch into V1.3 branch. Bug 959116