Closed Bug 947033 Opened 6 years ago Closed 6 years ago

[B2G][Keyboard Settings] Back arrow in keyboard settings does not return user to Settings.


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

Gonk (Firefox OS)
Not set


(blocking-b2g:1.3+, firefox28 affected, b2g-v1.2 unaffected, b2g-v1.3 fixed)

1.3 C1/1.4 S1(20dec)
blocking-b2g 1.3+
Tracking Status
firefox28 --- affected
b2g-v1.2 --- unaffected
b2g-v1.3 --- fixed


(Reporter: pbylenga, Assigned: timdream)



(Keywords: regression, Whiteboard: [fxos-bug-bash-1.2])


(3 files)

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.

Back button is now a “x” and when tapped brings user to Built-In keyboards instead of Settings portion.

Back button is a “<” and when tapped brings user to Settings portion.

Environmental Variables
Device: Buri v1.3 Mozilla RIL
Build ID: 20131205040201
Gaia: 1dd0e5c644b4c677a4e8fa02e50d52136db489d9
Platform Version: 28.0a1
Firmware Version: 20131115

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
Gaia: 8d762f3376318fd6be390432db750ae4904c9ab6
Platform Version: 26.0
RIL Version: 
Firmware Version: v1.2_20131115
William - Was there any intentional UX changes here made? What's the impact of this bug?
Flags: needinfo?(whsu)
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.
blocking-b2g: --- → 1.3?
Flags: needinfo?(whsu)
Attached image Back arrow icon.png
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)
blocking-b2g: 1.3? → 1.3+
QA Contact: sparsons
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.
Closed: 6 years ago
Depends on: 942140
Keywords: qawanted
Resolution: --- → DUPLICATE
Duplicate of bug: 946250
Okay - if you verified this, then that's good enough here. We don't need to do qawanted then.
Keywords: qawanted
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.
Resolution: DUPLICATE → ---
Whiteboard: [fxos-bug-bash-1.2]
(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.
Component: Gaia::Keyboard → Gaia::Settings
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.
Assignee: nobody → timdream
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] [review]
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 (or, we could even do it now if we don't plan to change DOM structure much).
Attachment #8347864 - Flags: review?(rlu)
Attachment #8347864 - Flags: review?(arthur.chen)
Target Milestone: --- → 1.3 C1/1.4 S1(20dec)
Comment on attachment 8347864 [details] [review]
mozilla-b2g:master PR#14685

r=me for the settings part. Thanks!
Attachment #8347864 - Flags: review?(arthur.chen) → review+
Comment on attachment 8347864 [details] [review]
mozilla-b2g:master PR#14685

r+ for keyboard app part.
Attachment #8347864 - Flags: review?(rlu) → review+
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
I verified this patch. It works.

Many thanks!

* The tested build:
 - Gaia:     e2f0e09e980b1cb3275a0bb033931cb48f9d521c
 - Gecko:
 - BuildID   20131218040201
 - Version   29.0a1
Duplicate of this bug: 949677
Duplicate of this bug: 948700
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
You need to log in before you can comment on or make changes to this bug.