[Settings] 'configure' activity seems broken

VERIFIED FIXED in Firefox OS v2.1

Status

Firefox OS
Gaia::Settings
VERIFIED FIXED
4 years ago
4 years ago

People

(Reporter: julienw, Assigned: arthurcc)

Tracking

({regression})

unspecified
2.1 S2 (15aug)
x86_64
Linux
regression
Dependency tree / graph

Firefox Tracking Flags

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

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
STR:
1. open SMS app
2. tap the top right button to open the menu (note: you need to wait that the first panel is loaded for the menu to work)
3. press "settings"

Expected:
* The "messaging" panel of Settings is displayed

Actual:
* The main panel is displayed.

QA: can you please test on 2.0 and 2.1? I personally tested on a recent 2.1 but I'd like to double-check. Thanks !
Issue is reproducible on Flame 2.1 and Buri 2.1.

Observed behavior: When tapping on Settings via Messages app, user is being taken to Settings app's main page, and not Message Settings section of Settings app. Note that SIM related settings are all grayed out in this situation (SIM manager, Call Settings, Message Settings, and Cellular & Data). User needs to kill Settings app and re-open it in order to correctly launch Message Settings.

Device: Flame
BuildID: 20140807062317
Gaia: 54c3c19d439f7dbafda5c6cc3b4850b545a068ba
Gecko: aa1617678a90
Version: 34.0a1 (2.1)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

Device: Buri
BuildID: 20140806134618
Gaia: 5e6ef81cb9e917657ce050f598229dfc83c58b8f
Gecko: a31cd48facbf
Version: 34.0a1 (2.1)
Firmware v1.2device.cfg
User Agent Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

--------------------------

Issue is NOT reproducible on Flame 2.0.

Observed behavior: When tapping on Settings via Messages app, device correctly brings up Message Settings section of Settings app.

Device: Flame
BuildID: 20140807025215
Gaia: 9d681c6a3b69af2d76e7e00c31bc57e0c3efb6b9
Gecko: ca7386df2e91
Version: 32.0 (2.0)
Firmware V123
User Agent Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.0: --- → unaffected
status-b2g-v2.1: --- → affected
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Contact: pcheng
[Blocking Requested - why for this release]: regression in a major feature
blocking-b2g: --- → 2.1?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Keywords: regression, regressionwindow-wanted
b2g-inbound regression window:

Last Working Environmental Variables:
Device: Flame
BuildID: 20140711071921
Gaia: 5b33a1e4c82d57369ec6812177e477e308d538ce
Gecko: 07618025b80d
Version: 33.0a1 (Master)
Firmware: V123
User Agent: Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First Broken Environmental Variables:
Device: Flame
BuildID: 20140711073213
Gaia: 6ecc793750a99c3fc4477aaa7a601dc1d9b67b86
Gecko: bf03f8e8d1d9
Version: 33.0a1 (Master)
Firmware V123
User Agent Mozilla/5.0 (Mobile; rv:33.0) Gecko/33.0 Firefox/33.0

First broken gecko & last working gaia - no repro
Gaia: 5b33a1e4c82d57369ec6812177e477e308d538ce
Gecko: bf03f8e8d1d9

First broken gaia & last working gecko - repro
Gaia: 6ecc793750a99c3fc4477aaa7a601dc1d9b67b86
Gecko: 07618025b80d

Gaia pushlog:
https://github.com/mozilla-b2g/gaia/compare/5b33a1e4c82d57369ec6812177e477e308d538ce...6ecc793750a99c3fc4477aaa7a601dc1d9b67b86

There is only one bug in the pushlog, Bug 1024893.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: regressionwindow-wanted
Broken by bug 1024893 ? Can you take a look Sergi?
Blocks: 1024893
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell) → needinfo?(sergi.mansilla)
This was a design flaw of settings app where we should not skip ongoing navigation when there is a pending one. Bug 1024893 introduce a certain calling sequence that caused the problem.
Assignee: nobody → arthur.chen
Flags: needinfo?(sergi.mansilla)
Created attachment 8469762 [details]
pr.html

Remove the code that skips the current navigation. We should let the current navigation finish before doing the next one to ensure the class names controlling the transition are set correctly. EJ, could you help review the patch? Thanks.
Attachment #8469762 - Flags: review?(ejchen)
See Also: → bug 1041593
Comment on attachment 8469762 [details]
pr.html

It loooks good to me, thanks Arthur !
Attachment #8469762 - Flags: review?(ejchen) → review+
Thanks!

master: 2ed0b81ade2c6c4799a66b84bbfa267f522e6070
Status: NEW → RESOLVED
Last Resolved: 4 years ago
status-b2g-v2.1: affected → fixed
Resolution: --- → FIXED

Updated

4 years ago
blocking-b2g: 2.1? → 2.1+
Target Milestone: --- → 2.1 S2 (15aug)
Blocks: 1041593
Comment on attachment 8469762 [details]
pr.html

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): N/A
[User impact] if declined: Users are not able to back to the previous panel sometimes.
[Testing completed]: Yes
[Risk to taking this patch] (and alternatives if risky): Low
[String changes made]: N/A
Attachment #8469762 - Flags: approval-gaia-v2.0?(bbajaj)
(In reply to Arthur Chen [:arthurcc] from comment #9)
> Comment on attachment 8469762 [details]
> pr.html
> 
> NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to
> better understand the B2G approval process and landings.
> 
> [Approval Request Comment]
> [Bug caused by] (feature/regressing bug #): N/A
> [User impact] if declined: Users are not able to back to the previous panel
> sometimes.
> [Testing completed]: Yes
> [Risk to taking this patch] (and alternatives if risky): Low
> [String changes made]: N/A

I am confused here, 2.0 is marked as unaffected here, so why would we want to land this change there?
Flags: needinfo?(arthur.chen)
It's unaffected, but the patch solves bug 1055874 (a v2.0 blocker) at the same time. Or I should create a separate patch there?
Flags: needinfo?(arthur.chen)
(In reply to Arthur Chen [:arthurcc] from comment #11)
> It's unaffected, but the patch solves bug 1055874 (a v2.0 blocker) at the
> same time. Or I should create a separate patch there?

yea, that would be better as I do want to confuse the status flag on this bug.
Comment on attachment 8469762 [details]
pr.html

clearing the nom as we'll take care of this in 2.0 by landing the patch in 1055874
Attachment #8469762 - Flags: approval-gaia-v2.0?(bbajaj)
This issue is verified fixed for the Flame 2.1 (319mb)

Device: Flame 2.1
BuildID: 20141011000201
Gaia: f5d4ff60ffed8961f7d0380ada9d0facfdfd56b1
Gecko: d813d79d3eae
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 34.0a2 (2.1)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Result: After selecting settings in the  message settings the device will go to the normal settings for less than a second, then switch over to the correct message settings.  

----------------------------------------------------------------------------------------

This issue IS affected for the Flame 2.2 Master KK (319mb)

Flame 2.2 Master KK (319mb) (Full Flash)

Device: Flame 2.2 Master
BuildID: 20141011040204
Gaia: 95f580a1522ffd0f09302372b78200dab9b6f322
Gecko: 3f6a51950eb5
Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf
Version: 35.0a1 (2.2 Master)
Firmware: V180
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0

Result: Device will linger for at least a few seconds in the normal settings, and then eventually switch over to the correct message settings. There is a substantial delay on the 2.2 compared to the 2.1
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
status-b2g-v2.1: fixed → verified
status-b2g-v2.2: --- → affected
Flags: needinfo?(ktucker)

Updated

4 years ago
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage?][failedverification]
Depends on: 1081592
status-b2g-v2.2: affected → ---
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?][failedverification] → [QAnalyst-Triage+]
bug 1081592 has been written for the issue in comment 14.
You need to log in before you can comment on or make changes to this bug.