Closed Bug 1016280 Opened 10 years ago Closed 10 years ago

[Settings][Keyboard][V2.0] The "<" icon of keyboard settings page changes to "X" icon

Categories

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

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.0+, b2g-v2.0 verified, b2g-v2.1 verified)

VERIFIED FIXED
2.0 S4 (20june)
blocking-b2g 2.0+
Tracking Status
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: whsu, Assigned: rudyl)

References

Details

(Keywords: regression, Whiteboard: [FT:System-Platform], [3rd-party-keyboard], interaction-design)

Attachments

(3 files)

Attached video WP_20140527_014.mp4
* Description:
  This is a regression bug.
  Returning from built-in keyboard settings, you can see the "<" icon changes to "X" icon.
  Attach the demo video.(WP_20140527_014.mp4)

* Reproduction steps:
  1. Launch the settings app then tap "Keyboards"
  2. Select a settings of built-in keyboard
  3. Tap "<" to go to previous page
  4. Checking the "<" icon of keyboard settings page

* Expected result:
  The "<" icon is at the top-left corner

* Actual result:
  The "<" icon changes to "X" icon.

* Reproduction build: V2.0 (Buri)
 - Gaia      f3b5d74dd3428c89cab06db734c62f3c9dbb8c4d
 - Gecko     https://hg.mozilla.org/mozilla-central/rev/e86a0d92d174
 - BuildID   20140525160203
 - Version   32.0a1
blocking-b2g: --- → 2.0?
Whiteboard: [FT:System-Platform], [3rd-party-keyboard]
Arthur, need your assessment on this one: we need this activity handling *not* to change the button to [x] (but do for other cases)

I suspect this is due to the |postResult| added in another flag.
Flags: needinfo?(arthur.chen)
What we want here is simply opening the settings app. We can launch the app in the usual way if there is no section specified in the activity, thus X button is not displayed.
Flags: needinfo?(arthur.chen)
Keywords: regression
Blocks: 960329
QA Wanted to confirm this doesn't reproduce on 1.4.
Keywords: qawanted
Issue does NOT reproduce on 1.4

Environmental Variables:
Device: Flame 1.4
BuildID: 20140528063006
Gaia: 9d632fd4f8965e15a3204f1609136f1b3b3f8bb3
Gecko: 59f7a4964a77
Version: 30.0
Firmware Version: v10G-2


Environmental Variables:
Device: Open_C 1.4
BuildID: 20140528063006
Gaia: 9d632fd4f8965e15a3204f1609136f1b3b3f8bb3
Gecko: 59f7a4964a77
Version: 30.0
Firmware Version: P821A10V1.0.0B06_LOG_DL
Keywords: qawanted
Rudy, could you figure out what's needed here with Arthur and make sure this is covered in the test?
Flags: needinfo?(rlu)
I'll look into this. Thanks.
Assignee: nobody → rlu
Flags: needinfo?(rlu)
Whiteboard: [FT:System-Platform], [3rd-party-keyboard] → [FT:System-Platform], [3rd-party-keyboard], interaction-design
QA Contact: jmitchell
blocking-b2g: 2.0? → 2.0+
As stated in bug 1016274 comment 7, we would need to decide which activity name to use for the special path: "keyboard app" -> setting app.
So, setting the dependency.
Depends on: 1007600
The regression window MAY be suspect as this issue becomes blocked by another issue while progressing back through builds.

Regressing back through builds in Mozilla-Central-Hamachi the last build this issue reproduces in is 20140522062218. In the prior (1 older) build - 20140522061319 - Pressing the < button on the Keyboard settings page will cause the page to start to slide / transition and then re-draws the same page. (I've posted a video to better convey this - http://www.youtube.com/watch?v=3RODj5cveqw&feature=youtu.be). 
This other issue is present progressing back until 20140512044209 where neither issue is present.

So - for this regression window I've used the build where the issue goes from the prior bug to become this bug instead.

B2G Inbound Regression Window:

Last Working:
Environmental Variables:
Device: Buri 2.0 MOZ
BuildID: 20140522010318
Gaia: b6690c4fb1b2ccda9b7660c3ae2b84c2745bb2e5
Gecko: 951d1d416263
Version: 32.0a1
Firmware Version: v1.2-device.cfg

First Broken:
Environmental Variables:
Device: Buri 2.0 MOZ
BuildID: 20140522012218
Gaia: da4c2e0a13ac0e120bcb0fc4ff822fe9ac0c440c
Gecko: a608d7e190bb
Version: 32.0a1
Firmware Version: v1.2-device.cfg

Last Working Gaia First Broken Gecko: Issue does NOT reproduce
Gaia: b6690c4fb1b2ccda9b7660c3ae2b84c2745bb2e5
Gecko: a608d7e190bb

First Broken Gaia Last Working Gecko: Issue DOES reproduce <indicating a gaia issue>
Gaia: da4c2e0a13ac0e120bcb0fc4ff822fe9ac0c440c
Gecko: 951d1d416263

Gaia pushlog:
https://github.com/mozilla-b2g/gaia/compare/b6690c4fb1b2ccda9b7660c3ae2b84c2745bb2e5...da4c2e0a13ac0e120bcb0fc4ff822fe9ac0c440c
Given the window above, the only suspected bug is bug 1009368.
What's the status of this bug? Have you discussed with Arthur?
Flags: needinfo?(rlu)
As mentioned in Bug 1016274 comment 7,
--
 1. From keyboard app, invoke settings activity with "window disposition" and without section parameter.
    -> This is currently a hack for keyboard app to go back to settings app. 
    1.a The above activity name might be changed after settings inline activity work is done, bug 1007600.

 2. For settings app, we should be do postError() in the case when section parameter is undefined.


Clear the dependency on bug 1007600, since we would keep the same activity name for now before that bug lands.
No longer depends on: 1007600
Flags: needinfo?(rlu)
Status: NEW → ASSIGNED
Patch available for review.
Arthur, could you help on this?

Thanks.

Also did stability check for the added marionette-js test, it all passed with 102 runs.
https://travis-ci.org/mozilla-b2g/gaia/builds/27058721
Attachment #8436496 - Flags: review?(arthur.chen)
Comment on attachment 8436496 [details] [review]
Patch V1 - pull request 20195

Thank you for the patch. r=me with one nit addressed.
Attachment #8436496 - Flags: review?(arthur.chen) → review+
Landed to Gaia master,
https://github.com/mozilla-b2g/gaia/commit/8ec63a4fa1508a8f1ffa3e0b1294fcbe56216917
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.0 S4 (20june)
Hi Rudy! I checked out the latest code on my Flame and noticed that there is still some bugginess. 

For example - the transition is incorrect and moves forward instead of backward which is super confusing.

Also, is this fix supposed to apply to all of settings or just the keyboard bit? I ask but I'm still seeing this issue when going into Sounds-> Manage Ringtones.

Thanks!
Flags: needinfo?(rlu)
(In reply to Tiffanie Shakespeare from comment #17)
> Hi Rudy! I checked out the latest code on my Flame and noticed that there is
> still some bugginess. 
> 
> For example - the transition is incorrect and moves forward instead of
> backward which is super confusing.

Hi Tiffanie,
Yes, this is a known issue. We would invoke settings activity to go back to settings app, which caused the activity style transition.
To be clear, this case is,
 1. Settings launch an app (keyboard app for keyboard settings, or ringtone app for managing ringtone).
 2. The launched app use activity to go back to settings app, because right now, we don't have another way to go back to the launcher.

Alive, do we need Bug 1005827 to resolve this animation issue or any chances that we could do a hack here?

> 
> Also, is this fix supposed to apply to all of settings or just the keyboard
> bit? I ask but I'm still seeing this issue when going into Sounds-> Manage
> Ringtones.

This fix is for keyboard part only. Do we have a bug filed for ringtone?

> 
> Thanks!
Flags: needinfo?(rlu) → needinfo?(alive)
(In reply to Rudy Lu [:rudyl] from comment #18)
> (In reply to Tiffanie Shakespeare from comment #17)
> > Hi Rudy! I checked out the latest code on my Flame and noticed that there is
> > still some bugginess. 
> > 
> > For example - the transition is incorrect and moves forward instead of
> > backward which is super confusing.
> 
> Hi Tiffanie,
> Yes, this is a known issue. We would invoke settings activity to go back to
> settings app, which caused the activity style transition.
> To be clear, this case is,
>  1. Settings launch an app (keyboard app for keyboard settings, or ringtone
> app for managing ringtone).
>  2. The launched app use activity to go back to settings app, because right
> now, we don't have another way to go back to the launcher.
> 
> Alive, do we need Bug 1005827 to resolve this animation issue or any chances
> that we could do a hack here?

I think so. We cannot change transition before we can distinguish.
Flags: needinfo?(alive)
(In reply to Alive Kuo [:alive][NEEDINFO!] from comment #19)
> (In reply to Rudy Lu [:rudyl] from comment #18)
> > (In reply to Tiffanie Shakespeare from comment #17)
> > > Hi Rudy! I checked out the latest code on my Flame and noticed that there is
> > > still some bugginess. 
> > > 
> > > For example - the transition is incorrect and moves forward instead of
> > > backward which is super confusing.
> > 
> > Hi Tiffanie,
> > Yes, this is a known issue. We would invoke settings activity to go back to
> > settings app, which caused the activity style transition.
> > To be clear, this case is,
> >  1. Settings launch an app (keyboard app for keyboard settings, or ringtone
> > app for managing ringtone).
> >  2. The launched app use activity to go back to settings app, because right
> > now, we don't have another way to go back to the launcher.
> > 
> > Alive, do we need Bug 1005827 to resolve this animation issue or any chances
> > that we could do a hack here?
> 
> I think so. We cannot change transition before we can distinguish.

After thinking again, I am going to file a bug to track this.
See Also: → 1023045
bug 1023045 filed to handle the ringtone case for the wrong [X] icon when coming back to setting app.
So this bug no longer block bug 960329.
No longer blocks: 960329
Thank you!
Thanks everyone! Verified this patch.
The bug cannot be reproduced on the latest V2.0 build

* Build Information:
 - Gaia      6aa07ea10420bd77f93d7415b5e34d89acc47a7e
 - Gecko     https://hg.mozilla.org/releases/mozilla-aurora/rev/c83fdcf0b735
 - BuildID   20140611160205
 - Version   32.0a2
Status: RESOLVED → VERIFIED
Attached video video of issue verify
This issue has been verified successfully on Flame v2.0 & v2.1
See attachment: verify_video.MP4
Reproducing rate: 0/5
Flame 2.0 versions:
Gaia-Rev        99e4594c66aa3738d58b0cb44bd885a87a063b6e
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/f91abc6127d9
Build-ID        20141125000201
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141125.035023
FW-Date         Tue Nov 25 03:50:34 EST 2014
Bootloader      L1TC00011880

Flame 2.1 versions:
Gaia-Rev        1bdd49770e2cb7a7321e6202c9bf036ab5d8f200
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/db893274d9a6
Build-ID        20141125001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141125.040617
FW-Date         Tue Nov 25 04:06:28 EST 2014
Bootloader      L1TC00011880
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: