Closed
Bug 1119917
Opened 10 years ago
Closed 10 years ago
[Windows Management] [Settings] Pulling down the notification menu and tapping the wifi icon (when not previously connected) does not take you to the WiFi settings page when user is located anywhere else in settings.
Categories
(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)
Tracking
(blocking-b2g:2.2+, b2g-v2.1 unaffected, b2g-v2.2 verified, b2g-master verified)
Tracking | Status | |
---|---|---|
b2g-v2.1 | --- | unaffected |
b2g-v2.2 | --- | verified |
b2g-master | --- | verified |
People
(Reporter: jmitchell, Assigned: mancas)
Details
(Keywords: regression, Whiteboard: [2.2-Daily-Testing])
Attachments
(2 files)
173.40 KB,
text/plain
|
Details | |
46 bytes,
text/x-github-pull-request
|
arthurcc
:
review+
bajaj
:
approval-gaia-v2.2+
|
Details | Review |
Description:
The normal functionality of the wifi icon on the notification menu is to toggle wifi off and on. If you have not yet connected to a wifi network or previously connected networks are not available then you will be taken to the wifi settings page. This does not occur if you are already anywhere in settings.
An example where this might be inconvenient to the user is as follows: Setting up a firefox account you can get several screens deep and have already entered your email before being prompted to enable an Internet connection; the user, in an attempt to not have to undo their progress, might try to access the wifi page in this manner. They would expect to be taken to a subset of the internet connection settings option similar to when trying to connect to a webpage without internet connection.
Repro Prerequisite: No internet / data enabled; no internet connection information stored
Repro Steps:
1) Update a Flame to 20150109010206
2) Proceed to anywhere in the Settings app (Example: Firefox Accounts)
3) Pull down the notification menu
4) Tap the wifi icon (twice if it is already blue)
Actual:
Nothing occurs, user is not taken to wifi settings page
Expected:
User will be taken to the wifi settings page (possibly a nested version so when they back out they will return to their previous location).
<OR> there might be some type of indication that selecting the wifi icon from being already in settings somewhere is not a valid option - as it stands - the user will select it with expected functionality that will not occur and it will feel broken.
Environmental Variables:
Device: Flame Master (KK - Nightly - Full Flashed)
Build ID: 20150109010206
Gaia: 5f0dd37917c4a6d8fa8724715d4d3797419f9013
Gecko: b3f84cf78dc2
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 37.0a1 (Master)
Firmware Version: V18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Repro frequency: 6/6
See attached: Logcat
---------------------------------------------------------------------------
This issue does NOT reproduce in 2.1
Actual Results: The user is taken to the wifi page from anywhere in other settings pages
Device: Flame 2.1 (KK - Nightly - Full Flashed)
Build ID: 20150108001214
Gaia: ed2e278753e8c9301ba322dcf2c3591f5928408d
Gecko: 127a0ead5f83
Gonk: a814b2e2dfdda7140cb3a357617dc4fbb1435e76
Version: 34.0 (2.1)
Firmware Version: V18D
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Reporter | ||
Updated•10 years ago
|
Flags: needinfo?(pbylenga)
Reporter | ||
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?]
Comment 1•10 years ago
|
||
Functional regression of a core feature.
Requesting a window.
blocking-b2g: --- → 2.2?
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: regressionwindow-wanted
Updated•10 years ago
|
status-b2g-master:
--- → affected
QA Contact: pcheng
Comment 2•10 years ago
|
||
b2g-inbound regression window:
Last Working Environmental Variables:
Device: Flame
BuildID: 20141020205719
Gaia: e09e1734ad523cf63351a28f6f84454319349fbe
Gecko: 4da1f6a151d6
Version: 36.0a1 (2.2 Master)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
First Broken Environmental Variables:
Device: Flame
BuildID: 20141020214218
Gaia: ba10744d64411a8a12ae68f7cf1ec3e3ac897d21
Gecko: bcc5df613d83
Version: 36.0a1 (2.2 Master)
Firmware: V18D-1
User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0
First Broken Gaia & Last Working Gecko - issue DOES repro
Gaia: ba10744d64411a8a12ae68f7cf1ec3e3ac897d21
Gecko: 4da1f6a151d6
First Broken Gecko & Last Working Gaia - issue does NOT repro
Gaia: e09e1734ad523cf63351a28f6f84454319349fbe
Gecko: bcc5df613d83
Gaia pushlog:
https://github.com/mozilla-b2g/gaia/compare/e09e1734ad523cf63351a28f6f84454319349fbe...ba10744d64411a8a12ae68f7cf1ec3e3ac897d21
Caused by Bug 1007600.
Comment 3•10 years ago
|
||
Arthur, could you take a look at this please? Looks like the landing to bug 1007600 may have caused this to occur.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker) → needinfo?(arthur.chen)
Assignee | ||
Comment 4•10 years ago
|
||
This is the same issue that is happening there: bug 1118669
Settings app is not handling the mozActivities if the app is open.
Comment 5•10 years ago
|
||
Triage: regression blocking
Assignee: nobody → arthur.chen
blocking-b2g: 2.2? → 2.2+
Comment 6•10 years ago
|
||
The root cause was the activity would not be opened if the app handling the activity is exactly the app currently in foreground [1]. Alive, triggering an activity handled by settings app when settings app is in foreground sounds a valid case to me, any ideas?
[1]: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/child_window_factory.js#L253
Flags: needinfo?(arthur.chen) → needinfo?(alive)
Assignee | ||
Comment 7•10 years ago
|
||
Hey Arthur, I've been working in bug 1118669. I think we could detect that the app is open and then we should save the current state of the application in order to restore it when the user completes the required task.
Comment 8•10 years ago
|
||
Had an offline discussion with Arthur.
We will try to use different hash for settings activity at first to resolve this one; I don't look into the bug 1118669 since it's settings only patch; waiting arthur feedback.
Flags: needinfo?(alive)
Assignee | ||
Comment 10•10 years ago
|
||
Hey Arthur, I not sure if this is what you talked with Alive. Take a look and let me know if we should change something
Thanks!
Attachment #8554476 -
Flags: review?(arthur.chen)
Comment 11•10 years ago
|
||
Comment on attachment 8554476 [details] [review]
Proposed patch
This looks good to me. But I'm going to reopen bug 1118669 because after this is fixed, the activity window will be under the system dialog. Let's use bug 1118669 tracking the issue.
Attachment #8554476 -
Flags: review?(arthur.chen) → review+
Updated•10 years ago
|
Assignee: arthur.chen → b.mcb
Comment 12•10 years ago
|
||
Manuel, could you help rebase to master and run gaia-try again? Thanks.
Flags: needinfo?(b.mcb)
Assignee | ||
Updated•10 years ago
|
Flags: needinfo?(b.mcb)
Keywords: checkin-needed
Comment 13•10 years ago
|
||
Autolander could not locate a review from a user within the suggested reviewer list. Either the patch author or the reviewer should be in the suggested reviewer list.
Updated•10 years ago
|
Keywords: checkin-needed
Comment 14•10 years ago
|
||
Autolander could not locate a review from a user within the suggested reviewer list. Either the patch author or the reviewer should be in the suggested reviewer list.
Comment 15•10 years ago
|
||
Manuel, the commit message should explain what you did in the patch instead of the bug title. Could you help update it? Since gaia-try has already passed, I'll merge the PR for you once you done the update. Thanks.
Flags: needinfo?(b.mcb)
Comment 16•10 years ago
|
||
master: 192295d20cc1ee4ea1cce9920ee9ad4520e8f8ca
Status: NEW → RESOLVED
Closed: 10 years ago
Flags: needinfo?(b.mcb)
Resolution: --- → FIXED
Assignee | ||
Comment 17•10 years ago
|
||
Thanks Arthur!
Comment 18•10 years ago
|
||
Comment on attachment 8554476 [details] [review]
Proposed patch
[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): N/A
[User impact] if declined: Users are not able to open activities of settings app when settings app is in foreground. This happens when users are using settings app and try to toggle connection settings from the utility tray or the rocket bar.
[Testing completed]: Testing on the device.
[Risk to taking this patch] (and alternatives if risky): Low as it does not make changes to the code.
[String changes made]: None
Attachment #8554476 -
Flags: approval-gaia-v2.2?
Updated•10 years ago
|
Attachment #8554476 -
Flags: approval-gaia-v2.2? → approval-gaia-v2.2+
Comment 19•10 years ago
|
||
Target Milestone: --- → 2.2 S5 (6feb)
Comment 20•10 years ago
|
||
This issue is verified fixed on Flame 3.0 and on Flame 2.2.
Observed behavior: Without previously connected to internet, tapping on the wifi icon of utility tray while inside a Settings page correctly goes to the Wifi settings page, and user is able to back out to previous page after setting wifi. The flow matches original reporter's first expected behavior.
Device: Flame 3.0 (nightly user, full flash, 319MB mem)
BuildID: 20150206010204
Gaia: 94af4b42d2ace6c9f38f31de77240604fac68af1
Gecko: 7c5f187b65bf
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0 Master)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0
Device: Flame 2.2 (tinderbox eng, full flash, 319MB mem)
BuildID: 20150206141725
Gaia: e827781324cbde91d2434b388f5dead3303a85ee
Gecko: 0552759956d3
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 37.0a2 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in
before you can comment on or make changes to this bug.
Description
•