Closed
Bug 1016280
Opened 11 years ago
Closed 11 years ago
[Settings][Keyboard][V2.0] The "<" icon of keyboard settings page changes to "X" icon
Categories
(Firefox OS Graveyard :: Gaia::Settings, defect)
Tracking
(blocking-b2g:2.0+, 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)
* 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
Reporter | ||
Updated•11 years ago
|
blocking-b2g: --- → 2.0?
Whiteboard: [FT:System-Platform], [3rd-party-keyboard]
Comment 1•11 years ago
|
||
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)
Comment 2•11 years ago
|
||
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)
Reporter | ||
Updated•11 years ago
|
Keywords: regression
Comment 4•11 years ago
|
||
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
Comment 5•11 years ago
|
||
Rudy, could you figure out what's needed here with Arthur and make sure this is covered in the test?
Flags: needinfo?(rlu)
Assignee | ||
Comment 6•11 years ago
|
||
I'll look into this. Thanks.
Assignee: nobody → rlu
Flags: needinfo?(rlu)
Updated•11 years ago
|
Whiteboard: [FT:System-Platform], [3rd-party-keyboard] → [FT:System-Platform], [3rd-party-keyboard], interaction-design
Updated•11 years ago
|
Keywords: regressionwindow-wanted
Updated•11 years ago
|
QA Contact: jmitchell
Updated•11 years ago
|
blocking-b2g: 2.0? → 2.0+
Assignee | ||
Comment 8•11 years ago
|
||
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
Comment 10•11 years ago
|
||
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
Keywords: regressionwindow-wanted
Comment 11•11 years ago
|
||
Given the window above, the only suspected bug is bug 1009368.
Comment 12•11 years ago
|
||
What's the status of this bug? Have you discussed with Arthur?
Flags: needinfo?(rlu)
Assignee | ||
Comment 13•11 years ago
|
||
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)
Assignee | ||
Updated•11 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 14•11 years ago
|
||
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 15•11 years ago
|
||
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+
Assignee | ||
Comment 16•11 years ago
|
||
Landed to Gaia master,
https://github.com/mozilla-b2g/gaia/commit/8ec63a4fa1508a8f1ffa3e0b1294fcbe56216917
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
status-b2g-v2.0:
--- → fixed
Target Milestone: --- → 2.0 S4 (20june)
Comment 17•11 years ago
|
||
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)
Assignee | ||
Comment 18•11 years ago
|
||
(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)
Comment 19•11 years ago
|
||
(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)
Comment 20•11 years ago
|
||
(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.
Comment 21•11 years ago
|
||
https://bugzilla.mozilla.org/show_bug.cgi?id=1023046 is tracking transition issues.
Assignee | ||
Comment 22•11 years ago
|
||
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.
Comment 23•11 years ago
|
||
Thank you!
Updated•11 years ago
|
status-b2g-v2.1:
--- → fixed
Reporter | ||
Comment 24•11 years ago
|
||
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
Comment 25•10 years ago
|
||
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.
Description
•